Methods and devices for event coordination in multi-AP operation

Abstract

Proposed multi-AP (MAP) mechanisms allowing neighbouring APs to share resources, in terms of frequency, time and spatial resources, in a way which prevents interference from occurring. The scope of th

Description

FIELD OF THE INVENTION The present invention generally relates to wireless communications and more specifically to coordination in multi-AP operations. BACKGROUND OF THE INVENTION Wireless communication networks are widely deployed to provide various communication services such as voice, video, packet data, messaging, broadcast, etc. These wireless networks may be multiple-access networks capable of supporting multiple users by sharing the available network resources. Examples of such multiple-access networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA (OFDMA) networks, and Single-Carrier FDMA (SC-FDMA) networks. In dense multiple AP networks, co-channel interference between BSSs (Basic Service Sets) 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 For example, in a dense deployment scenario where neighbouring BSSs corresponding to two or more APs overlap each other, if one AP (belonging to a MAP coordinated group or MAP coordination set of APs) has an R-TWT schedule for which the corresponding scheduled STAs fall in a geographic area that overlaps a neighbour BSS (of the same MAP group), then the R-TWT scheduled STAs possibly face interferences with neighbouring BSS's operation. 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 UHR Study Group, a study group in charge of defining the scope of the successor of the 802.11 be Task Group, namely the 802.11 bn Task group. The scope of the MAP topic is extended to optimized coordination, not only regarding shared transmissions but also regarding alternative mechanisms for OBSS Interference reduction. In otherwords, 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 UHR group seek to coordinate MAP with the Restricted Target Wake Time (R-TWT) procedure, in order to obtain service periods offering OBSS interference avoidance and transmission sharing in between the BSSs of the MAP coordinated group, i.e. MAP coordination set of APs. The MAP coordination is willing to optimize operations during the R-TWT service period to limit those issues. 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, 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). 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), RSNA 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 this context, embodiments provide a communication method in a wireless network comprising, at a first access-point, AP of a first BSS: obtaining multi-AP, MAP,-related information about a MAP Coordination Set, and sending, to a second AP of a second BSS, a frame including an Event Report element according to the 802.11 standard family that comprises the obtained MAP-related information. The MAP-related information describes information that concerns a communication group of APs, either already existing or to be created. The 802.11 Event Reporting procedure is therefore extended to MAP management by the use of the Event Report element to provide MAP-related information. Reusing existing elements advantageously simplifies the extension of the existing standard to new mechanisms. Correspondingly, a communication method in a wireless network is also provided that comprises, at a second access-point, AP of a second BSS: receiving, from a first AP of a first BSS, a frame including an Event Report element according to the 802.11 standard family that comprises multi-AP, MAP,-related information, and taking a MAP-related action based on the received MAP-related information to the effect of performing MAP coordination. Optional features are defined below with reference to methods, while they can be transposed into device features. In some embodiments, the first and second APs do not belong yet to the same MAP coordination set or even to any MAP coordination set. The invention can allow them to discover their respective capabilities with a view of creating or joining together an AP group. In variants, the first and second APs belong to the same MAP coordination set. The invention thus allows the APs to manage collectively the MAP coordination set during its lifetime. In some embodiments, the Event Report element includes an Event Type field set to a value comprised between 6 and 220, in particular value 6. Of course, value 7, 8, 9, 10 or higher up to 220 can be used instead to identify a MAP Event Report element. This allows the APs to directly identify MAP Event reports in received reporting frames. In some embodiments, the Event Report element includes an event report having fields conforming to the field format of a peer-to-peer link event report according to IEEE P802.11REVme MAP Event Reports, wherein one or more fields are personalized to MAP operation, “conforming to the field format” means that the same number of fields is provided with the same field lengths. The first subfield may be set to a BSSID MAC address of a MAP Coordination Set identifier. The sixth subfield about status is set to report a current status of the MAP Coordination Set. For example, the status may be set to one of the following values: MAP group terminated (meaning an end of the MAP Coordination Set is reported), MAP group creation (meaning a creation of such a Set is reported), MAP group membership terminated (meaning a leaving of an AP from the MAP Coordination Set is reported), MAP group membership active (meaning the joining of a new AP to the MAP Coordination Set is reported), TWT session terminated (meaning the end of a TWT session coordinated within the MAP Coordination Set is reported), TWT session active (meaning the start / creation of a TWT session coordinated within the MAP Coordination Set is reported), AP-capable detected (meaning an isolated neighboring AP not yet including in the Set is reported), Operating channel switch (meaning a change in operating channel of the MAP Coordinated Set is reported). Reusing the peer-to-peer link event report format for MAP purposes advantageously avoids introducing new formats in the standard. In specific embodiments, the Event Report element further includes an additional field (additional to the fields conforming the known peer-to-peer link event report) to include at least one of the following elements: an AP Channel Report element according to IEEE P802.11 REVme (i.e., having the same field format) to report a list of channels where the MAP Coordination Group is likely to operate. This may signal the channel or channels for an operating channel switch, an Intolerant Channel Report element to report a list of channels not recommended (even disallowed) for the MAP Coordination Set, a MAP Group ID element to report an identifier of the MAP Coordination Group and optionally a Group Address for the MAP Coordination Group, a Target Wake Time, TWT, element according to IEEE P802.11 REVme (i.e., having the same field format) to report a target wake time scheduled by at least one AP of the MAP Coordination set, a TWT Constraint Parameters element according to IEEE P802.11 REVme (i.e., having the same field format) to report constraint parameters to be used during the establishment of a target wake time by at least one AP of the MAP Coordination set, a Neighbor Report, NR, element according to IEEE P802.11 REVme to report about a neighboring AP, a Reduced NR, RNR, element according to IEEE P802.11 REVme to report about neighboring APs. This allows a reporting AP to provide more details than those that can be included in the conventional fields of the peer-to-peer link event report. In more specific embodiments, the NR or RNR element includes a capability bit for each reported neighboring AP, to define MAP capability of the respective reported neighboring AP. Such NR or RNR element can also be used by an AP in any other frame (than the reporting frame) to declare or signal its MAP capability or other AP’s MAP capability, e.g. in a Beacon frame. In this respect, embodiments of the disclosure relate to a frame comprising a neighbor report reporting about a neighboring access point, AP, wherein the neighbor report includes a field to signal whether or not the neighboring access point supports Multi-AP for AP-to-AP communication. An AP can therefore report about MAP capabilities of other APs. In embodiments, the neighbor report includes a Neighbor Report, NR, element having a BSSID Information field, at least one bit of which signaling a support of the Multi-AP for AP-to-AP communication. Available bits to provide the signaling include bits B21-B31 of the BSSID Information field and bits B4-B5 of the Capabilities subfield within the BSSID Information field (i.e. bits B8-B9 of the BSSID Information field). In other embodiments, the neighbor report includes 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 ora bit within the BSS Parameters field signals a support of Multi-AP for AP-to-AP communication. On one hand, one or more new types for the TBTT Information can define the MAP support. Alternatively, reserved bit B7 of the BSS Parameters field can be used to similar signaling of MAP support. In some embodiments, the sending of the frame including the Event Report element is responsive to receiving a request frame including an Event Request element. Such a request may be sent by the second AP upon detecting the first AP as not yet being included in the MAP Coordination Set. This allows the second AP to obtain information about the first AP that is related to the requirements of the MAP Coordination Set in order to join the first AP to the Set. In specific embodiments, the Event Request element includes an Event Type field set to a value comprised between 6 and 220, in particular value 6. Of course, value 7, 8, 9,10 or higher up to 220 can be used instead to identify a MAP Event Report element. The field in the Event Request element is preferably set to the same value as in the same field of the Event Report element. In other specific embodiments, the Event Request element does not include any event request in an Event Request field in the meaning of IEEE P802.11 REVme. This is for instance used before the MAP Coordination Set is created or joined. The requesting AP may then ask for any MAP-related event. In specific embodiments, the Event Report element includes the latest event report or reports available at the first AP at the time of receiving the request frame. This is for the requested AP to give the most recent MAP overview it has. In other specific embodiments, the request frame is an Event Request frame according to IEEE P802.11 REVme including the Event Request element. In variants, the request frame is a generic advertisement service, GAS, Initial Request frame according to IEEE P802.11 REVme including the Event Request element. In some embodiments, the sending of the frame including the Event Report element is responsive to one triggering event from the following ones: receiving a request frame including an Event Request element. ending the MAP Coordination Set, creating the MAP Coordination Set, leaving the MAP Coordination Set or detecting a leaving of an AP from the MAP Coordination Set, joining the MAP Coordination Set or detecting a joining of an AP to the MAP Coordination Set, ending a Target Wake Time, TWT, session coordinated within the MAP Coordination Set, creating a TWT session coordinated within the MAP Coordination Set, detecting an isolated neighboring AP not yet included in the MAP Coordination Set, changing an operating channel of the MAP Coordinated Set. In some embodiments, the Event Request element includes one or more MAP Event Request subelements, each made of a Subelement ID field, a Length field, and a Data field including any of: a MAP Group ID to signal an identifier of the MAP Coordination Group, an AP BSSID (BSS Identifier) field to signal an identifier of another AP of the MAP Coordination Set, an Operating Class field together with a Channel Number field to signal an operating channel of the MAP Coordination Set, a MLD Links field to signal whether an Event Report element is requested for all the links of a neighboring AP multi-link device or not. In some embodiments, the frame is an Event Report frame according to IEEE P802.11REVme including the Event Report element, i.e. a WNM frame having a WNM Action field value equal to 1. In variants, the frame is a generic advertisement service, GAS, Initial Response frame according to IEEE P802.11REVme including the Event Report element. This is a Public Action frame in the meaning of IEEE P802.11 REVme. In specific embodiments, an Advertisement Protocol element in the GAS Public Action frame is set to a value comprised between 5 and 220, in particular value 5. Of course, value 6, 7, 8, 9,10 or higher up to 220 can be used instead to identify a MAP-related GAS Public Action frame, hence including the above Event Report element. Correlatively, the invention also provides a wireless communication device comprising at least one microprocessor configured for carrying out any method as described above. Another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform any method as described above. At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium. Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal. BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 illustrates an exemplary network environment in which embodiments of the present disclosure can be implemented; Figure 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 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; Figures 7a and 7b illustrate, using flowcharts, an exemplary MAP Event management procedure according to embodiments, respectively at a requesting AP and responding AP; Figure 8a shows a schematic representation a communication device in accordance with embodiments of the present invention; and Figure 8b shows a schematic representation of a wireless communication device in accordance with 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 mu Itiple user terminals, i.e. wireless devices or stations. A TDMA system may allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units, each time slot being assigned to different user terminal. An OFDMA system utilizes orthogonal frequency division multiplexing (OFDM), which is a modulation technique that partitions the overall system bandwidth into multiple orthogonal sub-carriers or resource units. These sub-carriers may also be called tones, bins, etc. With OFDM, each sub-carrier may be independently modulated with data. An SC-FDMA system may utilize interleaved FDMA (IFDMA) to transmit on sub-carriers that are distributed across the system bandwidth, localized FDMA (LFDMA) to transmit on a block of adjacent sub-carriers, or enhanced FDMA (EFDMA) to transmit on multiple blocks of adjacent sub-carriers. The teachings herein may be incorporated into (e.g., implemented within or performed by) a variety of apparatuses (e.g., stations). In some aspects, a wireless device or station implemented in accordance with the teachings herein may comprise an access point (so-called AP) or not (so-called non-AP station or STA). An AP may comprise, be implemented as, or known as a Node B, Radio Network Controller (“RNC"), evolved Node B (eNB), 5G Next generation base station (gNB), Base Station Controller (“BSC”), Base Transceiver Station (“BTS”), Base Station (“BS”), Transceiver Function (“TF”), Radio Router, Radio Transceiver, Basic Service Set (“BSS”), Extended Service Set (“ESS”), Radio Base Station (“RBS”), or some other terminology. A non-AP station may comprise, be implemented as, or known as a subscriber station, a subscriber unit, a mobile station (MS), a remote station, a remote terminal, a user terminal (UT), a user agent, a user device, user equipment (UE), a user station, or some other terminology. In some implementations, a STA may comprise a cellular telephone, a cordless telephone, a Session Initiation Protocol (“SIP”) phone, a wireless local loop (“WLL”) station, a personal digital assistant (“PDA”), a handheld device having wireless connection capability, or some other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (e.g., a cellular phone or smart phone), a computer (e.g., a laptop), a tablet, a portable communication device, a portable computing device (e.g., a personal data assistant), an entertainment device (e.g., a music or video device, or a satellite radio), a global positioning system (GPS) device, or any other suitable device that is configured to communicate via a wireless or wired medium. In some aspects, the non-AP station may be a wireless node. Such wireless node may provide, for example, connectivity for or to a network (e.g., a wide area network such as the Internet or a cellular network) via a wired or wireless communication link. An AP manages a set of STAs (registered to it or associated with it) that together organize their accesses to the wireless medium for communication purposes. The STAs (including the AP to which they register) form a service set, here below referred to as basic service set, BSS (although other terminology can be used). A same physical STA acting as an access point may manage two or more BSS (and thus corresponding WLANs): each BSS is thus uniquely identified by a specific basic service set identification, BSSID and managed by a separate virtual AP implemented in the physical AP. Each STA is identified within a BSS thanks to an identifier, AID, assigned to it by the AP upon registration. The 802.11 family of standards define various media access control (MAC) mechanisms to drive access to the wireless medium. For example, in order to address the issue of increasing bandwidth and decreasing latency requirements that are demanded for wireless communications systems in high-density environments, multi-user (MU) schemes have been developed to allow a single access point (AP) managing a Basic Service Set (BSS) to schedule MU transmissions, i.e. multiple simultaneous transmissions to or from non-AP stations of the BSS, in the wireless network. A MU scheme has been adopted in the 802.11ax-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 signaled 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 / D3.2 of May 2023, introduce the Multi-Link Operation (MLO) when it comes to MAC layer operation. The MLO allows multi-link devices to establish or setup multiple links and operate them simultaneously. 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 1 illustrates an exemplary network environment in which embodiments of the present disclosure can be implemented. The illustrated wireless network environment comprises a multi-AP system 100 formed by a group of neighbouring wireless networks that operate over a common communication channel orwireless medium. The common communication channel may correspond to a part (e.g. 20 MHz) or all of an operating channel (e.g. 20 MHz, 40 MHz, 80 MHz, 160 MHz or 320 MHz). A first wireless network (or Basic Service Set) BSS1 comprises an access point (AP) 110 and three non-AP stations (STAs) 111, 112 and 113 associated to AP 110 (i.e. registered with it). A second wireless network BSS2 comprises an AP 120 and three associated non-AP STAs 121, 122 and 123. A third wireless network BSS2 comprises an AP 130 and three associated non-AP STAs 131, 132 and 133. In the following, BSSx represents any of the wireless networks, while 1x1, 1x2 and 1x3 any of the non-AP stations. Of course, another number of wireless networks and any number of non-AP stations per wireless network can be contemplated. In the present disclosure, APs 110, 120 and 130 are also referred to, respectively, as AP1, AP2 and AP3. A device may act as an AP of one wireless network and at the same time may belong to another wireless network as an associated STA. 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, 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). Each non-AP STA 1x1-1x3 registers to the AP 1x0 of one wireless network BSSx during an association procedure. During the association procedure over the primary channel, the AP assigns a specific Association IDentifier (AID) to the requesting station. For example, the AID is a 16-bit value uniquely identifying the station. The stations (including the AP) compete one against 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 (STA) for improving power efficiency. With TWT operation, a STA has only to wake up at a prescheduled time negotiated with another 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 / D3.0, April 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 / D3.0, April 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 / D3.0, April 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 / D3.0, April 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 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 is 0. 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 1 depicting multiple APs, a Multi-AP (MAP) technology has emerged where the APs 110,120, 130 collaborate to share the common communication channel once one of them is granted access to it. To do so, the APs exchange messages one with each other to coordinate the MAP communications, and thus to avoid interference that may result from an overlapping of their respective BSSs (hence known as Overlapping BSSs, orOBBSs). 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 may be part of an inter-AP coordination group or “MAP coordination set” of APs or “AP group” below, the formation of which is not yet defined by IEEE 802.11 standard. One may envisage that the APs willing to collaborate previously issues management frames, like beacons or dedicated broadcasted frames, to advertise the other APs 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, 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 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, 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 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 neighboring AP not yet included in the MAP Coordination Set, a change of an operating channel of the MAP Coordinated Set. The AP may then share this information with the other APs, 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, 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 this perspective, Figure 4 illustrates, using frame exchanges in a timeline, a MAP Event reporting procedure according to some embodiments, as a new type of Multi-AP Network Management procedure 400. A requesting STA (that is an AP as 110) transmits an event request frame 410 to a requested STA ora reporting STA (that is an AP 120). 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 forthe 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 110 and AP 120 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 110 and AP 120 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 requesting and reporting APs exchange inter-BSS frames with each other, typically a MAP Event Request and Report which are exchanged in single-user mode between both APs, as shown, for illustrative purposes, by references 410 and 411. There 802.11 frames may be exchanged overthe wireless medium shared between AP1 and AP2, or exchanged over another (wireless or wired) medium. For instance, an Ethernet backhaul may be built as an off-link or separate network between the two APs (more generally between the APs forming the MAP coordination set) for transporting such 802.11 frames conveying the MAP Event report. 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 Report element. Such a type of frame (GAS) advantageously allows the frame to be sent at destination to several APs. The generic advertisement service (GAS) relies on the use of Public Action frames. 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 / D3.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. Figure 5 illustrates, using a flowchart, general steps of embodiments of the invention, that take place at a reporting AP. The process starts for the reporting AP 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, yet belonging to the same MAP Coordination Set or not. As already mentioned above with reference to Figure 4, a first triggering event may include receiving a request frame 410 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, be it a MAP Event Request Frame or a GAS Query Request. 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 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 field to signal an identifier of another AP of the MAP Coordination Set. It is illustrated with AP Address subelement 600-b (Subelement ID value 1) that identifies a peer AP 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. It is to be noted that the concerned AP to monitor may be the requested AP (i.e., reporting AP 120 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 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 / D3.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 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 neighboring AP 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 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 eventsforany of the links of the responding AP MLD have to be reported. In some embodiments, the MLD Links field may be a bitmap signaling which links amongst the multiple links of the neighboring AP MLD have to be reported. Back to Figure 5, other triggering events than receiving request frame 410 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 in the MAP group. The triggering event thus includes joining the MAP Coordination Set or detecting a joining of another AP to the MAP Coordination Set. Exemplary state 565 corresponds to the leaving of an AP from the MAP group. The triggering event thus includes leaving the MAP Coordination Set or detecting a leaving of another AP 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 behavior of a MAP group may be reported. Hence, detecting an isolated neighboring AP 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 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 (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 generates and sends reporting frame 411 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 may be the requesting AP having sent request frame 410. In case the reporting frame 411 is sent spontaneously by the reporting AP, the addressee may include the APs 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. 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 has no logged events of a requested type (hence in case a request frame 410 is received), the reporting AP 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 behavior to 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 / 367 / 368 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. 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.1 IREVme 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 / MAP Group ID field 651 contains a BSSID MAC address (aka AP MAC address), 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, or 2-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. 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.11REVme / D3.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.11 REVme / D3.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 5b: 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 (reporting the admission or the leaving of an AP or detection of an isolated AP), 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 6h. 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 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 joined the MAP group to the time at which the reporting AP 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 6h 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.11 REVme / D3.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 / D3.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 / D3.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 / D3.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 / D3.0 to report about a neighboring AP. This element can be included in field 657 for MAP Status with value 3 or 6. 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, and equals to field 651. 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 neighboring APs. In the standard, it is usually present in Beacon, Probe Response or FILS Discovery frames. It contains channel and other information related to neighbor 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. The data fields is 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 for the RN element above, 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 tools 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 signaling 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. If the Event Report is embedded in a GAS Query response for Advertisement Protocol (“Multi-AP Query protocol” as per Figure 4b), 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 324 (field 324 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 324 (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, were 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, or to 7. Steps 701 or 704 may be performed by the requesting AP when it experiences interferences in its neighborhood. 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 disable 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. Figure 8a schematically illustrates a communication device 800 configured to implement at least one embodiment of the present invention, for instance any of AP or AP MLD shown in Figure 1. The communication device 800 is an AP able to participate to a Multi-AP set. The communication device 800 may preferably be a device such as a microcomputer, a workstation or a light portable device. The communication device 800 comprises a communication bus 813 to which there are preferably connected: a central processing unit 801, such as a processor, denoted CPU; a memory 803 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 802 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 804. Preferably the communication bus provides communication and interoperability between the various elements included in the communication device 800 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 800 directly or by means of another element of the communication device 800. 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 802, in order to be stored in the memory of the communication device 800 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 8b is a block diagram schematically illustrating the architecture of the communication device 800, adapted to carry out, at least partially, the invention. As illustrated, device 800 comprises a physical (PHY) layer block 823, a MAC layer block 822, and an application layer block 821. The PHY layer block 823 (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 822 preferably comprises a MAC 802.11 layer 824 implementing conventional 802.11 be MAC operations, and additional block 825 for carrying out, at least partially, the invention. The MAC layer block 822 may optionally be implemented in software, which software is loaded into RAM 803 and executed by CPU 801. The MAC 802.11 layer 824 may implement an Upper-MAC stack along with a series of Lower-MAC modules. Preferably, the additional block 825, 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 800. As the same device can play different roles overtime, the additional block 825 is preferably designed to selectively perform the different operations. For instance, and not exhaustively, operations for the communication device 800 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 824 and multi-AP reporting managing module 825 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 821 runs an application that generates and receives data packets, for example data packets such as a video stream. Application layer block 821 represents all the stack layers above MAC layer according to ISO standardization. Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present invention. 5 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. 10 In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

