Methods and devices for STA assisted multi AP coordination

Abstract

Wireless network comprising an intermediate station which receives MAP coordination frames from first AP and transmits MAP coordination frames to a second AP A wireless network comprising a first basic service set (BSS) managed by a first access point (AP), a second BSS managed by a second AP, and an intermediate station (STA) in wireless range of the first and the second APs. The STA receives a multi-AP (MAP) coordination frame from the first AP managing the first BSS, and the STA sending a second MAP coordination frame to the second AP managing the second BSS. The STA may convert parameter values representative of the operating context of the first BSS in the first MAP coordination frame into parameter value representative of the second BSS operating context in the second MAP coordination frame. Receiving the first MAP frame may involve identifying target wake time (TWT) schedule. The MAP coordination frame is at least one of: a WNM action frame, a generic advertisement service frame, a frame inside the established pre-association security recognition, a pre-association wireless network management frame and / or a public action frame. The STA may be configured in either relay or proxy mode. The MAP frame may comprise a multi-hop action frame comprising an Event Request element representative of a request for an Event Report element comprising MAP-related information.

Description

FIELD OF THE INVENTION The present invention generally relates to wireless communications and more specifically to STA assisted multi-AP coordination. BACKGROUND OF THE INVENTION Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, etc. These wireless networks may be multiple-access networks capable of supporting multiple users by sharing the available network resources. Examples of such multiple-access networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA (OFDMA) networks, and Single-Carrier FDMA (SC-FDMA) networks. In dense multiple AP networks, co-channel interference between BSSs (Basic Service Sets) becomes a problem. Methods for AP coordination can then be helpful to improve the use of the limited radio resources. The IEEE (Institute of Electrical and Electronics Engineers - RTM) 802.11 be draft standard Task Group addresses a so-called Multi-Access Point (Multi-AP or MAP) technology which aims at providing some collaboration between neighbouring access points (APs) managing separate BSSs in order to have a more efficient utilization of time, frequency and spatial resources available. This is particularly important when the neighbouring APs operate over the same selected communication channel (or over channels sufficient close in frequency to generate interferences) in which interferences may occur. In that case, the BSSs are referred to as overlapping BSSs or OBSSs. Furthermore, even if the neighbouring BSSs corresponding to two or more APs do not hear their wireless signal each other, one or more STAs (Which can be both AP STA or non-AP STA) may exist intermediately within the wireless range of two or more APs. In this case, the STAs may face interferences with neighbouring BSS's operation as well. 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. The MAP topic is now addressed back in the 802.11 bn Task group, which is the successor of the 802.11 be 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. Recent publications of the 11 bn task 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. For the time being, there is no procedure or functionality to generate reports on MAP state events. Mechanisms to provide a wireless network management for MAP operations are needed that would allow reports to be efficiently generated and exchanged between APs which are not able to communicate with each other, e.g., regarding operations prior to the creation of a MAP coordination set (such as how to advertise capable APs) as well as operations during the lifetime of the MAP coordination set, i.e., within an established MAP coordination set (such as informing of any event change in the group). Today, there exists no capability for a multi-AP wireless network to manage MAP operations if APs are not able to communicate with each other. SUMMARY OF INVENTION It is a broad objective of the present invention to overcome some of the foregoing concerns. The inventors have noticed that existing Wireless Network Management can be extended to APs and new services for the MAP group. The wireless network management procedure for a WLAN is known to provide protocols relevant to the wireless network management, such as allowing a non-AP station or an access point (AP) to collect a variety of information on the wireless network or diagnosing problems of the wireless network. Currently, those procedures are limited to intra-BSS operations. As an example, IEEE 802.11v or BSS Transition is an amendment that was published in 2011 and added to the IEEE 802.11-2012 standards. Besides radio measurements, 802.11v enables the reporting of different MAC level events through a so-called Event Request / Report exchange. By using this feature, an AP is able to request its associated STAs information about recent or past transition events (i.e. handovers), Robust Security Network Association events regarding authentication parameters, and so on. The invention takes advantage of the existing 802.11 reporting mechanism to enhance MAP management in a MAP group in the use case in which to APs cannot communicate directly. As such, according to a first aspect, the present invention aims at a communication method over a medium in a wireless network, said network comprising a first Basic Service Set (BSS) managed by a first access point (AP), a second BSS managed by a second AP and an intermediate station (STA) in wireless range of the first and the second APs, the communication method comprising: receiving, by the STA, a first multi-AP (MAP) coordination frame from the first AP managing the first BSS; and sending, by the STA, a second MAP coordination frame to the second AP managing the second BSS. Such dispositions allow for the MAP coordination of several access points which are not directly connected through a wireless communication channel. An intermediate unit corresponds, preferably, to a station (STA) in the sense of Standard IEEE 802.11. However, such an intermediate station may correspond to an access point. In particular embodiments, the method object of the present invention further comprises a step of converting, by the STA, at least one parameter value representative of an operating context of the first BSS in the first MAP coordination frame into a parameter value representative of an operating context of the second BSS in the second MAP coordination frame. Such embodiments allow the emission of contextually accurate messages in each BSS, that is, messages that fit into the particular operating parameters of each BSS. In particular embodiments, the at least one converted parameter value corresponds to a parameter representing clock information applicable to the second BSS. In particular embodiments: during the step of receiving, the first MAP coordination frame identifies a Target Wake Time, TWT schedule provided in the first BSS; during the step of converting, the timing information of the received TWT schedule in the first BSS that is based on a first clock applicable to the first BSS is converted into timing information based on a second clock applicable to the second BSS; and during the step of sending, the second MAP coordination frame sent identifies a Target Wake Time, TWT, schedule in the second BSS based the converted timing information. In particular embodiments: during the step of receiving, the first MAP coordination frame identifies a target address in the first BSS; during the step of converting, the target address in the first BSS is converted into a target address in the second BSS in the second MAP coordination frame; and the step of sending is executed as a function of the converted target address in the second MAP coordination frame. Such embodiments allow for the indirect communication between access points, each communicating with the intermediate station. In particular embodiments, at least one MAP coordination frame is a frame which is formatted to be exchanged, between STA and AP, in an association-less state. In particular embodiments, the STA and at least one AP are in association state, wherein at least one MAP coordination frame exchanged between the STA and said at least one AP is a frame which is formatted to be exchanged, between STA and AP, in an association-less state. Such embodiments allow the communication between a STA and an AP which are not associated, therefore allowing for MAP coordination regardless of association status. In particular embodiments, at least one MAP coordination frame is at least one of: a WNM action frame; a generic advertisement service frame; a frame inside the established pre-association security negotiation; a pre-association wireless network management frame; and / or a public action frame. In particular embodiments, the method object of the present invention comprises a step of transmitting a discovery request, by the first AP associated with the first BSS, to the STA, representing a request to identify the second AP managing the second BSS which the STA can communicate with. In particular embodiments, the method object of the present invention comprises a step of assessing, by the first AP associated with the first BSS, the existence of the second AP associated with the second BSS, the step of transmitting a discovery request being performed if the presence of the second AP is assessed. Such embodiments allow for the smart discovery of APs outside a MAP network with which a MAP coordination is required. In particular embodiments, the method object of the present invention comprises a step of transmitting an unsolicited MAP coordination response from the STA without said STA receiving a MAP coordination request from the first AP. In particular embodiments, the method object of the present invention comprises a step of configuring the STA in either a relay mode or a proxy mode, in which: in a relay mode, the STA sends each frame received to and from the first and / or second APs; and in a proxy mode, the STA manages MAP events with the first AP to conclude an information exchange and, when the information exchange is concluded, sends a MAP coordination report to the second AP. Such embodiments allow for more flexibility in operational capabilities of the system, based upon, for example, computing capacities of the STA. Indeed, proxy mode requires more intensive computing by the STA in comparison to the relay mode in which less interpretation of the content of exchanges is required. In particular embodiments, the method object of the present invention comprises a step of negotiating between a STA and an AP to determine if the STA is to be configured in relay mode or in proxy mode, the step of configuring being performed as a function of the result of the step of negotiating. Such a step of negotiating allows for the selection of the appropriate operational mode in view of the capabilities of the STA and the desired operational conditions of the system. In particular embodiments, at least one MAP coordination frame comprises a multihop action frame comprising an Event Request element, representative of a request for an Event Report element, and an Event Report element according to the 802.11 standard family, which comprises MAP-related information. According to a second aspect, the present invention aims at a wireless network, said network comprising a first Basic Service Set (BSS) managed by a first access point (AP), a second BSS managed by a second AP and an intermediate station (STA) in wireless range of the first and the second APs, the STA comprising: a receiver of a MAP coordination frame from the first AP managing the first BSS; and an emitter of a MAP coordination frame to the second AP managing the second BSS. According to a third aspect, the present invention aims at a multi-hop action frame, which comprises an Event Request element, representative of a request for an Event Report element, and an Event Report element, according to the 802.11 standard family, which comprises MAP-related information. According to a fourth aspect, the present invention aims at 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 object of the present invention. According to a fifth aspect, the present invention aims at a wireless communication device comprising at least one microprocessor configured for carrying out the method object of the present invention. At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium. Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a hard disk drive, a magnetic tape device or a solid-state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal. BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figure 1a illustrates an exemplary network environment in which embodiments of the present disclosure can be implemented; Figure 1b illustrates an exemplary network environment in which one of the embodiments of the present disclosure can be implemented; Figure 1c illustrates an exemplary network environment in which one of the embodiments of the present disclosure can be implemented; Figure 2 illustrates, using frame exchanges in a timeline, an Event reporting procedure according to the 802.11 standard; Figure 3a illustrates a format of an Event Request frame according to the 802.11 standard; Figure 3b illustrates values that the Event Type field of Figure 3a can take; Figure 3c illustrates a format of the Event Report frame according to the 802.11 standard; Figure 4 illustrates, using frame exchanges in a timeline, a MAP Event reporting procedure according to some embodiments; Figure 4a illustrates an Event Type field table according to some embodiments; Figure 4b illustrates an Advertisement protocol field table according to some embodiments; Figure 4c illustrates, using frame exchanges in a timeline, an Event reporting procedure with the Relay STA according to the one of the embodiments of the present disclosure; Figure 4d illustrates the Multihop Action fields table according to some embodiments; Figure 4e illustrates the Multihop MAP Event Request / Response frame format according to some embodiments; Figure 4f illustrates MAC Header fields of Multihop Action frames according to some embodiments; Figure 4g illustrates, using frame exchanges in a timeline, an Event reporting procedure with the Proxy STA according to the one of the embodiments of the present disclosure; Figure 4h illustrates, using frame exchanges in a timeline, an unsolicited Event reporting procedure with the Proxy STA according to the one of the embodiments of the present disclosure; Figure 5 illustrates, using a flowchart, general steps of embodiments of the invention, that take place at a reporting AP; Figure 5a illustrates an exemplary state machine for a Multi-AP Group, implicitly defining various triggering events associated to MAP events to be reported; Figure 6a illustrates an exemplary format of a MAP Event Request element according to embodiments; Figure 6b illustrates an exemplary format of a MAP Event Report element according to embodiments; Figure 6c illustrates the format of a ‘AP Channel Report’ element to be used in the MAP Event Report element of Figure 6b according to embodiments; Figure 6d illustrates the format of a ‘MAP Group’ element to be used in the MAP Event Report element of Figure 6b according to embodiments; Figure 6e illustrates the format of a ‘Target Wake Time (TWT)’ element to be used in the MAP Event Report element of Figure 6b according to embodiments; Figure 6f illustrates the format of a ‘TWT Constraint Parameters’ element to be used in the MAP Event Report element of Figure 6b according to embodiments; Figure 6g illustrates the format of a ‘Neighbor Report (NR)’ element to be used in the MAP Event Report element of Figure 6b according to embodiments; Figure 6h illustrates the format of a ‘Reduced Neighbor Report (RNR)’ element to be used in the MAP Event Report element of Figure 6b according to embodiments; Figure 6i illustrates the format of a ‘MAP Capabilities’ element to be used in the MAP Event Report element of Figure 6b according to embodiments; Figures 7a and 7b illustrate, using flowcharts, an exemplary MAP Event management procedure according to embodiments, respectively at a requesting AP and responding AP according to embodiments; Figure 7c illustrates, using flowcharts, an exemplary MAP Event management procedure in case of MLD according to embodiments; Figures 8a, 8b and 8c illustrate, using flowcharts, an exemplary MAP Event management procedure according to embodiments, respectively at a requesting AP, responding AP and Relay STA according to embodiments; Figures 9a, and 9b illustrate, using flowcharts, an exemplary MAP Event management procedure according to embodiments, respectively at a requesting AP, responding AP and Proxy STA according to embodiments; Figures 10a, 10b and 10c illustrate an exemplary AP / STA list the MAP group manages according to embodiments; Figure 11a shows a schematic representation a communication device in accordance with embodiments of the present invention; Figure 11b shows a schematic representation of a wireless communication device in accordance with embodiments of the present invention; and Figure 12 illustrates, using flowcharts, an exemplary MAP coordination between two APs according to embodiments of the present invention. DETAILLED DESCRIPTION OF EMBODIMENTS The techniques described herein may be used for various broadband wireless communication systems, including communication systems that are based on an orthogonal multiplexing scheme. Examples of such communication systems include Spatial Division Multiple Access (SDMA) system, Time Division Multiple Access (TDMA) system, Orthogonal Frequency Division Multiple Access (OFDMA) system, and Single-Carrier Frequency Division Multiple Access (SC-FDMA) system. An SDMA system may utilize sufficiently different directions to simultaneously transmit data belonging to multiple user terminals, i.e. wireless devices, or stations. A TDMA system may allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units, each time slot being assigned to different user terminal. An OFDMA system utilizes orthogonal frequency division multiplexing (OFDM), which is a modulation technique that partitions the overall system bandwidth into multiple orthogonal sub-carriers or resource units. These sub-carriers may also be called tones, bins, etc. With OFDM, each sub-carrier may be independently modulated with data. An SC-FDMA system may utilize interleaved FDMA (IFDMA) to transmit on sub-carriers that are distributed across the system bandwidth, localized FDMA (LFDMA) to transmit on a block of adjacent sub-carriers, or enhanced FDMA (EFDMA) to transmit on multiple blocks of adjacent sub-carriers. The teachings herein may be incorporated into (e.g., implemented within or performed by) a variety of apparatuses (e.g., stations). In some aspects, a wireless device or station implemented in accordance with the teachings herein may comprise an access point (so-called AP) or not (so-called non-AP station). An AP may comprise, be implemented as, or known as a Node B, Radio Network Controller (“RNC"), evolved Node B (eNB), 5G Next generation base station (gNB), Base Station Controller (“BSC”), Base Transceiver Station (“BTS”), Base Station (“BS”), Transceiver Function (“TF”), Radio Router, Radio Transceiver, Basic Service Set (“BSS”), Extended Service Set (“ESS”), Radio Base Station (“RBS”), or some other terminology. A non-AP station may comprise, be implemented as, or known as a subscriber station, a subscriber unit, a mobile station (MS), a remote station, a remote terminal, a user terminal (UT), a user agent, a user device, user equipment (UE), a user station, or some other terminology. In some implementations, a non-AP STA may comprise a cellular telephone, a cordless telephone, a Session Initiation Protocol (“SIP”) phone, a wireless local loop (“WLL”) station, a personal digital assistant (“PDA”), a handheld device having wireless connection capability, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone or smart phone), a computer (e.g., a laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music or video device, or a satellite radio), a global positioning system (GPS) device, or any other suitable device that is configured to communicate via a wireless or wired medium. In some aspects, the non-AP station may be a wireless node. Such wireless node may provide, for example, connectivity for or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link. An AP manages a set of non-AP 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 non-AP STA is identified within a BSS thanks to an identifier, AID, assigned to it by the AP upon registration. The 802.11 family of standards define various media access control (MAC) mechanisms to drive access to the wireless medium. For example, in order to address the issue of increasing bandwidth and decreasing latency requirements that are demanded for wireless communications systems in high-density environments, multi-user (MU) schemes have been developed to allow a single access point (AP) managing a Basic Service Set (BSS) to schedule MU transmissions, i.e., multiple simultaneous transmissions to or from non-AP stations of the BSS, in the wireless network. A MU scheme has been adopted in the 802.11 ax-2021 standard, published on May 2019. Thanks to the MU feature, a non-AP station has the opportunity to gain access to the wireless medium via two access schemes: the MU scheme and the conventional Enhanced Distributed Channel Access - EDCA (Single User) scheme. Each BSS defines a main elementary channel of the wireless medium (known as a primary channel, usually a 20 MHz channel or a multiple of 20 MHz channel) on which the stations (including the AP) perform EDCA contention using generally legacy EDCA parameters (defined in an EDCA Parameter Set provided by the AP). To increase bandwidth for the forthcoming transmission, the stations can simultaneously contend for additional 20 MHz channels, known as secondary channels. The communication channel thus granted for transmission comprises the primary channel and optionally secondary channels. The 802.11 ax standard allows a MU downlink (DL) transmission to be performed by the AP when gaining access to the wireless medium for a transmission opportunity (TXOP). During the MU DL transmission on the granted communication channel, the AP performs multiple simultaneous elementary transmissions, over so-called resource units (RUs), to various non-AP stations. As an example, the resource units split the communication channel of the wireless network in the frequency domain, based for instance on Orthogonal Frequency Division Multiple Access (OFDMA) technique. The assignment of the RUs to the non-AP stations is signalled at the beginning of the MU Downlink frame, by providing an association identifier (AID) of a non-AP station (individually obtained by each station during its association procedure with the AP) for each RU defined in the transmission opportunity. The 802.11 ax standard also allows a MU uplink (UL) transmission to be triggered by the AP when gaining access to the wireless medium. During the MU UL transmission, various non-AP stations can simultaneously transmit data to the AP over the resource units forming the communication channel. To control the MU UL transmission by the non-AP stations, the AP previously sends a control frame, known as a Trigger Frame (TF). The Trigger Frame allocates the resource units to the non-AP stations of the same BSS, using 16-bit Association IDentifiers (AIDs) assigned to them upon registration to the AP and / or using reserved AIDs designating a group of non-AP stations. The TF also defines the start of the MU UL transmission by the non-AP stations as well as the length thereof. After a non-AP station makes an MU UL transmission, it performs EDCA contention on the medium using temporarily a different (from the legacy ones) set of EDCA parameters, known as MU EDCA parameters (defined in a Multi-User (MU) EDCA Parameter Set provided by the AP). The current discussions in the task group 802.11 be, as illustrated by draft IEEE P802.11 be / D5.0 of November 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. 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. 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 including passive scanning (ML beacons) or active scanning (ML Probe Request and corresponding Response), followed by ML Authentication and finally by ML Setup where the non-AP MLD associates with the AP MLD (hence obtained an Association IDentifier, AID) and sets up the ML links for its affiliated non-AP STAs with the APs affiliated with the AP MLD. 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). 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. The affiliated APs and non-AP STAs operate on their respective channels in accordance with one or more of the IEEE 802.11 standards (a / b / g / n / ac / ad / af / ah / aj / ay / ax / be / bn) or other wireless communication standards. Thanks to the multi-link aggregation, traffic associated with a single MLD can theoretically be transmitted across multiple parallel communication links, thereby increasing network capacity and maximizing utilization of available resources. The description below mostly concentrates on a single link for ease of explanation. However, similar considerations can be made with respect to each link forming a multiple link set for MLD devices. Therefore, the term STA or “station” may refer to one affiliated STA of a non-AP MLD (non-AP STAs of a non-AP MLD), and AP may refer to one affiliated AP of an AP MLD. Figure la illustrates a context of use of the present invention, which corresponds to a network environment, which comprises several APs, each AP managing a BSS, such a network environment being referred to as a “multi-AP system”. The illustrated wireless network environment comprises a multi-AP system 100a 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 an operating channel (e.g., 20 MHz, 40 MHz, 80 MHz, 160 MHz or 320 MHz). A first wireless network (or Basic Service Set) BSS1 comprises an access point (AP) 110y (y can be a or b or c) and three non-AP stations (STAs) 111a, 112a and 113a associated to AP 110y (i.e., registered with it). A second wireless network BSS2 comprises an AP 120 and three associated non-AP STAs 121 y, 122y and 123y. A third wireless network BSS2 comprises an AP 130y and three associated non-AP STAs 131y, 132y and 133y. In the following, BSSx represents any of the wireless networks, while 1x1 y (x can be 1 or 2 or 3), 1x2y and 1x3y 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 110y, 120y and 130y 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. All or part of the APs may be affiliated APs to the same AP MLD. They also can be separate devices. Any AP broadcasts management frames, such as beacon frames, to share parameters to be used for the functioning of its BSS. The stations (AP and non-AP) of each wireless network exchange data frames over the communication channel 100 (or operating channel), 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. In the context of the invention, two different patterns may be used in exemplary network environments. In a first pattern, as Figure 1b illustrates, 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). References 101b, 102b and 103b refer to the wireless ranges of BSS1, BSS2 and BSS3 respectively. In such a pattern, while APs can communicate directly, there may be situations in which communication through an intermediate STA may be required. Such situations may arise, for example, when connectivity between APs is too poor, or when an AP fails to reach another AP initially, thus attempting an intermediated attempt to reach said another AP. In a second pattern, as Figure 1c illustrates, the APs cannot communicate one with each other since they do not have means of direct communication including both wireless and wired links. References 101c, 102c and 103c refer to the wireless range of BSS1, BSS2 and BSS3 respectively. In this second case, APs may communicate with other APs by with the assistance of intermediate STA(s) (which can be both AP STA or non-AP STA) such as STA11 111c, STA13 113C, STA31 131c. Each non-AP STA 1x1y-1x3y registers to the AP 1x0y (where y is either b or c) of one wireless network BSSx during an association procedure. During the association procedure over the primary channel, the AP assigns a specific Association IDentifier (AID) to the requesting station. For example, the AID is a 16-bit value uniquely identifying the station. The stations (including the AP) compete one against 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. More generally, the resources may include space, frequency and time resources and may be obtained according to different multiplexing schemes. Examples of those schemes include Spatial Division Multiple Access (SDMA) system, Time Division Multiple Access (TDMA) system, Orthogonal Frequency Division Multiple Access (OFDMA) system, and Single-Carrier Frequency Division Multiple Access (SC-FDMA) system. In the IEEE 802.11 wireless local area networking standards, the multi-AP system 100 may correspond to an extended service set (ESS) and each of the wireless networks to a basic service set (BSS). Although the description of embodiments of the invention is given in the context of IEEE 802.11, the embodiments are not limited thereto and they may apply to other types of wireless networks and protocols. To meet low latency requirements in 802.11 be as well as to increase efficiency of the MU operation, existing mechanisms have been reused and improved. As example, the Target Wake Time (TWT) mechanism, originally defined in the IEEE 802.11 ah and 802.11 ax standards, has been adapted to be included in the 802.11 be D3.2 standard. TWT enables wake time negotiation between an AP and an associated station (non AP STA) for improving power efficiency. With TWT operation, a non-AP STA has only to wake up at a pre-scheduled time negotiated with another non-AP STA or AP in the network. 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). 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. 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. 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. 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. 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. The wireless network management procedure for a WLAN provides protocols relevant to the wireless network management (WNM), such as allowing a non-AP station or an access point (AP) to collect a variety of information on the wireless network or diagnosing problems of the wireless network. For example, the wireless network management procedure includes an event reporting procedure, a diagnostic reporting procedure, a presence service procedure, a base service set (BSS) transition management procedure, a flexible broadcast multicast service (FBMS) procedure, a traffic filter service (TFS) procedure, and a sleep mode procedure. The Event reporting procedure according to the 802.11 standard (section 4.3.19.8 in IEEE Std 802.11™-2020) is shown in Figure 2. The Event reporting procedure serves to diagnose states of a network in real time. The Event reporting procedure in a WLAN defines a variety of events such as a transition event, a robust security network association (RSNA) event, a peer-to-peer link event, and a system log event as event request / report elements. Event request / report elements other than the system log event define various types of sub-elements. The STA log of events recording the reported events is not cleared as a result of BSS transitions. However, if the STA moves to a different ESS or IBSS, the STA deletes all event log entries. A STA that supports Event reporting sends an Event Request or Event Report frame to a STA within the same infrastructure BSS or the same IBSS. As shown in the Figure, a station transmitting an Event Request frame is called a requesting STA, while a station transmitting an Event Report frame is called a reporting STA or a requested STA. In ESS embodiment (infrastructure BSS), the requesting STA is often an access point (AP) and the reporting STA is a non-AP STA. Alternatively, in the wireless network management procedure in the IBSS (independent BSS is a sort of ad hoc mode or peer to peer network), the requesting STA and the reporting STA may both be a non-AP STA. The requesting STA transmits an Event Request frame 210 to the reporting STA to request the reporting STA to report one or more event information on one or more event report elements, in an Event Report frame 211. The Event Request frame 210 can include one or more Event Request elements, as shown in Figure 3a. Figure 3a illustrates a format of an Event Request frame according to the 802.11 standard. Event Request frame 310 includes a Category field 300, an Action field 301, a Dialog Token field 302, an Event Request Elements field 303 comprising one or more Event Request elements 320, and Destination URI element 304. Category field 300 is set to a value indicating that the corresponding frame belongs to a Wireless Network Management category (value 10 according to Table 9-79 of in IEEE P802.11-REVme / D4.0, August 2023). As several Action frame formats are defined for wireless network management (WNM) purposes, a WNM Action field 301, in the field immediately after the Category field, differentiates the formats. WNM Action field 301 is set to a value indicating that the frame is an Event Request frame (WNM Action field value equals 0, according to Table 9-510 in IEEE P802.11-REVme / D4.0, August 2023). Dialog Token field 302 is used to identify the exchange of frame between the stations, and is set to a value selected by the requesting STA, so as to match Event Request frame 210 with Event Report frame 211. Event Request Elements field 303 contains the one or more of the Event Request elements 320. Destination URI element 304 is of less importance for the present invention. The AP includes the URI in the Destination URI element that the reporting non-AP STA may use to send Event Reports, upon the loss or interruption of connectivity to the BSS. Event Request element 320 contains a request to the receiving STA to perform the specified event action, wherein: Element ID field 321 is set to a value (equal to 78) indicating that the information element is an Event Request element. Length field 322 is set to various values depending on the length of the Event Request element 320. Event Token field 323 is a nonzero number that is unique among the Event Request elements sent to each destination MAC address for which a corresponding Event Report element has not been received. Event Type field 330 is set to indicate the types of events requested when a STA transmits an Event Request frame to another STA. The Event Type field 330 is a number that identifies the type of event request. The event type can include, for example, a transition event, an RSNA event, a peer-to-peer link event, a BSS color collision detection and a system log event. The values of the Event Type field are defined per Figure 3b (Table 9-231 of IEEE P802.11-REVme / D4.0, August 2023). Event Response Limit field 324 is set to indicate the maximum number of logged events to report in the corresponding Event Request element 320. If the number of available logged events of the requested type exceeds the Event Response Limit, the reporting STA reports an Event Response Limit number of the most recent events. If there are no available logged events of the type specified in the Event Request frame, the reporting STA sends the Event Report frame without any Event Report element. The reporting STA sends all available Event Report elements for the requested event type when the Event Request field is not present in the Event Request element. The Event Response Limit field is set to 0 to indicate that no limit is set on the number of Event Reports to be included in the Event Report element. Event Request field 325 contains the event request corresponding to the event type, as described in 9.4.2.66.2 (Transition event request) to 9.4.2.66.8 (BSS color in use event report) of IEEE P802.11-REVme / D4.0, August 2023. The requested STA or reporting STA processes (220) the received Event Request frame, generates an Event Report frame 211 and sends it to the requesting STA in response to the Event Request frame 210. The Event Report frame (211) can include the same number of Event Report elements as specified in the Event Response Limit field 324 for the requested event type. Figure 3c illustrates a format of the Event Report frame 211 according to the 802.11 standard. Category field 350, WNM action field 351 and Dialog Token field 352 are similar to Category field 300, WNM action field 301 and Dialog Token field 302 described above. If the Event Report frame 211 is transmitted spontaneously, i.e., for another reason than in response to an Event Request frame 210, then the Dialog Token field 352 is set to 0. Event Report Elements field 353 contains one or more of the Event Report elements 360. A given Event Report element 360 is used by the reporting STA to report an event: Element ID field 361 is set to a value (equal to 79) indicating that the information element is an Event Report element. Length field 362 is set to various values depending on the length of Event Report element 360. Event Token field 363 is the Event Token in the corresponding Event Request element 320. If the Event Report element is sent spontaneously / autonomously (i.e., not in response to an Event Request element 320), then Event Token 363 is set to 0. Event Type field 364 is a number that identifies the type of Event Report element 320. The values of the Event Type field 364 are the same as those used for Event Type field 330, hence they correspond to those of Figure 3b. Event Report Status field 365 is set to a value indicating the STA’s response to the Event Request. The Figure shows the various values available to indicate success, failure of request, refusal of request, and so on. Event TSF (Timing Synchronization Function) 366, UTC Offset 367, Event Time Error 368, and Event Report fields are not always present (depending on whether the status is successful and on the Event Type). Event TSF field 366 is TSF value when the STA logged the event. UTC Offset field 367 is the UTC value that corresponds to the UTC time when the TSF timer is equal to 0. Event Time Error field 368 is the UTC standard deviation, that corresponds to the TSF value logged for the event. If 367 and 368 are unknown, the field isO. Event Report field 369 contains the specification of a single event report. In each Event Report element 360, the reporting STA includes a Status field that indicates the result of the Event Request / Report transaction. If the reporting STA is able to return one or more Event Report elements 360, then the reporting STA returns a value of "Successful" in the Event Report Element (in Event Report Status field 365). If the reporting STA has no logged events of the requested type, the reporting STA returns a value of Successful in the Event Report Status field 365 without an event included in the Event Report field 369. If the reporting STA is unable to process the request at that time, the reporting STA returns a value of "Request failed" in the Event Report Status field 365 of the Event Report element 360. However, the known Event reporting procedure is limited to reports within the same infrastructure BSS or the same IBSS, i.e. between the stations (including the AP) of the same BSS. Back to Figure 1y (where y can correspond to a or b or c) depicting multiple APs, a Multi-AP (MAP) technology has emerged where the APs 110y, 120y, 130y 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 including in a pattern in which APs are assisted by the intermediate STA(s), to coordinate the MAP communications, and thus to avoid interference that may result from an overlapping of their respective BSSs (hence known as Overlapping BSSs, or OBBSs). 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. To coordinate the MAP communications, the APs and / or non-AP STAs may be part of an inter-AP coordination group or “MAP coordination set” of APs and / or non-AP STAs or “AP group” below, the formation of which is not yet defined by IEEE 802.11 standard. One may envisage that the APs and / or non-AP STAs willing to collaborate previously issues management frames, like beacons or dedicated broadcasted frames or with the MAP Event Request and MAP Event Report frames exchange described below, to advertise the other APs and / or non-AP STAs of their MAP coordination capability. The coordination group is also referred to as the AP Candidate Set for the MAP sharing. Mechanisms to provide a wireless network management for MAP operations is needed that would allow reports to be efficiently generated and exchanged between APs and / or non-AP STAs, e.g., regarding operations prior to the creation of a MAP coordination set (such as how to advertise capable APs) as well as operations during the lifetime of the MAP coordination set, i.e., within an established MAP coordination set (such as informing of any event change in the group). This is for the APs and / or non-AP STAs to be informed of any event regarding to a MAP coordination set. Embodiments of the present disclosure extend the conventional (i.e. according to 802.11) Event reporting procedure to support service of a Multi-AP event support. A new request / report type can be allocated to MAP event request and report in AP-to-AP communication which may include at least one intermediate STA, wherein the requesting station and the responding station are APs. When a MAP event occurs with respect to a MAP Coordination Set, an AP obtains multi-AP, MAP,-related information about the MAP Coordination Set. As described below, exemplary events may include an end of the MAP Coordination Set, a creation of a MAP Coordination Set, a leaving of an AP from the MAP Coordination Set, a joining of a new AP and / or non-AP STA to the MAP Coordination Set, an end of a Target Wake Time, TWT, session coordinated within the MAP Coordination Set, a creation of a TWT session coordinated within the MAP Coordination Set, a detection of an isolated neighbouring AP and / or non-AP STA not yet included in the MAP Coordination Set, a change of an operating channel of the MAP Coordinated Set. In this context of the present invention, it is considered that non-AP STAs are also able to join the MAP group since they may assist the MAP activities. The AP may then share this information with the other APs and / or non-AP STAs, in particular those of the MAP Coordination Set or of a group to build such as a MAP Coordination Set. The AP thus sends to one or more other APs and / or non-AP STAs, a frame including an Event Report element according to the 802.11 standard family that comprises the obtained MAP-related information. Reusing the Event Report element substantially reduces the complexity of introducing MAP management. In contexts where APs cannot communicate directly, a communication method over a medium in a wireless network, said network comprising a first Basic Service Set (BSS) managed by a first access point (AP), a second BSS managed by a second AP and an intermediate station (STA) in wireless range of the first and the second APs, the communication method comprising: receiving, such as the step 1201 of receiving shown in figure 12, by the STA, a first multi-AP (MAP) coordination frame from the first AP managing the first BSS; and sending, such as the step 1202 of sending shown in figure 12, by the STA, a second MAP coordination frame to the second AP managing the second BSS. Such a MAP coordination frame can correspond to an Event Request or Event Report frame, for example. In this perspective, Figure 4 illustrates, using frame exchanges in a timeline, a MAP Event reporting procedure according to some embodiments which applies to network environments where APs can communicate directly such as the one shown in Figure 1b, as a new type of Multi-AP Network Management procedure 400. Only one Requesting AP 110b and one Reporting AP 120b is shown in Figure 4 but one can envisage that multiple Requesting APs or multiple Reporting AP may exchange MAP Event Request / Report frames as well. A requesting STA (that is an AP as 110b) transmits an event request frame 410 to a requested STA ora reporting STA (that is an AP 120b). Reporting STA may also be a STA such as STA 111b. The event request frame is transmitted from one AP to request another AP to report one or more events related to Multi-AP operations. That is to say, an AP that supports event reporting can send such an event request frame to another AP (inter-BSS communication) whose last received Extended Capabilities element contains a value of 1 for the Event bit in the Extended Capabilities element that it transmits in its beacon or management frames. While the Figure is described with only two APs for sake of illustration, the Network Management procedure 400 is not limited to that number. AP 110b and AP 120b may be neighbouring APs that do not yet participate to a MAP coordination set. Hence, they do not yet belong to the same MAP coordination set or even to any MAP coordination set. The MAP Network Management procedure 400 may help them to discover their capabilities and set up a MAP coordination set. AP 110b and AP 120b may be neighbouring APs of the same MAP coordination set to which they participate. The MAP Network Management procedure 400 may help them to know more easily about new events within the MAP coordination set, hence to efficiency organize cooperation within the MAP coordination set, such as scheduling rTWT or sharing TXOPs. The reporting AP processes (420) any received MAP Event Request frame 410, generates a corresponding MAP Event Report frame 411 and sends it to the requesting AP in response to the MAP Event Request frame 410. The Event Report frame (411) can include the same number of MAP Event Report elements as specified in the (MAP) Event Response Limit field 324 for the requested event type (as described above for the conventional Event reporting procedure). The MAP Event Request or Report frame 410 / 411 may be addressed to a single AP. In that case, the frame including an Event Report element may be a dedicated unicast frame addressed by a first AP to the second AP over the medium or using an alternate communication medium. The description below is mainly be based on this assumption. However, variants exist where the frame is addressed to a group address, i.e., to a group of APs. Also, the description below of MAP management is mainly based on existing WNM Action frames such as Event Request and Report frames, that follow the format of Figures 2, 3a, 3b and 3c with adaptations as explained below. The frames are therefore Event Report frames according to IEEE P802.11 REVme including the Event Report element. In embodiments allowing distinguishing between conventional Event Request and Report frames and those dedicated to MAP management according to the present disclosure, the Event Request element includes an Event Type field 330 / 364 set to a value comprised between 6 and 220, in particular value 6 as shown in Figure 4a (which shows this new value in addition to conventional values for the Event Type field in Table 9-231). Exemplary Event Request elements 320 and Event Report elements 360 that are included in these frames 410 / 411 for MAP management purposes are described below with reference to Figure 6a and 6b respectively. In variants to the Event Request and Report frame formats, the frame is a generic advertisement service, GAS, Initial / Query Request or Response frame according to IEEE P802.11 REVme including the Event Request or Report element. Such a type of frame (GAS) advantageously allows the frame to be sent at destination to several APs without requiring the association with such APs. The generic advertisement service (GAS) relies on the use of Public Action frames which can be exchanged between STAs even in pre-association state. In particular variants, if two STAs are associated, these STAs can exchange Event Request / Report element with MAP Event Request and Report frames which belongs to WNM Action category. Else if two STAs are not associated, these STAs can exchange Event Request / Report element with GAS Initial Request and Response frames which belongs to Public Action category or with any other frames which is allowed to be exchange without association. A GAS frame exchange conventionally takes place between two STAs: one STA transmits a GAS Query Request and the other STA transmits the GAS Query Response as described in 11.22.3.2 (GAS Protocol). The advertisement protocol transported by the GAS is one of the query protocols in Table 9-275 (Advertisement protocol ID definitions) according to 802.11 REVme / D4.0. Embodiments provide that at least 2 APs issue GAS frames. In addition, the GAS frames can be transmitted as group addressed frames (Data frame that has an RA that is a group address to a set of receiving STAs, for example the MAC address of the MAP group). Therefore, multiple APs of the invention may be addressed with a GAS frame in a group addressed GAS Query Request, and may send in response an individually addressed or group addressed GAS Query Response. To allow distinguishing between conventional GAS frames and those dedicated to MAP management according to the present disclosure, an Advertisement Protocol element in the GAS frames may be set to a value comprised between 5 and 220, in particular value 5 as shown in Figure 4b (which shows this new value in addition to conventional values for the Advertisement protocol field in Table 9-275). The new advertisement protocol corresponding to this new value, here ‘5’, is referred to as “Multi-AP Query protocol”. The GAS protocol, which is used to transport Query Requests frames and Query Response frames, is transparent to the advertisement protocol. The new advertisement protocol ID is thus included in the Advertisement Protocol element in a Beacon or Probe Response frame. Similar Event Request elements 320 and Event Report elements 360 as those mentioned above (described below with reference to Figure 6a and 6b) can be included in these GAS frames for MAP management purposes. In particular embodiments, at least one MAP coordination frame is a frame which is formatted to be exchanged, between STA and AP, in an association-less state. Such embodiments may use of new variant of Public Action frame (instead of falling into Public Action frame format defined for GAS as described before) may be operated. Table 9-450 shows the latest definition of the Public Action field values of IEEE P802.11-REVme / D4.0. Value 47 to 255 is Reserved so for example, 47 can be used for the MAP Event Request and 48 can be used for the MAP Event Response. These MAP Event Request and MAP Event Response Public Action frames contain the same information as the MAP Event Request and MAP Report Action frames with WNM category except the Category field value that should be 4 for Public Action frames and 10 for WNM Action frames. Having the Event Request and Report frames as Public Action frames, STAs can exchange these frames in pre-association state. In such embodiments, the Event Request and Report frames which has the WNM Action (value 10) as its Category field can be added as frames which can be exchanged during the pre-association state. In such embodiments to the MAP Event Request and Report frame formats, the use of Pre-association Security Negotiation, PASN which is introduced in the IEEE 802.11 az amendment to secure the MAP management frames may be operated. PASN provides a security negotiation before the association stage by three-message authentication frame exchange. Public action frames are allowed to be exchange after the PASN authentication as shown in the P802.11az amendment. One can envisage that the Event Request and Report frames which has the WNM Action (value 10) as its Category field can be added as frames which can be exchanged after the PASN authentication as well. As it is understood, at least one MAP coordination frame is at least one of: a WNM action frame; a generic advertisement service frame; a frame inside the established pre-association security negotiation; a pre-association wireless network management frame; and / or a public action frame. In particular embodiments, at least one MAP coordination frame exchanged between the STA and said at least one AP is a frame which is formatted to be exchanged, between STA and AP, in an association-less state. Figure 4c and 4g illustrate, using frame exchanges in a timeline, a MAP Event reporting procedure according to some embodiments which applies to network environments where Requesting AP and Reporting AP cannot communicate directly such as the one shown in Figure 1c, as a new type of Multi-AP Network Management procedure 400. More specifically, Figure 4c illustrates the case of having Relay STA as the intermediate station and Figure 4g illustrates the case of having Proxy STA instead. In particular embodiments, the method object of the present invention comprises a step of configuring, such as the step 1207 of configuring shown in figure 12, the STA in either a relay mode ora proxy mode, in which: in a relay mode, the STA sends each frame received to and from the first and / or second APs; and in a proxy mode, the STA manages MAP events with the first AP to conclude an information exchange and, when the information exchange is concluded, sends a MAP coordination report to the second AP, such as shown in figure 5a. In particular embodiments, one intermediate STA (such as 113c) can have both capabilities of Relay Station and Proxy Station and act as both roles simultaneously. Those roles can be separately triggered based on the received frames by the Requesting AP(s) and / or Reporting AP(s). For example, Relay STA role can be triggered when receiving Multihop MAP Event Request / Report frames and Proxy STA role can be triggered when receiving MAP Event Request / Report frames. In particular embodiments, the method object of the present invention comprises a step of negotiating, such as the step 1208 of negotiating shown in figure 12, between a STA and an AP to determine if the STA is to be configured in relay mode or in proxy mode, the step of configuring being performed as a function of the result of the step of negotiating. In such embodiments, this role can be negotiated between Requesting AP and the intermediate STA using the (Multihop) MAP Event Request frames with MAP Capabilities subelement 600-e which indicates the role requested to the intermediate STA. The intermediate STA may accept this by responding the (Multihop) MAP Event Report frame with Event Report Status field 365 to 0 Successful. Otherwise, the intermediate STA may refuse this by responding the (Multihop) MAP Event Report frame with Event Report Status field 365 to any one of the following: 1 Request failed, 2 Request refused, 3 Request incapable. In other embodiments, if the Requesting AP and the intermediate STA are associated, this negotiation may be done in the association procedure using the MAP Capabilities information which may be placed in Association Request frame as well. As illustrated in Figure 4c, a requesting STA (that is an AP as 110c) transmits an event request frame 410b to a Relay STA (that is a STA as 113c) and this Relay STA forwards the Event Request Frame as 412b to the reporting STA (that is an AP 120c). Then the Reporting AP 320 reports back an Event Report Frame 412b to Relay STA 113c. Finally, Relay STA 113c forwards this Event Report to Requesting AP 110c as Event Report Frame 411b. Only one Requesting AP 110c, one Relay STA 113c and one Reporting AP 120c is shown in Figure 4c but one can envisage that multiple Requesting APs or multiple Relay STAs or multiple Reporting AP may exchange Multihop MAP Event Request / Report frames as well. In particular embodiments, the method object of the present invention further comprises a step of converting, such as the step 1203 of converting shown in figure 12, by the STA, at least one parameter value representative of an operating context of the first BSS in the first MAP coordination frame into a parameter value representative of an operating context of the second BSS in the second MAP coordination frame. Such a parameter value may correspond to an Address field. In such embodiments, for example: during the step of receiving, the first MAP coordination frame identifies a target address in the first BSS; during the step of converting, the target address in the first BSS is converted into a target address in the second BSS in the second MAP coordination frame; and the step of sending is executed as a function of the converted target address in the second MAP coordination frame. In particular embodiments, the method object of the present invention comprises a step of transmitting, such as the step 1204 of transmitting shown in figure 12, a discovery request (individually addressed), by a first AP associated with the first BSS, to the STA, representing a request to identify the second AP managing the second BSS which the STA can communicate with. In particular embodiments, the method object of the present invention comprises a step of assessing, such as the step 1205 of assessing shown in figure 12, by the first AP associated with the first BSS, the existence of the second AP associated with the second BSS, the step of transmitting a discovery request being performed if the presence of the second AP is assessed. Such embodiments may use the Beacon Request / Report mechanism of the 802.11 standard, in which a requesting AP sends Beacon Request to the non-AP STA to ask if there are neighboring APs around the non-AP STA. Then the non-AP STA may provide in response a Beacon Report including a Neighbor Report element that reports about the discovered APs. A Neighbor Report can include the lEs (Information Element) found in the discovered APs. Furthermore, the AP can request what IE are to be reported using the Request element attached to the Beacon Request. Two embodiments may be envisaged: in a first embodiment, the Requesting AP can ask the STA for discovery using the MAP Event Request / Report mechanism without any estimation and the STA reports if there are candidate APs; and In a second embodiment, the Requesting AP can do the preparation using the Beacon Request / Report mechanism as described above, and, after receiving information about candidate APs, the Requesting AP may skip the discovery using the MAP Event Request / Report and proceed to the next step. One advantage to use the proposed MAP Event Request / Report mechanism is that the STA is not required to be associated with the Requesting AP. In other embodiments, the method comprises a step of transmitting a MAP coordination request, by a first AP associated with the first BSS, to the STA, said MAP coordination request being integrated into a MAP coordination frame sent (either in broadcast, unicast or multicast). In such embodiments, Relay STA 113c simply forwards the received Multihop MAP Event Request and Report by converting the Address fields included in the MAC header as described below. Frames in 9.3.3.1 Format of (PV0) Management frames of IEEE P802.11-REVme / D4.0, Multihop Action frames are specified to enable the multi-hop exchange of the Action frames. These Multihop Action frames can be used to achieve the forwarding by the Relay STA of this embodiment. According to the Table 9-538 Multihop Action field values of IEEE P802.11-REVme / D4.0, Multihop Action field value is Reserved for 2-255. For example, the value of 3 can be assigned to Multihop MAP Event Request and the value of 4 can be assigned to Multihop MAP Event Report as shown in Figure 4d but this embodiment is not limited to such values. In particular embodiments, at least one MAP coordination frame comprises a multihop action frame comprising an Event Request element, representative of a request for an Event Report element, and an Event Report element according to the 802.11 standard family, which comprises MAP-related information, such as disclosed in the present document. Examples of the contents of Multihop Event Request and Multihop Event Report Action frames are for example shown in Figure 4e. These include the same elements as the Event Request elements 320 and Event Report elements 360 as those mentioned above (described below with reference to Figure 6a and 6b). In particular embodiments, the method object of the present invention comprises a step of extracting information from a mesh control field, and a step of populating at least one of the Event Request element and / or the Event Report element with the extracted information. In such embodiments, Event Request elements 320 and Event Report elements 360 may include Mesh Control field as specified in Figure 9.34 of IEEE P802.11-REVme / D4.0. Essential parts in this Mesh Control for this invention are Address Extension Mode field and Address Extension field and one can envisage to extract only these parts and construct a new dedicated Control field such as Multihop Control field to reduce the overhead. Address Extension Mode filed should at least have one bitto indicate 0: None and 1: Address4. If 0: None is indicated, Address Extension field doesn’t exist. If 1: Address4 is indicated, Address Extension field exists and this contains Address 4 information with 6 octets. The usage of Addressl to Address4 is identical to the ones for Multihop Action frames which are specified in Table 9-75 Address field contents for mesh Data and Multihop Action frames of IEEE P802.11-REVme / D4.0 except followings: a) For individually addressed Multihop Action frames, DA and SA are not Mesh DA and Mesh SA but are one of the addresses of Requesting AP or Reporting AP. b) For group addressed Multihop Action frames, SA is not Mesh SA but is one of the addresses of Requesting AP or Reporting AP as shown in Figure 4f. Multihop Action frames are able to be exchanged between Requesting AP 110c, Relay STA 113c and Reporting AP even if they are not associated each other. When Requesting AP 110c sends individually addressed Multihop MAP Event Request Frame 410b to Relay STA 113c with aiming the final destination to Reporting AP 120c, Multihop MAP Event Request Frame 410b contains MAC header with To DS: 0, From DS: 0, Address extension mode: Address4, Addressl: RA (MAC Address of Relay STA 113c), Address2: TA (MAC Address of Requesting AP), Address3: DA (MAC Address of Reporting AP 120c), Address4: SA (MAC Address of Requesting AP 110c). Relay STA 113c receives this frame and then forwards the frame as Multihop MAP Event Request Frame 412b to Reporting AP 120c. Multihop MAP Event Request Frame 412b contains MAC header with To DS: 0, From DS: 0, Address extension mode: Address4, Addressl: RA (MAC Address of Reporting AP 120c), Address2: TA (MAC Address of Relay STA 113c), Address3: DA (MAC Address of Reporting AP 320), Address4: SA (MAC Address of Requesting AP 110c). Reporting AP 120c receives this frame and then responds the Multihop MAP Event Report Frame 413b to Relay STA 113c aiming the final destination as Requesting AP 110c. Multihop MAP Event Report Frame 413b contains MAC header with To DS: 0, From DS: 0, Address extension mode: Address4, Addressl: RA (MAC Address of Relay STA 113c), Address2: TA (MAC Address of Reporting AP 120c), Address3: DA (MAC Address of Requesting AP 110c), Address4: SA (MAC Address of Reporting AP 120c). Relay STA 113c receives this frame and then forwards the frame as Multihop MAP Event Report Frame 411b to Requesting AP 110c. Multihop MAP Event Report Frame 411b contains MAC header with To DS: 0, From DS: 0, Address extension mode: Address4, Addressl: RA (MAC Address of Requesting AP 110c), Address2: TA (MAC Address of Relay STA 113c), Address3: DA (MAC Address of Requesting AP 110c), Address4: SA (MAC Address of Reporting AP 120c). If the Address 3: DA is set to a group address such as broadcast address in the Multihop MAP Event Request Frame 410b, Relay STA 113c can groupcast the Multihop MAP Event Request Frame 412b by setting the Address 1: RA to the indicated group address (i.e. broadcast address in this example). This usage may be useful when the Requesting AP 110c doesn’t know any of the address of Reporting AP(s) since Requesting AP 110c can ask Relay STA 113c to broadcast the Multihop MAP Event Request Frame 412b to any of the potential Reporting AP 120c. This frame is individually addressed for the first hop (from Requesting AP 110c to the Relay STA113c in this case), but converted as group addressed when it is relayed at the second hop (from Relay STA 113c to Reporting APs). When Requesting AP 110c sends group addressed Multihop MAP Event Request Frame 410b to Relay STA 113c, Multihop MAP Event Request Frame 410b contains MAC header with To DS: 0, From DS: 0, Address extension mode: None, Addressl: DA (MAC Address of the target group), Address2: TA (MAC Address of Requesting AP), Address3: SA (MAC Address of Requesting AP 110c). Relay STA 113c receives this frame and then forwards the frame as Multihop MAP Event Request Frame 412b to the target group (not illustrated). Multihop MAP Event Request Frame 412b contains MAC header with To DS: 0, From DS: 0, Address extension mode: None, Addressl: DA (MAC Address of target group), Address2: TA (MAC Address of Relay STA 113c), Address3: SA (MAC Address of Requesting AP 110c). As a response, one of the reporting APs (e.g. Reporting AP 120c) included in the target group may send an individually addressed Multihop MAP Event Report Frame 413b. In this case, the MAC header construction is already explained above. In another case, one of the reporting APs (e.g. Reporting AP 120c) included in the target group may send a group addressed Multihop MAP Event Report Frame 413b. In this case, Multihop MAP Event Report Frame 413b contains MAC header with To DS: 0, From DS: 0, Address extension mode: None, Addressl: DA (MAC Address of target group), Address2: TA (MAC Address of Reporting AP 120c), Address3: SA (MAC Address of Reporting AP 120c). Relay STA 113c receives this frame and then forwards the frame as Multihop MAP Event Report Frame 411b to Requesting AP 110c. Multihop MAP Event Report Frame 411b contains MAC header with To DS: 0, From DS: 0, Address extension mode: None, Addressl: DA (MAC Address of target group), Address2: TA (MAC Address of Relay STA 113c), Address3: SA (MAC Address of Reporting AP 120c). Multihop MAP Event Request Frame 410b can be received by other Relay STA(s) (not illustrated) and these Relay STA(s) may forward the frame as well. To explain the advantage of group addressed Event Report, for example if several Requesting APs relayed requests to one reporting AP through different relay STAs asking the same event report, the Reporting AP may send the Event Report with groupcast frame which is destined to the multiple requesting APs through the multiple relay STAs. This can reduce the overhead of reporting each event report individually to Requesting APs As illustrated in Figure 4g, a requesting STA (that is an AP as 110c) transmits an event request frame 410c to a Proxy STA (that is a STA as 113c) and this Proxy STA processes event(s) 412c that may happen between Reporting AP 120c and feedback with Event Report Frame 411c to the Requesting AP 120c. Only one Requesting AP 110c, one Proxy STA 113c and one Reporting AP 120c is shown in Figure 4g but one can envisage that multiple Requesting APs or multiple Proxy STAs or multiple Reporting AP may exchange MAP Event Request / Report frames and process events as well. Compared to the Relay STA described in Figure 4c, Proxy STA that is an intermediate STA which acts as a Proxy of Reporting AP(s) does not simply forward the Event Request and Response frame from Requesting AP to Reporting AP or vice versa but instead, it interprets the Event Request from Requesting AP and processes the relevant events and constructs the Event Report based on the processed events. This requires more complexity and processing in the Proxy STA 113c but may have advantage to decrease the complexity and processing in Requesting AP 110c and / or Reporting AP 120c side and furthermore, enables more complex embodiments as described later. One can envisage to use Multihop MAP Event Request / Response frames towards Proxy STA to destine the target over the Proxy STA as done for Relay STA. In the other embodiment, as shown in Figure 4h, Proxy STA (that is a STA as 113c) may process MAP events between Reporting AP(s) (such as AP 120c) as shown in 412c and send the MAP Event Report Frame 411 c to a Requesting AP (such as AP 110c) without receiving MAP Event Request Frame by the Requesting AP. This corresponds to an unsolicited MAP Event Report. With this, Proxy STA 113c can trigger the reporting of MAP events without waiting the trigger from the Requesting AP(s). Proxy STA 113c may discover which Requesting AP to send the unsolicited MAP Event Report by any means. One example is to conduct an active scanning (i.e. to send a Probe Request frame) or passive scanning by Proxy STA 113c and to receive a beacon frame or a Probe Response frame to discover an MAP capable AP(s). If Proxy STA 113c discovers an MAP capable AP(s) by whom it didn’t receive any MAP Event Request Frame yet, Proxy STA 113c may send an unsolicited MAP Event Report to inform the MAP event between the Reporting APs to the discovered MAP capable AP(s). One can further envisage that Relay STA 113c as shown in 113c may send an unsolicited MAP Event Report Frame without receiving any request frames from the Requesting AP 110c as well as the Proxy STA does. In particular embodiments, the method comprises a step of transmitting, such as the step 1206 of transmitting shown in figure 12, an unsolicited MAP coordination response from the STA without said STA receiving a MAP coordination request from the first AP. Figure 5 illustrates, using a flowchart, general steps of embodiments of the invention, that take place at a reporting AP and / or Proxy STA. The process starts for the reporting AP and / or Proxy STA to detect at step 500 whether a report triggering event occurs, i.e., a reason why a MAP Event Report should be transmitted to another neighbouring AP or Relay STA or Proxy STA yet belonging to the same MAP Coordination Set or not. As already mentioned above with reference to Figure 4, Figure 4c and Figure 4g, a first triggering event may include receiving a request frame 410,412b or 410c with a MAP Event Request element. This means that the sending of the MAP Event Report is responsive to receiving such request frame. Figure 6a illustrates an exemplary format of such a MAP Event Request element 320 included in the request frame 410 or 412b or 410c, be it a MAP Event Request Frame or a GAS Query Request or a Public Action frame or a Multihop Action frame. The same references as in Figure 3a correspond to the same fields. Event Type field 330 is set to value ‘6’ to signal the Multi-AP Protocol. The requesting AP may include zero or more MAP Event requests (or MAP Event Request subelements) 600 in Event Request field 325 of Event Request element 320. Subelements 600 are defined to have a common general format consisting of a 1-octet element-specific Subelement ID field, a 1-octet Length field, and a variable length subelement-specific Data field. Each subelement is assigned a subelement ID that is unique within the containing element or subelement. The Length field specifies the number of octets in the Data field. The Event Request elements can contain conditions that specify events to be reported and conditions that establish event reporting when an AP experiences modifications, problems or failures. The following exemplary subelements are defined for different MAP Event types corresponding to different Subelement IDs as shown in Table 610. Each MAP Event Request subelements is made of a Subelement ID field, a Length field, and a Data field that depends on the MAP Event type (hence Subelement ID). Exemplary subelements include: a MAP Group ID to signal an identifier of the MAP Coordination Group. It is illustrated with MAP Group ID subelement 600-a (Subelement ID value 0) that identifies the Multi-AP group (MAP Coordination Set) to be reported. In the absence of this subelement with ID=0 from the Event Request element 320, the request 410 or 41 Ob or 412b or 410c is a request for MAP Events for any AP or MAP group. A MAP Group ID field of length 0 indicates the wildcard group ID. - an AP BSSID / STA MAC ADDR field to signal an identifier of another AP or non-AP STA of the MAP Coordination Set. It is illustrated with AP / STA Address subelement 600-b (Subelement ID value 1) that identifies a peer AP or non-AP STA of the Multi-AP group to be reported. The presence of this subelement with ID=1 in the Event Request element 320 means that the request is limited to MAP Events of this AP or non-AP STA. It is to be noted that the concerned AP or non-AP STA to monitor may be the requested AP (i.e., reporting AP 220 of Figure 4 that receives the event request frame 410 in which case the indicated address matches the Address 1 field of the MAC header contents of the event request frame 410) or be a remote AP distinct from the requested AP. an Operating Class field together with a Channel Number field to signal an operating channel of the MAP Coordination Set. It is illustrated with Channel Number subelement(s) 600-c (Subelement ID value 2) that identifies the channel for the MAP link or links (in case of MLD) to be reported. The absence of this subelement from the Event Request element 320 means the request 410 or 410b or 412b or 410c is for any channel. The Channel Number subelement 600-c includes an Operating Class field to indicate the channel set of the link to be used for the MAP Event report (Operating Classes are defined in Annex E of 802.11REVme / D4.0) and a Channel Number field to indicate the channel number for MAP Events requested. A Channel Number of 0 in all Channel Number subelements indicates that the request 410 or 410b or 412b or 410c is to report any MAP event for any supported channel in the specified filtering Operating Class. an MLD Links field to signal whether a MAP Event Report is requested for all the links of a neighbouring AP (or non-AP STA) multi-link device or not. It is illustrated with MLD Link(s) subelement 600-d (Subelement ID value 3) that identifies if any MAP activity (existing group or compliant AP) on the links of a reporting AP MLD has to be reported. This may help the requesting AP to discover any MAP group operating (and being detected) on any one of those links of the reporting AP MLD, and for example to change its operating link towards that discovered link. Value 0 in MLD Links field or excluding this subelement 600-d indicates that the request 410 or 410b or 412b or 410c is to report MAP events from the channel where the request is received or from any channel that is listed in Channel Number subelement(s) 600-c (if any). On the contrary, value 1 means that MAP events for any of the links of the responding AP MLD have to be reported. In some embodiments, the MLD Links field may be a bitmap signalling which links amongst the multiple links of the neighbouring AP MLD have to be reported. A MAP Capabilities field to signal whether a MAP Event Report is requested for one or more specific type(s) of MAP coordination subtype. It is illustrated with MAP Capabilities subelement 600-e (Subelement ID value 4) that identifies if any MAP activity (existing group or compliant AP) relevant to the according MAP coordination subtypes of a reporting AP or Proxy STA has to be reported. Value 0 in MAP Capabilities may specify the relevant MAP activity of the corresponding MAP coordination will not be reported. Value 1 for all bits in MAP Capabilities info field or excluding this subelement 600-e indicates that the request 410 or 410b or 412b or 410c is to report all MAP events relevant for any MAP coordination subtypes. According to this invention, at least 2-bit Forwarding capability may be included in the MAP Capabilities information field that indicates the forwarding capability type of Relay STA or Proxy STA that will not be reported. These 2bit may be assigned as follows but not limited to this: 00 (not supported), 01 (Relay STA supported), 10 (Proxy STA supported), 11 (Both Relay STA and Proxy STA supported). Provided this capability information, Requesting AP can request the Relay STA or Proxy STA to report with an ordered way. For example, if the STA supports both Relay STA and Proxy STA capabilities, Requesting AP can request the STA not to use the Proxy STA but to use the Relay STA function by indicating 01 in the Forwarding capability of the MAP Capabilities subelement. This means the Requested STA will not report MAP activity relevant to Proxy STA. Back to Figure 5, other triggering events than receiving request frame 410 or 410b or 412b or 410c may be used at step 500. Figure 5a illustrates an exemplary state machine for a Multi-AP Group, implicitly defining various triggering events associated to MAP events to be reported. Exemplary state 550 corresponds to the creation of a MAP group. The triggering event thus includes creating the MAP Coordination Set. Exemplary state 555 corresponds to the deletion of a MAP group. The triggering event thus includes ending the MAP Coordination Set. Exemplary state 560 corresponds to the admittance of a new AP or non-AP STA in the MAP group. The triggering event thus includes joining the MAP Coordination Set or detecting a joining of another AP or non-AP STA to the MAP Coordination Set. Exemplary state 565 corresponds to the leaving of an AP or non-AP STA from the MAP group. The triggering event thus includes leaving the MAP Coordination Set or detecting a leaving of another AP or non-AP STA from the MAP Coordination Set. Exemplary state 570 corresponds to the creation of a TWT schedule when TWT sessions are used in the MAP group to coordinate transmissions or coordinating APs for BSS interfering avoidance. The triggering event thus includes creating a TWT session coordinated within the MAP Coordination Set. Exemplary state 575 corresponds to the deletion of a TWT schedule when TWT sessions are used in the MAP group to coordinate transmissions or coordinating APs for BSS interfering avoidance. The triggering event thus includes ending a TWT session coordinated within the MAP Coordination Set. Exemplary state 580, hence triggering event, corresponds to a change of operating channel of the MAP group (MAP Coordination Set). Individual events that are not directly concerning the behaviour of a MAP group may be reported. Hence, detecting an isolated neighbouring AP or non-AP STA not yet included in the MAP Coordination Set (but capable to be) may also be a triggering event, corresponding to another state 585. Next to step 500, the reporting AP or Proxy STA obtains (step 510) MAP-related information about the MAP Coordination Set (to be created or existing). This may consist in retrieving the latest event report or reports available at the AP or Proxy STA (in log events) at the time of receiving the request frame. Or it may consist in obtaining information about the event forming the triggering event as mentioned above. Once the MAP-related information has been retrieved at step 510, the reporting AP or Proxy STA generates and sends reporting frame 411 or 413b or 411c that includes a MAP Event Report 320 to convey the MAP-related information about the reported event. This is step 520. The addressee of reporting frame 411 or 411b or 411c may be the requesting AP having sent request frame 410 or 410b or 410c respectively. The addressee of reporting frame 413b may be the Relay STA having sent request frame 412b. In case the reporting frame 411 or 413b or 411 c is sent spontaneously by the reporting AP or Proxy STA, the addressee may include the APs or non-AP STAs in relation to the reported event (as an example, a TWT deleting session may be preferably advertised to the participants of the session prior to the session ending effectiveness) or indirectly impacted by the event (as an example, a TWT deleting session may be preferably advertised to the non-participants of the session in order that they know there will be room (as referring to a maximum number of TWT sessions, Figure 6f) to open new TWT session(s)). Figure 6b illustrates an exemplary format of a MAP Event Report element 360 included in reporting frame 411 or 411b or 413b or 411c. The same references as in Figure 3c correspond to the same fields. Event Type field 364 is set to value ‘6’ to signal the Multi-AP Protocol. Event Report Status field 365 indicates the result of the MAP Event request / report transaction. If the reporting AP is able to return one or more event reports in Event Report field 369 as explained below, then the reporting AP returns a value of “Successful” in Event Report Status field 365. If the reporting AP or Proxy STA has no logged events of a requested type (hence in case a request frame 410 or 412b or 410c is received), the reporting AP or Proxy STA returns a value of “Successful” in Event Report Status field 365 without any event report in Event Report field 369. In some embodiments, fields 36613671368 take different signification compared to the legacy behaviourto define time reference for the MAP Coordination Set. Indeed, it is important for the MAP group to have a time reference when events and schedules (such as TWTs) are intensively considered for cooperation in between the set of APs. One may consider having a common time reference for the MAP group, such as having one AP mastering the clock reference. Fields 366 / 3671368 of MAP Event Report element 360 may thus serve as a time advertisement, as follows: Event TSF field 366 is TSF value when the AP logged the event, taking the reference of the MAP group. UTC Offset field 367 is the UTC value that corresponds to the UTC time when the TSF timer of the MAP group is equal to 0. If the UTC Offset is unknown, the field is set to 0. Event Time Error field 368 is the UTC standard deviation, that corresponds to the TSF value of the MAP group logged for the event. If the Event Time Error is unknown, the field is set to 0. In particular embodiments: during the step of receiving, the first MAP coordination frame identifies a Target Wake Time, TWT schedule provided in the first BSS; during the step of converting, the timing information of the received TWT schedule in the first BSS that is based on a first clock, such as TSF, applicable to the first BSS is converted into timing information based on a second clock, such as TSF, applicable to the second BSS; and during the step of sending, the second MAP coordination frame sent identifies a Target Wake Time, TWT, schedule in the second BSS based the converted timing information. If APs cannot directly communicate each other, intermediate STA such as Proxy STA may be able to receive beacons of Requesting AP and Reporting AP. In this case, Proxy STA can compute the TSF offset of two BSSs and apply the offset when forwarding the Event Reports from the Reporting AP to Requesting AP. In other embodiments, time references can be handled locally in each AP or STA by calculating the offset between TSFs of two or more BSSs. For example, if APs can directly communicate with each other, APs may periodically receive beacons from other APs and compare the TSF value of other BSS with its own TSF value. An event report 650 may be included in Event Report field 369, to report an event. As shown, even report 650 has six first fields conforming to the field format of the peer-to-peer link event report according to IEEE P802.11REVme MAP Event Reports (made of fields 651-656) to which an optional (element) field 657 may be added. One or more of these fields are personalized to MAP operation. In other embodiments (not shown), even report 650 may be preceded by a Subelement ID and Length fields (as in Figure 6a), such as to comply with format 600. BSSID Address I STA Address I MAP Group ID field 651 contains a BSSID MAC address (aka AP MAC address), or the MAC address of Proxy STA, or a MAP Group Identifier that identifies the MAP Coordination Set. A MAC address follows a 6-byte format, whereas a MAP Group Identifier may use only a subset of bits (e.g., 12 bits, or2-octets). The computation of the MAP Group Identifier is out-of-scope of the invention: when a MAP group is created, allocation of a MAP Group Identifier may be envisaged to be used for MAP event filtering. Proxy STA may set the BSSID Address I STA Address / MAP Group ID 651 as its own MAC address when it wants to report its own event (e.g., with having MAP Status field as STA capable detected to report its own existence). Or it may set the BSSID of the Reporting AP that Proxy STA is reporting to the Requesting AP. Operating Class field 652 indicates the channel set of the link where a MAP group is expected to operate. This is the channel set concerned by the report. Valid values of the Operating Class are shown in Annex E of 802.11 REVme / D4.0. Channel Number field 653 indicates the channel number of the link concerned by the report. The Channel Number is defined within an Operating Class as shown in Annex E of 802.11REVme / D4.0. STA Tx Power field 654 indicates the target transmit power at the antenna, used for the MAP group. The presence of this information is not mandatory. Value -128 indicates that the value is unknown. MAP Status field 656 indicates the MAP connection status of the MAP group. Table 660 shows exemplary statuses that can be reported, that corresponds to the various states shown in Figure 5a: MAP group terminated (status = 0 corresponding to state 555), MAP group creation (status = 1 corresponding to state 550), MAP group membership terminated (status = 2 corresponding to state 565), MAP group membership active (status = 3 corresponding to state 560), TWT session terminated (status = 4 corresponding to state 575), TWT session active (status = 5 corresponding to state 570), AP capable detected (status = 6 corresponding to state 585), Operating channel switch (status = 7 corresponding to state 580). This shows how different values in MAP Status field 656 can report different types of events that are detected. The exemplary statuses are provided for the sake of illustration and are non-limitative. Note that although MAP Status field 656 is self-sufficient to report some events (e.g., MAP statuses 0,1), other events may optionally require additional information to be fully reported. For example, with MAP status 3 or 2 or 6 or 8 (reporting the admission or the leaving of an AP / non-AP STA or detection of an isolated AP / non-AP STA), an additional field identifying the AP concerned by the event can be provided, e.g., in Optional Element field 657. Similarly, TWT scheduling information can be provided (in the same Optional Element field 657) in case of MAP status 5 or 4. Also information about the new operating channel may also be included in case of MAP status 7: e.g., fields 653 and 654 may be used to convey the new operational parameters. Optionally, an AP Channel Report Element (Figure 6c below) may be considered in Optional Element field 657 (for providing information of new channel switching or potential channels to be used for a MAP group). More details about exemplary information in Optional Element field 657 are provided below with reference to Figures 6c to 6i. Connection Time field 655 contains the connection time in seconds, for the event report element which generally indicates the time difference from the event timestamp to the current time. The connection time may be customized according to the status value as follows: If MAP Status field 656 is 0, field 655 indicates the duration of the MAP group. If MAP Status field is 1, field 655 indicates the time difference from the time the MAP group was established to the time at which the reporting AP or the Proxy STA generates the event report. If MAP Status field is 2, field 655 indicates the duration of the MAP membership procedure. If MAP Status is 3, field 655 indicates the time difference from the time the AP or the non-AP STA joined the MAP group to the time at which the reporting AP or the Proxy STA generates the event report. If MAP Status field is 4, field 655 indicates the duration of the TWT session membership procedure. If MAP Status is 5, field 655 indicates the time difference from the time any AP of the MAP group schedules a TWT session to the time at which the reporting AP generates the event report. If MAP Status is 6, field 655 indicates the time difference from the time one AP able to support membership of a MAP group was detected to the time at which the reporting AP generates the event report. As mentioned above, Optional Element field 657 may comprise additional information about the reported Event depending of the type of event (hence of the value set in MAP Status field 656). Figures 6c to 6i illustrate various elements that can be provided in Optional Element field 657. They illustrate various but non limitative possibilities to use the scalable Event report mechanism according to the present disclosure. All these elements comprise an Element ID field to identify the type of element, a Length field used in a conventional manner and one or more data fields carrying information specific to the element. Figure 6c illustrates the format of an ‘AP Channel Report’ element according to 802.11REVme / D4.0. In the standard, this element is used to contain a list of channels where a STA is likely to find an AP. In the present disclosure, its use is extended to contain a list of channels wherein a Multi-AP group (the MAP Coordination Set being reported) is likely to operate. This element can be included in field 657 for MAP Status with value 1 (MAP group creation) or 7 (operating channel switch) that require defining a channel. The data fields are made of an Operating Class field and a Channel List field. The Operating Class field contains an enumerated value from Annex E of 802.11REVme / D4.0, to specify the operating class in which the Channel List field is valid. The Channel List field contains a variable number of octets, where each octet describes a single channel number (still on Operating Class according to Annex E) to be considered for operating the MAP group. In a variant to carry an operating channel of the MAP group, this element may define not recommended or even prohibited channels. In this case, the format of Figure 6c (with a different Element ID to distinguish the purpose of the element) conveys a list of channels on which an AP has found conditions that disallow the use of a MAP group operation. Such element can be named ‘MAP Intolerant Channel Report element’ or ‘BSS Intolerant Channel Report element’. The Operating Class field has same meaning as above. The Channel List field contains a variable number of octets, where each octet describes a single channel number that is prohibited or not-recommended for operation of the MAP group (Channel numbering is still dependent on operating class according to Annex E). Figure 6d illustrates the format of a ‘MAP Group’ element to report a MAP group ID, hence to identify the MAP group. This element can be included in field 657 for MAP Status with value 0 to 5, or 7. MAP Group element is similarto subelement 600-a, except that Element ID replaces Subelement ID. As for 600-a, optional Group Address field may be provided to have a pair {MAP Group ID, with a Group Address field} to further indicate the MAC group address for AP-to-AP communication. Figure 6e illustrates the format of a ‘Target Wake Time (TWT)’ element according to 802.11 REVme / D4.0 to report a target wake time scheduled by at least one AP of the MAP Coordination set. This format covers various declinations, such as an individual TWT, a broadcast TWT (bTWT), a Restricted-TWT (rTWT) or an OBSS-TWT which schedules dedicated service periods (SPs) for interference reduction in between APs of the MAP group. Reporting such TWT schedules in a MAP group is of high importance for the APs to efficiently schedule their own infrastructure BSS given possible interferences with OBSSs in the MAP Coordination Set. TWT element can be included in field 657 for MAP Status with value 4 or 5. The data fields are made of a Control field and a TWT Parameter Information field providing all information about the TWT to be reported. Figure 6f illustrates the format of a ‘TWT Constraint Parameters’ element according to 802.11 REVme / D4.0. In the standard, the TWT Constraint Parameters element provides TWT constraint parameters that can be used during the establishment of individual TWT agreements and / or broadcast TWT schedules in a BSS. In the present disclosure, its use is extended to support the negotiation of TWT session within the MAP group. This element can be included in field 657 for MAP Status with value 5. The data fields are made of an Element ID Extension field (as defined in the standard), a Starting Target Wake Time Alignment field and a Max TWT Sessions field. The Starting Target Wake Time Alignment field contains a positive integer ‘n’ that indicates a recommended time for the start of the first TWT SP of the TWT agreement. A value of n indicates that the first start time is recommended to be an integer multiple of n + 1 TUs [i.e., (Target Wake Time) mod (n + 1) = 0], The Max TWT Sessions field contains the maximum number of TWT sessions that any AP is capable of establishing with a peer AP of the MAP group, in other words the maximum number of TWT sessions for the group. Figure 6g illustrates the format of a ‘Neighbor Report (NR)’ element according to 802.11 REVme / D4.0 to report about a neighbouring AP. This element can be included in field 657 for MAP Status with value 3 or 6 or 8. For MAP Status with 8, the detected capable STA can be a Proxy STA. In this case, Proxy STA can include Neighbor Report which includes the information of neighbour AP(s) that the Proxy STA had detected. This element thus describes an AP that is (capable of) operating in a MAP group. The data fields are made of a BSSID field, a BSSID Information field, an Operating Class field, a Channel Number field, a PHY Type field and an Optional Subelements field. The value of the BSSID field is the BSSID of the BSS being reported. The subsequent fields in the Neighbor Report element pertain to this BSS. The BSSID Information field can be used to help determine the offered service set. It includes multiple subfields as shown in the Figure, wherein: the AP Reachability subfield may be used to indicate whether the AP identified by this BSSID is reachable by the AP that requested the present MAP report (i.e., that includes the NR element). For example, the AP identified by this BSSID may be reachable for the exchange of registration frames for the sake of joining the MAP group. The Capabilities subfield contains selected capability information for the AP identified by this BSSID: the 1 -bit subfields within this subfield have the same meaning as in the standard and are set to the same values as the equivalent bits within the Capability Information field being sent in the Beacon frames by the AP being reported. Therefore, one of the reserved fields B4 or B5 can be used to indicate MAP capability. Alternatively, any bit B21-B31 of the BSSID Information field can be considered instead. Figure 6h illustrates the format of a ‘Reduced Neighbor Report (RNR)’ element to report about neighbouring APs. In the standard, it is usually present in Beacon, Probe Response or FILS Discovery frames. It contains channel and other information related to neighbour APs, including the so-called “reported APs” in the context of Multi-link environment as per the 802.11 be standard version. This element can be included in field 657 for MAP Status with value 6 or 8. For MAP Status with 8, the detected capable STA can be a Proxy STA. In this case, Proxy STA can include Reduced Neighbor Report which includes the information of neighbour AP(s) that the Proxy STA had already detected. The data fields are made of a Neighbor AP information Fields field containing a set of one or more (“n" in the example of the Figure) Neighbor AP Information fields, each providing elements or network information about a neighbour or “reported” AP different from the reporting AP (AP sending the RNR element). In a preferred embodiment where multiple APs are reported by the RNR element, BSSID Address / MAP Group ID field 651 does not contain a BSSID value but rather a wildcard value or a MAP Group ID. Each Neighbor AP Information field comprises a TBTT Information Header subfield, an Operating Class subfield, a Channel Number subfield and a TBTT Information Set subfield, all related to a given operating channel. The TBTT Information Set subfield may include a bunch (1..p) of TBTT Information fields, each reporting a given AP operating in class / channel as specified. As the NR element shown in Figure 6g, the RNR element shown in Figure 6h may consider that a bit within the TBTT Information field can be used to signal MAP capability of the corresponding neighbour or “reported” AP. For example, the support of MAP capability may be provided in the RNR element via bit B7 of the BSS Parameters subfield. As RNR is a common tool used for reporting presence of a remote AP along with its capabilities, a reported AP in a MAP Event report according to the present disclosure may easily use a received RNR and include it in an event report in element 657. Therefore, the use of bit B7 may also be used to signal MAP support by remote APs when it is present in Beacon, Probe Response or FILS Discovery frames. In variants, the MAP support signalling may be conveyed by defining a new type of TBTT Information. For example, the Neighbor AP Information field may include a TBTT Information Field Type field (in the TBTT Information Header field) set to a value indicating a Multi-AP operation support for an AP-to-AP communication. Such setting allows APs receiving the RNR element to quickly identify the APs supporting the MAP protocol, hence possibly ad hoc networks such as MAP groups. In a general way, a frame can thus be provided that comprises a Reduced Neighbor Report, RNR, element having at least one Neighbor AP Information field, wherein the TBTT Information Field Type field in the TBTT Information Header field of the Neighbor AP Information field is set to a value defining a support of Multi-AP for AP-to-AP communication. Values 0 and 1 for the TBTT Information Field Type field are already used in the standard. Hence, any other value, 2 or 3, may be used. Figure 6i illustrates the format of MAP Capabilities element to report the MAP capabilities of the detected AP or non-AP STA. This element can be included in field 657 for MAP Status with value 6 or 8. According to this invention, at least 2-bit Forwarding capability may be included in the MAP Capabilities information field that indicates the forwarding capability of the detected AP or non-AP STA. These 2 bits may be assigned as follows but not limited to this: 00 (not supported), 01 (Relay STA supported), 10 (Proxy STA supported), 11 (Both Relay STA and Proxy STA supported). Provided this capability information, Requesting AP can know which forwarding capability is supported in the detected AP or non-AP STA and determine which Event Request / Response frame (i.e., Multihop MAP Event Request / Response frame or MAP Event Request / Response Frame) it should send. Any other capability information (not illustrated) relevant to MAP may be indicated in this MAP Capabilities element. If the Event Report is embedded in a GAS Query response for Advertisement Protocol (“Multi-AP Query protocol” as per Figure 4b) or another Public Action frame or Multihop Action frame, one may consider embedding the whole MAP Event Report element 360 or at least subfields of this element making the response identifiable (this means including at least an Event Type field 364, an Event Report Status field 365 and the Event report 650). Figures 7a and 7b illustrate, using flowcharts, an exemplary MAP Event management procedure according to embodiments, respectively at a requesting AP and responding (or reporting) AP. The frame exchanges involve the MAP event reporting according to the present disclosure to provide information to the APs to create or join the MAP group. First, an AP has to discover one (or more) remote AP that is able to support the MAP group operations and also the MAP event reporting. This is step 700. This can be seen as a scanning procedure that allows the first AP (requesting AP) to search for a (or more) candidate AP that has MAP capability. One way to do so is a passive scanning method using the Beacon frames transmitted by the remote AP (or APs), which Beacon frames include the information capability of MAP support. For example, an RNR element as described above can be used to inform of the MAP capability (e.g., in bit B7 of the BSS Parameters subfield). Another way to do so is an active scanning method, wherein the first AP first transmits a Probe Request frame (including its own MAP capability indication in order to filter answers) and then receives (in response) a (or more) Probe Response frame including an identification of the second AP (or APs) and information capability of MAP support by the second AP(s). Again, a RNR element can be present in the Probe Response frame. Once a MAP-capable second AP is detected, the first AP issues a MAP Event Request frame to it. Thus, the first AP becomes a requesting AP and the second AP a reporting AP. At step 701, the requesting AP transmits the MAP Event Request frame 410 to the reporting AP. In embodiments, the Event Request elements 303 of the MAP Event Request frame 410 does not include any event request in field 325 (field 325 can even be omitted), and just stipulates an Event Type 330 set to Multi-AP protocol (value 6). The reporting AP receiving (step 720) the MAP Event Request frame 410 processes it at step 721. The reporting AP confirms a Dialog Token field, an Event Token field, and an Event Request field included in the received MAP Event Request frame 410 and then determines how to process the frame by checking the Event Type that must be equal to value 6, standing for Multi-AP protocol (if different from 6, the algorithm ends). When the received Event Request frame 410 does not include any Event Request field 325 (or it is empty), the reporting AP determines the latest event information (as logged, if any) available before receiving the MAP Event Request frame in order to build the MAP Event Report elements related to MAP. Once the Event Report elements have been prepared, the reporting AP transmits (still step 721) them via reporting frame 411 to the requesting AP. Later on, some MAP-related information can be received by the reporting AP (step 722). For example, management frames may be received from other APs that are indicative of MAP support by those other APs. Alternatively or in combination, any information relative to an existing MAP operation can be considered as significant for building a MAP event report: e.g., admission of new AP(s) in the MAP group, setup or deletion of a TWT session, etc. All the events mentioned above with respect to Figure 5a are exemplary events to be reported. Each AP supporting such a MAP event logs (possibly up to a maximum number) the last MAP events occurring (the most recent). Preferably, when a MAP group is initiated, an AP logs and records the TSF time of the MAP group. When a MAP group is terminated, an AP logs the MAP event including the connection time for the terminated MAP group and deletes any other event for the now-ended MAP group from the log. This is to report only valuable information. At step 724, a MAP Event Report frame 411 is emitted by the reporting AP and received (step 702) by the requesting AP. Next, the requesting AP determines (step 703) which MAP-related action to take given the reported events. For example, it may decide to create a new MAP group, or to join an existing MAP group that is reported. In some embodiments, where the requesting AP focuses on a given MAP group, it may issue a new MAP Event Request frame 410 (step 704) that is related to a given AP. As an example, MAP Event Request subelement 600 may be set to the AP Address of the given AP, in order to be reported on whether this AP joined a MAP group or be set to a MAP group ID in order to be reported on whether the given AP joined the MAP group. The requesting AP thus expects receiving regular MAP Event Report frames 411 corresponding to Event status values set to 2 to 5, orto 7. Steps 701 or 704 may be performed by the requesting AP when it experiences interferences in its neighbourhood. Indeed, the process helps it to find some cooperative APs to establish a MAP coordination though a MAP group. Figure 7c illustrates, using a flowchart, a MAP reporting procedure in case of MLD, according to embodiments. A reporting AP receives (step 750) a MAP Event Request frame 410 on one of its multiple links. It starts (step 751) monitoring the MAP events on all its links, including at least the active ones but preferably also the disabled ones (i.e., those with no active transmission). Any MAP event is logged in memory at step 723. Finally, a reporting frame 411 including one or more logged MAP events (possibly depending on a requested type) is conveyed on the original link on which the requesting AP operates (the link where the request, if any, was sent). In this context, reporting frames 411 may be exchanged on a distinct link that the one on which the MAP operation can take place. Hence, the reporting frames can also contain an identification of that link. Thanks to this information, the requesting AP may decide to switch its operating link to the identified link, or a requesting AP MLD may setup an active link for MAP operation on the identified link. As a result, the proposed MAP Reporting procedure advantageously provides a large MAP Event Report coverage in wireless bands, and ease the discovery of operational band(s) or link(s) where the interferences would impact less the communications. Figures 8a, 8b and 8c illustrate, using flowcharts, an exemplary MAP Event management procedure according to embodiments, respectively at a requesting AP, Relay STA and responding (or reporting) AP. The frame exchanges involve the MAP event reporting according to the present disclosure to provide information to the APs to create or join the MAP group. First, an AP has to discover one (or more) Relay STA that is able to support the MAP group operations and also the MAP event reporting with the support of Relay STA capability. This is step 800. This can be seen as a scanning procedure that allows the first AP (requesting AP) to search for a (or more) candidate STA that has Relay STA capability. One way to do so is to send a broadcasted MAP Event Request frame with the MAP Capabilities MAP Event Request Subelement indicating Forwarding capability as 01 to ask the recipients to send the MAP Event Report frame back if they support the Relay STA capability. AP may send this MAP Event Request frame on one or more of its operating channels. If the first AP already knows some specific MAC addresses of the surrounding STAs by any means, it can send an individual MAP Event Request frame to each STA instead. In the other embodiment, Relay STA may send an unsolicited MAP Event Report Frame (as well as illustrated in Figure 4f for the Proxy STA) to the Requesting AP without receiving a request frame from the Requesting AP. Relay STA may indicate its capability of Relay STA function by including the Forwarding capability shown in Figure 6i as 01 or 11 included in the MAP Event Report frame with MAP status set to STA capable detected (value 8). Once a Relay STA-capable STA is detected, the first AP issues a Multihop MAP Event Request frame to it. Thus, the first AP becomes a Requesting AP and the other AP over the Relay STA becomes Reporting AP. At step 801, the requesting AP transmits the Multihop MAP Event Request frame 410b to the Relay STA. In embodiments, the Event Request elements 303 of the MAP Event Request frame 410b does not include any event request in field 325 (field 325 can even be omitted), and just stipulates an Event Type 330 set to Multi-AP protocol (value 6). The Relay STA receiving (step 840) the Multihop MAP Event Request frame 410b processes it at step 841. During this step, the Relay STA converts the address fields as already described and forwards the frame as Multihop MAP Event Request Frame 412b to Reporting AP. Relay STA may verify all the Subelements included in the Event Request element and determine not to relay in any invalid case. Otherwise, Relay STA may not verify any Subelements and just simply forward it. The reporting AP receiving (step 820) the MAP Event Request frame 412b processes it at step 821. The reporting AP confirms a Dialog Token field, an Event Token field, and an Event Request field included in the received MAP Event Request frame 412b and then determines how to process the frame by checking the Event Type that must be equal to value 6, standing for Multi-AP protocol (if different from 6, the algorithm ends). When the received Event Request frame 412b does not include any Event Request field 325 (or it is empty), the reporting AP determines the latest event information (as logged, if any) available before receiving the MAP Event Request frame in order to build the MAP Event Report elements related to MAP. Once the Event Report elements have been prepared, the reporting AP transmits (still step 821) them via reporting frame 413b to the Relay STA. The Relay STA receiving (step 842) the Multihop MAP Event Report frame 413b processes it at step 843. During this step, the Relay STA converts the address fields as already described and forwards the frame as Multihop MAP Event Report Frame 411 b to Requesting AP. Relay STA may verify all the Subelements included in the Event Report element and determine not to relay in any invalid case. Otherwise, Relay STA may not verify any Subelements and just simply forward it. Later on, some MAP-related information can be received by the reporting AP (step 822). For example, management frames may be received from other APs that are indicative of MAP support by those other APs. Alternatively, or in combination, any information relative to an existing MAP operation can be considered as significant for building a MAP event report: e.g., admission of new AP(s) in the MAP group, setup or deletion of a TWT session, etc. All the events mentioned above with respect to Figure 5a are exemplary events to be reported. Each AP supporting such a MAP event logs (possibly up to a maximum number) the last MAP events occurring (the most recent). Preferably, when a MAP group is initiated, an AP logs and records the TSF time of the MAP group. When a MAP group is terminated, an AP logs the MAP event including the connection time for the terminated MAP group and deletes any other event for the now-ended MAP group from the log. This is to report only valuable information. At step 824, a Multihop MAP Event Report frame 413b is emitted by the reporting AP and received (step 842) by the Relay STA. The Relay STA again forwards the frame as Multihop MAP Event Report frame 411b which is received (step 802) by the Requesting AP. Next, the requesting AP determines (step 803) which MAP-related action to take given the reported events. For example, it may decide to create a new MAP group, or to join an existing MAP group that is reported. In some embodiments, where the requesting AP focuses on a given MAP group, it may issue a new Multihop MAP Event Request frame 410b (step 804) that is related to a given AP. As an example, MAP Event Request subelement 600 may be set to the AP Address of the given AP, in order to be reported on whether this AP joined a MAP group or be set to a MAP group ID in order to be reported on whether the given AP joined the MAP group. The requesting AP thus expects receiving regular Multihop MAP Event Report frames 411b corresponding to Event status values set to 2 to 5, or to 7. Steps 801 or 804 may be performed by the requesting AP when it experiences interferences in its neighbourhood. Indeed, the process helps it to find some cooperative APs and STAs to establish a MAP coordination though a MAP group. Figures 9a and 9b illustrate, using flowcharts, an exemplary MAP Event management procedure according to embodiments, respectively at a requesting AP and Proxy STA. The frame exchanges involve the MAP event reporting according to the present disclosure to provide information to the APs to create or join the MAP group. First, an AP has to discover one (or more) Proxy STA that is able to support the MAP group operations and also the MAP event reporting with the support of Proxy STA capability. This is step 900. This can be seen as a scanning procedure that allows the first AP (requesting AP) to search for a (or more) candidate STA that has Proxy STA capability. One way to do so is to send a broadcasted MAP Event Request frame with the MAP Capabilities MAP Event Request Subelement indicating Forwarding capability as 10 to ask the recipients to send the MAP Event Report frame back if they support the Proxy STA capability. AP may send this MAP Event Request frame on one or more of its operating channels. If the first AP already knows some specific MAC addresses of the surrounding STAs by any means, it can send an individual MAP Event Request frame to each STA instead. In the other embodiment, as shown in Figure 4h, Proxy STA may send an unsolicited MAP Event Report Frame to the Requesting AP without receiving a request frame from the Requesting AP. Proxy STA may indicate its capability of Proxy STA function by including the Forwarding capability shown in Figure 6i as 10 or 11 included in the MAP Event Report frame with MAP status set to STA capable detected (value 8). Once a Proxy STA-capable STA is detected, the first AP issues a MAP Event Request frame to it. Thus, the first AP becomes a Requesting AP and the other AP over the Proxy STA which can be more than one becomes Reporting AP(s). At step 901, the requesting AP transmits the MAP Event Request frame 41 Octo the Proxy AP. In embodiments, the Event Request elements 303 of the MAP Event Request frame 410c does not include any event request in field 325 (field 325 can even be omitted), and just stipulates an Event Type 330 set to Multi-AP protocol (value 6). The Proxy STA receiving (step 920) the MAP Event Request frame 410c processes it at step 921. The Proxy STA confirms a Dialog Token field, an Event Token field, and an Event Request field included in the received MAP Event Request frame 410c and then determines how to process the frame by checking the Event Type that must be equal to value 6, standing for Multi-AP protocol (if different from 6, the algorithm ends). When the received Event Request frame 410c does not include any Event Request field 325 (or it is empty), the reporting AP determines the latest event information (as logged, if any) available before receiving the MAP Event Request frame in order to build the MAP Event Report elements related to MAP. Once the Event Report elements have been prepared, the reporting AP transmits (still step 921) them via reporting frame 411c to the requesting AP. During the process step in 921, Proxy STA may further send one or more MAP Event Request Frame (included in the Process Event 412c) to solicit latest reports from one or more Reporting APs. Later on, some MAP-related information can be received by the Proxy STA (step 922). For example, management frames may be received from other APs that are indicative of MAP support by those other APs. Alternatively, or in combination, any information relative to an existing MAP operation can be considered as significant for building a MAP event report: e.g., admission of new AP(s) in the MAP group, setup or deletion of a TWT session, etc. All the events mentioned above with respect to Figure 5a are exemplary events to be reported. During step 922, Proxy STA may further process the received information to convert the information appropriately. For example, when the Reporting AP reports an MAP Event Report indicating the TWT session active (value 5 of MAP Status), it may forward this MAP Event Report to the requesting AP. In particular, at least one converted parameter value corresponds to a parameter representing clock, information applicable to the second BSS. If there is no common time reference between Reporting AP and Requesting AP, Proxy STA may convert the time information by applying the TSF offset between Reporting AP and Requesting AP before forwarding the information. This can be achieved by the Proxy STA since it exists in the wireless range of both Reporting AP and Requesting AP. Since the Proxy STA can receive beacons from both APs, Proxy STA can calculate the TSF offset between two APs. Each Proxy STA supporting such a MAP event logs (possibly up to a maximum number) the last MAP events occurring (the most recent). Preferably, when a MAP group is initiated, a Proxy STA logs and records the TSF time of the MAP group. When a MAP group is terminated, a Proxy STA logs the MAP event including the connection time for the terminated MAP group and deletes any other event for the now-ended MAP group from the log. This is to report only valuable information. At step 924, a MAP Event Report frame 411c is emitted by the Proxy STA and received (step 902) by the requesting AP. Next, the requesting AP determines (step 903) which MAP-related action to take given the reported events. For example, it may decide to create a new MAP group, or to join an existing MAP group that is reported. In some embodiments, where the requesting AP focuses on a given MAP group, it may issue a new MAP Event Request frame 410c (step 904) that is related to a given AP. As an example, MAP Event Request subelement 600 may be set to the AP / STA Address of the given AP or STA, in order to be reported on whether this AP or STA joined a MAP group or be set to a MAP group ID in order to be reported on whether the given AP or STA joined the MAP group. The requesting AP thus expects receiving regular MAP Event Report frames 411c corresponding to Event status values set to 2 to 5, or to 7 or 8. Steps 901 or 904 may be performed by the requesting AP when it experiences interferences in its neighbourhood. Indeed, the process helps it to find some cooperative APs and STAs to establish a MAP coordination though a MAP group. When Requesting AP receives an Event Report with from Relay STA (in step 802) or Proxy STA (in step 902), these reports may report the admission of new AP / STA 560 or leaving of AP / STA 565 by setting the MAP Status value 3 and 2 respectively. Receiving such reports, Requesting AP should manage the AP / STA list with a graph-based structure. For example, when STA 113c reports the admission of new AP 120c and AP 130c to the Requesting AP 110c, AP 110c creates the AP / STA list as shown in Figure 10a. Then, another STA 111c joins the MAP group and reports the AP 120cto AP 110c as well. Requesting AP 11 Octhen updates the AP / STA list as shown in Figure 10b. Next, STA 113c may be out of MAP group by any means such as reporting the leaving by MAP Event Report with MAP Status value 2 or periodical keep alive frame exchange fails between Requesting AP 110c and STA 113c etc. In this case, AP 110c updates the AP / STA list as shown in Figure 10c. It is worth to note that since AP 130c was managed only under STA 113c, leaving of STA 113c means leaving of AP 130c too. On the other hand, since AP 120c was managed also under STA 111c which is still alive, AP 120c remains in the list even if STA 113c is left. Reporting AP such as AP 130c and AP 120c should also maintain the graphbased AP / STA list as well to know the MAP group structure. In a situation such as shown in Figure 10b, AP 110c may select one of the STA 113 of STA 111c to forward the report regarding the AP 120c. Requesting AP 110c can do this selection by sending the (Multihop) MAP Event Request frame including the AP / STA Address subelement 600-b in the Event Request element. For example, AP 110c sends the MAP Event Request frame with the BSSID of AP 130c in the AP / STA Address subelement to STA 113c. This enforces the STA 113c to report only the MAP events related to AP 130c. The MAP events related to AP 120c will be reported via STA 111c. One can envisage that AP 110c may use the RSSI information (one between the Requesting AP 110c and the intermediate STA 111 c or STA 113c and / or the one between intermediate STA 111c or STA 113c and Reporting AP 120c or AP 130c) or the workload of intermediate STA 111 c or STA 113c to decide the selection. 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 1a, 1b and 1c. The communication device 1100 is an AP able to participate to a Multi-AP set. The communication device 1100 may preferably be a device such as a microcomputer, a workstation or a light portable device. The communication device 1100 comprises a communication bus 1113 to which there are preferably connected: a central processing unit 1101, such as a processor, denoted CPU; a memory 1103 for storing an executable code of methods or steps of the methods according to embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the methods; and at least one communication interface 1102 connected to a wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards or Wi-Fi alliance protocols, via transmitting and receiving antennas 1104. Preferably the communication bus provides communication and interoperability between the various elements included in the communication device 1100 or connected to it. The representation of the bus is not limiting and in particular the central processing unit is operable to communicate instructions to any element of the communication device 1100 directly or by means of another element of the communication device 1100. The executable code may be stored in a memory that may either be read only, a hard disk or on a removable digital medium such as for example a disk. According to an optional variant, the executable code of the programs can be received by means of the communication network, via the interface 1102, in order to be stored in the memory of the communication device 1100 before being executed. In an embodiment, the device is a programmable apparatus which uses software to implement embodiments of the invention. However, alternatively, embodiments of the present invention may be implemented, totally or in partially, in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). Figure 11b is a block diagram schematically illustrating the architecture of the communication device 1100, adapted to carry out, at least partially, the invention. As illustrated, device 1100 comprises a physical (PHY) layer block 1123, a MAC layer block 1122, and an application layer block 1121. The PHY layer block 1123 (here an 802.11 standardized PHY layer) has the task of formatting, modulating on or demodulating from any 20MHz channel or the common communication channel, and thus sending or receiving frames over the wireless radio medium used, such as 802.11 frames, for instance MAC data and management frames based on a 20MHz width to interact with legacy 802.11 stations (non-AP, AP, non-AP MLD, AP MLD), as well as of MAC data frames of OFDMA type having smaller width than 20MHz legacy (typically 2 or 5 MHz) to / from that radio medium. The MAC layer block or controller 1122 preferably comprises a MAC 802.11 layer 1124 implementing conventional 802.11 be MAC operations, and additional block 1125 for carrying out, at least partially, the invention. The MAC layer block 1122 may optionally be implemented in software, which software is loaded into RAM 1103 and executed by CPU 1101. The MAC 802.11-layer 1124 may implement an Upper-MAC stack along with a series of Lower-MAC modules. Preferably, the additional block 1125, referred to as multi-AP reporting 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 overtime, the additional block 1125 is preferably designed to selectively perform the different operations. For instance, and not exhaustively, operations for the communication device 1100 acting as an AP or AP MLD include: exchanging request and reporting frames 410 / 411 such as MAP Event Report and Request frames, providing MAP capability information elements in Beacon frames or Probe Response frames, e.g. via NR or RNR element, determining MAP Event Request subelement(s) suitable for the MAP group discovery or operation, monitoring MAP events according to a received MAP Event request; providing MAP status and Optional elements for MAP Event Reports with regard to logged events. MAC 802.11 layer 1124 and multi-AP reporting managing module 1125 interact one with the other in order to process accurately communications over the medium, e.g. over single-user or OFDMA RUs addressed to multiple stations according to embodiments of the invention. On top of the Figure, application layer block 1121 runs an application that generates and receives data packets, for example data packets such as a video stream. Application layer block 1121 represents all the stack layers above MAC layer according to ISO standardization. Figure 12 illustrates a general flow chart corresponding to a particular embodiment of the method object of the present invention. This particular flowchart is disclosed throughout the description of figures 1 to 11 and serves from an abstract perspective. 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. Many further modifications and variations will suggest themselves to those versed in the art upon referring to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