1. A communication method in a wireless network comprising, at a first access-point, AP of a first basic service set, BSS:obtaining multi-AP, MAP,-related information about a MAP Coordination Set, andsending, to a second AP of a second BSS, a frame including an Event Report element according to the 802.11 standard family that comprises the obtained MAP-related information.

2. A communication method in a wireless network comprising, at a second accesspoint, AP of a second basic service set, BSS:receiving, from a first AP of a first BSS, a frame including an Event Report element according to the 802.11 standard family that comprises multi-AP, MAP,-related information, andtaking a MAP-related action based on the received MAP-related information to the effect of performing MAP coordination.

3. The method of Claim 1 or 2, wherein the first and second APs do not belong yet to the same MAP coordination set or even to any MAP coordination set.

4. The method of Claim 1 or 2, wherein the first and second APs belong to the same MAP coordination set.

5. The method of Claim 1 or 2, wherein the Event Report element includes an Event Type field set to a value comprised between 6 and 220, in particular value 6.

6. The method of Claim 1 or 2, wherein the Event Report element includes an event report having fields conforming to the field format of a peer-to-peer link event report according to IEEE P802.11REVme MAP Event Reports, wherein one or more fields are personalized to MAP operation.

7. The method of Claim 6, wherein the Event Report element further includes an additional field to include at least one of the following elements:an AP Channel Report element according to IEEE P802.11 REVme to report a list of channels where the MAP Coordination Group is likely to operate,an Intolerant Channel Report element to report a list of channels not recommended for the MAP Coordination Set,a MAP Group ID element to report an identifier of the MAP Coordination Group and optionally a Group Address for the MAP Coordination Group,a Target Wake Time, TWT, element according to IEEE P802.11 REVme to report a target wake time scheduled by at least one AP of the MAP Coordination set,a TWT Constraint Parameters element according to IEEE P802.11 REVme to report constraint parameters to be used during the establishment of a target wake time by at least one AP of the MAP Coordination set,a Neighbor Report, NR, element according to IEEE P802.11 REVme to report about a neighboring AP,a Reduced NR, RNR, element according to IEEE P802.11 REVme to report about neighboring APs.

8. The method of Claim 7, wherein the NR or RNR element includes a capability bit for each reported neighboring AP, to define MAP capability of the respective reported neighboring AP.

9. The method of Claim 1, wherein the sending of the frame including the Event Report element is responsive to receiving a request frame including an Event Request element.

10. The method of Claim 9, wherein the Event Request element includes an Event Type field set to a value comprised between 6 and 220, in particular value 6.

11. The method of Claim 9, wherein the Event Request element does not include any event request in an Event Request field in the meaning of IEEE P802.11 REVme.

12. The method of Claim 9, wherein the Event Report element includes the latest event report or reports available at the first AP at the time of receiving the request frame.

13. The method of Claim 9, wherein the request frame is an Event Request frame according to IEEE P802.11 REVme including the Event Request element or a generic advertisement service, GAS, Initial Request frame according to IEEE P802.11REVme including the Event Request element.

14. The method of Claim 1, wherein the sending of the frame including the Event Report element is responsive to one triggering event from the following ones:receiving a request frame including an Event Request element.ending the MAP Coordination Set,creating the MAP Coordination Set,leaving the MAP Coordination Set or detecting a leaving of an AP from the MAP Coordination Set,joining the MAP Coordination Set or detecting a joining of an AP to the MAP Coordination Set,ending a Target Wake Time, TWT, session coordinated within the MAP Coordination Set,creating a TWT session coordinated within the MAP Coordination Set,detecting an isolated neighboring AP not yet included in the MAP Coordination Set,changing an operating channel of the MAP Coordinated Set.