1. A communication method in a wireless network, said network comprising a first Basic Service Set (BSS) managed by a first access point (AP), a second BSS managed by a second AP and an intermediate station (STA) in wireless range of the first and the second APs, the communication method comprising:receiving, by the STA, a first multi-AP (MAP) coordination frame from the first AP managing the first BSS; andsending, by the STA, a second MAP coordination frame to the second AP managing the second BSS.

2. The method of claim 1, which further comprises a step of converting, by the STA, at least one parameter value representative of an operating context of the first BSS in the first MAP coordination frame into a parameter value representative of an operating context of the second BSS in the second MAP coordination frame.

3. The method according to claim 2, in which the at least one converted parameter value corresponds to a parameter representing clock information applicable to the second BSS.

4. The method according to claim 3, in which:during the step of receiving, the first MAP coordination frame identifies a Target Wake Time, TWT schedule provided in the first BSS;during the step of converting, the timing information of the received TWT schedule in the first BSS that is based on a first clock applicable to the first BSS is converted into timing information based on a second clock applicable to the second BSS; andduring the step of sending, the second MAP coordination frame sent identifies a Target Wake Time, TWT, schedule in the second BSS based the converted timing information.

5. The method according to any one of claims 2 to 4, in which:during the step of receiving, the first MAP coordination frame identifies a target address in the first BSS;during the step of converting, the target address in the first BSS is converted into a target address in the second BSS in the second MAP coordination frame; andthe step of sending is executed as a function of the converted target address in the second MAP coordination frame.