15. The method of Claim 9 or 14, wherein the Event Request element includes one or more MAP Event Request subelements, each made of a Subelement ID field, a Length field, and a Data field including any of:a MAP Group ID to signal an identifier of the MAP Coordination Group,an AP BSSID field to signal an identifier of another AP of the MAP Coordination Set,an Operating Class field together with a Channel Number field to signal an operating channel of the MAP Coordination Set,a MLD Links field to signal whether an Event Report element is requested for all the links of a neighboring AP multi-link device or not.

16. The method of Claim 1 or 2, wherein the frame is an Event Report frame according to IEEE P802.11 REVme including the Event Report element or a generic advertisement service, GAS, Initial Response frame according to IEEE P802.11 REVme including the Event Report element.

17. The method of Claim 16, wherein an Advertisement Protocol element in the GAS Public Action frame is set to a value comprised between 5 and 220, in particular value 5.

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

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

20. A frame comprising a neighbor report reporting about a neighboring access point, AP, wherein the neighbor report includes a field to signal whether or not the neighboring access point supports Multi-AP for AP-to-AP communication.

21. The frame of Claim 20, wherein the neighbor report includes one of:a Neighbor Report, NR, element having a BSSID Information field, at least one bit of which signaling a support of the Multi-AP for AP-to-AP communication, 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 ora bit within the BSS Parameters field signals a support of Multi-AP for AP-to-AP communication.

Images