6. The method according to any one of claims 1 to 5, in which at least one MAP coordination frame is a frame which is formatted to be exchanged, between STA and AP, in an association-less state.

7. The method according to claim 6, in which the STA and at least one AP are in association state, wherein at least one MAP coordination frame exchanged between the STA and said at least one AP is a frame which is formatted to be exchanged, between STA and AP, in an association-less state.

8. The method according to any one of claims 6 or 7, in which at least one MAP coordination frame is at least one of:a WNM action frame;a generic advertisement service frame;a frame inside the established pre-association security negotiation;a pre-association wireless network management frame; and / ora public action frame.

9. The method according to any one of claims 1 to 8, which comprises a step of transmitting a discovery request, by the first AP associated with the first BSS, to the STA, representing a request to identify the second AP managing the second BSS which the STA can communicate with.

10. The method according to claim 9, which comprises a step of assessing, by the first AP associated with the first BSS, the existence of the second AP associated with the second BSS, the step of transmitting a discovery request being performed if the existence of the second AP is assessed.

11. The method according to any one of claims 1 to 10, which comprises a step of transmitting an unsolicited MAP coordination response from the STA without said STA receiving a MAP coordination request from the first AP.

12. The method according to any one of claims 1 to 11, which comprises a step of configuring the STA in either a relay mode or a proxy mode, in which:in a relay mode, the STA sends each frame received to and from the first and / or second APs; andin a proxy mode, the STA manages MAP events with the first AP to conclude an information exchange and, when the information exchange is concluded, sends a MAP coordination report to the second AP.

13. The method according to claim 12, which comprises a step of negotiating between a STA and an AP to determine if the STA is to be configured in relay mode or in proxy mode, the step of configuring being performed as a function of the result of the step of negotiating.

14. The method according to any one of claims 1 to 13, in which at least one MAP coordination frame comprises a multi-hop action frame comprising an Event Request element, representative of a request for an Event Report element, and an Event Report element according to the 802.11 standard family, which comprises MAP-related information.

15. A Wireless network, said network comprising a first Basic Service Set (BSS) managed by a first access point (AP), a second BSS managed by a second AP and an intermediate station (STA) in wireless range of the first and the second APs, the STA comprising:a receiver of a MAP coordination frame from the first AP managing the first BSS; and an emitter of a MAP coordination frame to the second AP managing the second BSS.

16. A multi-hop action frame, which comprises an Event Request element, representative of a request for an Event Report element, and an Event Report element, according to the 802.11 standard family, which comprises MAP-related information.

17. 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 according to any one of claims 1 to 14,18. A wireless communication device comprising at least one microprocessor configured for carrying out the method according to any one of claims 1 to 14.

Images