WO2025011958A1

WO2025011958A1 - Improved coexistence link information report

Info

Publication number: WO2025011958A1
Application number: PCT/EP2024/067918
Authority: WO
Inventors: Romain Guignard; Pascal Viger
Original assignee: Canon Europe Ltd; Canon Inc
Current assignee: Canon Europe Ltd; Canon Inc
Priority date: 2023-07-07
Filing date: 2024-06-26
Publication date: 2025-01-16
Anticipated expiration: 2026-01-07

Abstract

When links of a non-AP MLD become NSTR or EMLSR links and the non-AP MLD performs P2P communications or experiences OBSS interferences over one of the constrained links, it sends a Coexistence link report about the P2P session or the OBSS to the AP MLD. A Channel Usage Request frame can be used. The AP MLD may take actions to the effect of reducing scheduling for the non-AP MLD involved in the P2P session that interferes with the P2P communication or of avoiding scheduling it over the link experiencing OBSS interferences. The AP MLD may avoid scheduling downlink communication to the non-AP MLD over the other constrained link, while the P2P session is on-going on the first constrained link. Actions may also be taken by the AP MLD to release such limitations when the P2P session ends, or when the non- AP MLD become inactive with respect to the P2P session.

Description

IMPROVED COEXISTENCE LINK INFORMATION REPORT

FIELD OF THE INVENTION

The present invention generally relates to wireless communications and more specifically to Peer-to-Peer (P2P) communication.

BACKGROUND OF INVENTION

With the development of latency sensitive applications such as online gaming, real-time video streaming, virtual reality, drone or robot remote controlling, better throughput, low latency and robustness requirements and issues need to be taken into consideration. Such problematic issues are currently under consideration by the IEEE 802.1 1 working group as a main objective to issue the next major 802.11 release, known as 802.11 be or EHT for “Extremely High Throughput”.

Low latency reliable services, LLRS, have been defined as targets of such main objective. LLRSs are services provided to a higher layer traffic stream that prioritize and deliver MSDUs (data units) within a worst-case latency budget with a given reliability/packet delivery ratio (PDR) and low jitter.

The IEEE P802.11 be/D3.2 version (May 2023, below the “D3.2 standard”) introduces the Multi-link (ML) operation (MLO). MLO improves data throughput by allowing communications between stations over multiple concurrent and non-contiguous communication links.

Multi-Link Operation enables a non-AP (access point) MLD (ML device) to register with an AP MLD, i.e., to discover, authenticate, associate and set up multiple links with the AP MLD. Each link enables channel access and frame exchanges between the non-AP MLD and the AP MLD based on supported capabilities exchanged during association.

A MLD is a logical entity that has more than one affiliated station (AP or non-AP) and has a single medium access control (MAC) service access point (SAP) to logical link control (LLC), which includes one MAC data service. An AP MLD is thus made of multiple affiliated APs whereas a non-AP MLD is made of multiple affiliated non-AP stations. The affiliated stations in both AP MLD and non-AP-MLD can use 802.11 mechanisms to communicate with affiliated stations of another MLD over each of the multiple communication links that are set up.

In MLD operation, simultaneous transmit and receive (STR) operations may be allowed. That is, a MLD can transmit on one link while receiving on another link. Non-AP MLDs may be STR or non-STR (NSTR). A NSTR non-AP MLD is not able to receive on one link concurrently to transmitting on another link of a NSTR link pair.

Similarly, with the introduction of MLO and of spatial multiplexing capabilities of the MLDs, an MLD can operate according to various Enhanced Multi-Link Operating Modes (EML OMs), namely the EMLSR (Enhanced Multi-Link Single Radio) mode and the EMLMR (Enhanced MultiLink Multi-Radio) mode that are mutually exclusive. In the EMLSR mode, while a non-AP MLD can simultaneously listen to a set of enabled links (so-called EMLSR links), it can only receive and/or send data frames over only one EMLSR link at a time. Again, the non-AP MLD in the EMLSR mode is not able to receive on one link concurrently to transmitting on another link of the EMLSR links.

Therefore, the NSTR link pair or the EMLSR links are constrained links for the non-AP MLD. This may raise issue when one of the links experiences other communications, such as P2P communication from the non-AP MLD or interference from another BSS (known as Overlapping BSS or OBSS).

A similar situation exists with a P2P Concurrent Device where one MAC entity operates within an infrastructure BSS while another second MAC entity is dedicated to P2P communications.

To meet low latency requirements in EHT as well as to increase efficiency of the UL MU operation, existing mechanisms have been reused within the D3.2 standard and improved, while other new mechanisms have been added.

Exemplary mechanisms include the Target Wake Time (TWT) mechanism, the Triggered TXOP Sharing (TXS) mechanism, the Tunneled Direct Link Setup (TDLS), Software AP (or soft AP).

TDLS and Soft AP allow P2P sessions to be established, hence P2P (or Direct Link - DiL) transmissions to be performed between two peer MLDs concurrently to the existing AP-based infrastructure.

However, the coexistence between infrastructure (AP) and the P2P communications (either through TDLS or noninfrastructure BSS such as softAP or Wi-Fi Direct Group Owner) or an OBSS raises a number of issues for them to efficiently operate together.

For instance, in MLO, a non-AP MLD may use one (permanently or not) of the constrained links for P2P communication (or this link may experience interference with an OBSS) and one to communicate with its associated AP. However, due to the NSTR or EMLSR constraint, the non- AP MLD cannot freely operate which makes the coexistence between infrastructure and P2P communications difficult and more especially the scheduling by the AP of the stations involved in both types of communication. For example, a critical situation occurs when the AP MLD transmits some data to a non-AP MLD which is currently operating on the other constrained link for P2P communication and is therefore unable to receive and decode the data from the AP MLD.

Also, the various mechanisms mentioned above may raise issues. In the example of the TWT mechanism, a rTWT (restricted TWT) may be negotiated between an initiator affiliated non- AP station and an affiliated AP station. As the other peer non-AP station of the P2P session is not involved in the rTWT, it is likely that the other peer non-AP station will not awake at the time of a service period (SP) of the rTWT and therefore will not be available for TXS-based P2P communication within the rTWT SP. The TXS mechanism is known to facilitate P2P communications within a TXOP obtained by the AP, by sending a trigger frame, called MU-RTS TXS, to specify the time duration of a portion of the TXOP that is allocated to an associated non- AP station. In other words, the D3.2 standard is for the moment not satisfactory with respect to P2P or DiL (Direct Link) transmissions and infrastructure coexistence.

SUMMARY OF THE INVENTION

It is a broad objective of the present invention to overcome some of the foregoing concerns, in particular to improve coexistence of P2P transmissions with infrastructure.

In this context, a non-AP MLD experiencing NSTR or EMLSR, or more generally a non- AP device having constrained links, and taking part in a P2P session or having an OBSS in its vicinity may report to the AP MLD or AP device, in a Coexistence or P2P link report, some information about the P2P session or OBSS for the AP MLD or device to properly schedule communication in its infrastructure network (BSSs managed by its affiliated APs).

For example, a non-AP STA affiliated to the non-AP MLD may switch from a base channel of an enabled link to another channel, e.g. an off-channel, using a TDLS Channel Switch, to perform P2P communications. The AP MLD is now aware of such switch. The link may become NSTR with another link enabled between the non-AP MLD and the AP MLD, without the AP MLD being aware of this new NSTR constraint for the non-AP MLD.

Similarly, an affiliated AP may perform a Channel Switch to change its operating band, resulting in a channel/link interfering with the channel/link of the P2P session, without the AP MLD being aware of this new NSTR constraint for the non-AP MLD.

The non-AP MLD thus preferably notifies the AP MLD, using the P2P link report, about the P2P communication together with the NSTR constraint. A Channel Usage element in a frame, such as a Channel Usage Request frame, appears suitable to convey such information.

The frame may be sent over any of the two constrained links (NSTR link pair or EMLSR links), and more generally over any link enabled with the AP MLD. The Channel Usage element may comprise a link ID identifying the P2P link on which the P2P communication takes place, a NSTR bitmap identifying the other link or links constrained with the P2P link.

An identifier of the other (partner) peer non-AP station or MLD involved in the P2P communication may also be provided in the Channel Usage element for the AP MLD to also adapt its scheduling in its infrastructure network regarding the other peer non-AP station or MLD.

Other information helpful to enhance the scheduling, e.g. information about timing information regarding periods of P2P activity (e.g. P2P TWT) or of power saving in the P2P session as well as a P2P status of the P2P session (session active, session terminated), can also be provided in the Channel Usage element.

Indeed, other events, such as establishing the P2P session over constrained links or ending such P2P session, have impact on the efficiency of the communications within the infrastructure network. Actions (P2P rules) may be taken by the AP MLD to the effect of reducing scheduling of the non-AP MLD (involved in the P2P session) which interferes with the P2P communication or of avoiding scheduling it over the link experiencing interferences with the OBSS. For example, the AP MLD may avoid scheduling downlink communication to the non-AP MLD over the other constrained link, while the P2P session is on-going on the first constrained link. Actions may also be taken by the AP MLD to release such P2P rules when the P2P session ends, or when the non-AP MLD becomes inactive with respect to the P2P session (e.g. enters in power saving mode).

Embodiments thus propose a method of communication in a wireless network comprising, at a non-access-point, non-AP, device having multiple stations operating on respective links: declaring, to an AP device, transmission constraints between links of the non-AP device. Constrained links include for example EMSLR links or a NSTR link pair or links of a P2P Concurrent Device; and sending, to the AP device, a Coexistence or P2P link report about an activity, e.g. P2P session, taking place on one of the constrained links.

The activity is determined on one of the constrained links. This may for example be achieved when the non-AP device controls an affiliated non-AP station of the non-AP device to participate in a peer-to-peer, P2P, session with a peer station over the one constrained link. Exemplary P2P sessions include a TDLS session established between registered non-AP MLDs or a P2P Group established as an Independent BSS or ad hoc network thanks to a soft AP.

Correspondingly, a method of communication in a wireless network is also proposed that comprises, at an access-point, AP, device: receiving, from a non-AP device, a declaration about transmission constraints between links of the non-AP device, and a Coexistence or P2P link report about an activity, e.g. a P2P session in which an affiliated non-AP station of a non-AP MLD participates with a peer station, that takes place on the one of the constrained links.

As a consequence of the Coexistence or P2P link report, the AP device becomes aware of a P2P session or OBSS coexisting with the infrastructure network (BSSs) it manages, in particular in relation with known constrained links at the non-AP device. This provides the AP device with more information to improve a scheduling of the non-AP stations on the constrained links within its infrastructure network. Coexistence between P2P (or DiL for Direct Link) communications or OBSS and infrastructure communications can be enhanced.

The non-AP device may be a non-AP MLD or a standalone non-AP station. Similarly, the non-AP device or the AP device may include a soft AP operating as a Group Owner of a P2P Group. Any of the non-AP device and AP device may thus be a P2P Concurrent Device.

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

In some embodiments, the method further includes adapting communication in a Basic Service Set, BSS, managed by the AP device based on the received Coexistence or P2P link report. For instance, adapting the communication in the BSS may include adapting communication to the non-AP device. In particular, adapting the communication in the BSS may be responsive to receiving the Coexistence or P2P link report reporting activity on EMLSR links of the non-AP device. In embodiments, the method further includes adapting a scheduling of resources on the constrained links based on the received Coexistence or P2P link report.

The AP device can therefore avoid any interference between communications scheduled within the infrastructure network over one of the constrained link and P2P communication or OBSS over another one of the constrained link. Infrastructure communication is thus not lost for the non-AP device simultaneously performing P2P communication or experiencing interference with an OBSS.

In some embodiments, adapting a scheduling includes one or more from amongst the following P2P rules: reducing or avoiding downlink communications to the non-AP device over the constrained links, enrolling the peer station in a TWT agreement negotiated with the non-AP device on the one constrained link, scheduling a TWT to be aligned to a period of P2P inactivity of peer stations of the P2P session as notified in the P2P link report. The notice of absence may mirror an indication of Power Saving mode for the affiliated non-AP station involved in the P2P session.

In particular embodiments, the method further includes, responsive to receiving a P2P link report reporting a termination of the P2P session, releasing the adaptation of the scheduling, i.e., the applied P2P rules.

In some embodiments, the method further includes selecting appropriate transmission parameters for the non-AP device.

In some embodiments, the transmission constraints include a non-simultaneous transmit and receive, NSTR, link pair or an enabled enhanced multi-link single radio, EMLSR, operation on the constrained links.

In particular, the NSTR link pair may be signalled in the P2P link report.

In some embodiments, the Coexistence or P2P link report includes a peer-to-peer link Event Report element or a Channel Usage element with a peer-to-peer link indication. These elements may be according to the IEEE 802.11 family of standards.

For instance, the peer-to-peer link Event Report element or Channel Usage element with peer-to-peer link indication may include one or more of the following fields: a Link ID field including an identifier of the link on which the P2P session takes place, a peer STA address field including an identifier of the peer station, a NSTR field, such as a NSTR indication bitmap, reporting a non-simultaneous transmit and receive, NSTR, link pair of the non-AP device, and a Timing Information field specifying a period of P2P communication in the P2P session or a power saving period for the affiliated non-AP station, a P2P Session Identifier field including an identifier of the P2P session, and a P2P Session Status field including a current status of the P2P session. In some embodiments, the Channel Usage element with peer-to-peer link indication includes a peer-to-peer link Event Report element having one or more of said fields.

In some embodiments, the Coexistence or P2P link report includes, e.g. in a Coexistence element, one or more of the following fields: a Link ID field including an identifier of the link on which the P2P session takes place, a peer STA address field including an identifier of the peer station, a Coexistence Indication Bitmap field indicating one or more pairs of links experiencing transmission constraints, an OBSS List Indication field indicating one or more overlapping Basic Service Sets that interfere with the constrained link, a Coexistence Schedule element indicating a time period when the constrained link experiences transmission constraints, and a Coexistence Status field indicating a current status of the transmission constraints. The Coexistence Status field may be set to a first value (e.g., 1) to indicate the non-AP device has coexistence activities on one or more of its own EMLSR links, and otherwise, be set to a second value (e.g., 0) to indicate the non-AP device has no coexistence activities on one or more of its own EMLSR links.

In some embodiments, the Coexistence or P2P link report is included in a WNM (wireless network management) Action frame having a WNM Action field value set to 1 to signal an Event Report Action frame or set to 21 to signal a Channel Usage Request Action frame or set to a reserved value between 28 and 255 to signal a Coexistence Report Action frame.

In some embodiments, the non-AP device includes or is a P2P Concurrent Device hosting a first station associated with the AP device and a second station, collocated with the first station, that acts as a P2P Device operating in a P2P Group. Declaring the transmission constraints may then include sending, by the first station to the AP device a capability for P2P concurrent mode of operation, and then sending a Coexistence or P2P link report may include sending, by the first station to the AP device, Timing Information obtained by the collocated P2P Device about a P2P session (session to which the P2P Device participates), which Timing Information defines a period of P2P communication in the P2P session. This allows the P2P Concurrent Device to warn the AP device about the timing information of P2P communication periods. As an example, the P2P Concurrent Device may obtain timing information about the P2P session from the Group Owner of the P2P Group and then report to the AP device with which its WLAN STA is associated. In an alternative example, the P2P Concurrent Device may obtain timing information (negotiated P2P TWT) from an AP device with which it is associated and then report to an AP or soft AP operating as Group Owner of the P2P Group. In both examples, the addressed AP device or soft AP is then able to control infrastructure communication (for the AP device) or P2P communication (for the Group Owner) in a way that improve coexistence between infrastructure and P2P communications. In particular embodiments, sending the obtained Timing Information includes sending a Channel Usage Request frame including a Target Wake Time (TWT) element representative of the Timing Information. By signaling timing information of P2P communication periods forthe P2P Concurrent Device, the TWT element thus indicates absences of the WLAN Device of the same P2P Concurrent Device.

In other particular embodiments, in case the P2P Device does not operate as a Group Owner of the P2P Group, the obtaining step includes receiving, from the P2P Group Owner by the collocated P2P Device, a Target Wake Time (TWT) element indicative of a P2P communication period or a Notice of Absence element indicative of a period of absence of P2P communication, and the sending step to the AP device includes sending a Channel Usage Request frame including a second Target Wake Time (TWT) element that includes Timing Information derived from the received TWT element or Notice of Absence element. The P2P Concurrent Device therefore operates any conversion of timing information provided in the received TWT element or Notice of Absence element into timing information for the AP device. In particular, it signals the periods dedicated to P2P communication.

In other particular embodiments, the first station acts as P2P Device operating in a second P2P Group and the AP device includes a soft AP operating as Group Owner of the second P2P Group. In these embodiments, the P2P Concurrent Device is hosting two collocated stations that act as P2P Devices in two separate P2P Groups.

In other particular embodiments, the P2P Concurrent Device is a non-access-point, non- AP, multi-link device, MLD, having a first affiliated non-AP STA operating as WLAN Device in an infrastructure Basic Service Set and a second affiliated non-AP STA operating as P2P Device.

In some embodiments, the Coexistence or P2P link report is sent responsive to one of the following triggering events: creating a P2P session, such as establishing or joining a TDLS session or a P2P group, receiving, from the AP device, a P2P link report request frame, terminating the P2P session, such as tearing down a TDLS session or sending a disassociation frame for disassociating from a P2P group, enabling or disabling a transmission constraint between links, such as enabling or disabling enhanced multi-link single radio, EMLSR, operation for the links, or performing a Channel Switch modifying the STR or NSTR relationship between two links, switching the channel of a link on which the P2P session takes place to an off-channel that becomes NSTR with another link enabled with the AP device, switching the operating channel of a link of the AP device that becomes NSTR with the link on which the P2P session takes place, detecting an interference from an Overlapping Basic Service Set, OBSS, that disturbs a link of the non-AP device, obtaining Timing Information about the P2P session that defines a period of P2P communication in the P2P session or a power saving period for the affiliated non-AP station.

In this context, specific embodiments related to EMLSR may provide that the Coexistence or P2P link report is sent when enabling enhanced multi-link single radio, EMLSR, operation for the links. Enabling EMLSR operation for the links may include sending an EML Operating Mode Notification frame to the AP device.

In embodiments, the Coexistence or P2P link report includes a Coexistence Status field set to a first value (e.g., 1) to indicate the non-AP device has coexistence activities on one or more of the links, and otherwise, is set to a second value (e.g., 0) to indicate the non-AP device has no coexistence activities on one or more of the links.

Other specific embodiments provide that declaring the transmission constraints between the links includes activating an enhanced multi-link single radio, EMLSR, mode on the links. In other words, the link constraints are advertised when activating the EMLSR mode. In this perspective, activating the EMLSR mode may include sending an EML Operating Mode Notification frame to the AP device.

In specific embodiments, the Coexistence or P2P link report includes the declaration of the transmission constraints between the links. In other words, one and the same frame may be used to provide both the declaration of the transmission constraints and the report about coexistence or P2P activity.

In particular embodiments, the method further comprises receiving, from the AP device, information enabling Coexistence or P2P link reporting, wherein the Coexistence or P2P link report is sent only when the Coexistence or P2P link reporting is enabled.

Correspondingly, the method at the AP MLD further comprises sending, to the non-AP MLD, information enabling Coexistence or P2P link reporting to drive the non-AP device to send the Coexistence or P2P link report only when Coexistence or P2P link reporting is enabled.

Hence, the AP MLD warns the non-AP MLD when it is needed to send the link report, upon each triggering event.

In some embodiments, the information enabling the Coexistence or P2P link reporting includes at least one from: a peer-to-peer link Event Report element in a frame (e.g., in an Event Report Request frame), a Channel Usage element with a peer-to-peer link indication in a frame (e.g., in a Channel Usage Request frame or a Probe Response frame), a P2P-related capability declared by the AP device in a frame (e.g., TDLS Prohibited capability field set to 0 meaning TDLS is allowed, Peer-to-peer TWT Support enabled, and so on.; e.g., in a Beacon or Probe Response frame).

In some embodiments, the peer station is a non-AP MLD. In other embodiments, the Coexistence or P2P link report is sent by an affiliated non-AP station of the non-AP device, said affiliated non-AP station participating in a P2P session on the one constrained link. Hence the report is sent over the link on which the P2P communication is instantiated. Note that in case of off-channel, the non-AP station reverts back to the base channel of the link to send the report.

Embodiments of the invention also provide a frame to be sent by a non-access-point, non-AP, device to report about a P2P session in which it participates with a peer station, the frame including a peer-to-peer link Event Report element or Channel Usage element with a peer-to-peer link indication, the element including one or more of the following fields: a Link ID field including an identifier of the link on which the P2P session takes place, a peer STA address field including an identifier of the peer station, a NSTR field, e.g., a NSTR bitmap, including a non-simultaneous transmit and receive, NSTR, link pair of the non-AP device, and a Timing Information field specifying a period of P2P communication in the P2P session or a power saving period for the affiliated non-AP station, a P2P Session Identifier field including an identifier of the P2P session, and a P2P Session Status field including a current status of the P2P session.

Embodiments of the present disclosure allow a TDLS session to be established between stations not sharing the same AP device. This is made possible through a forward function of the TDLS Action frames between distinct AP devices. In this respect, a method of communication in a wireless network is provided, the method comprising, at a first access-point, AP, instantiated in a first communication device: receiving, from a first (peer) non-AP station associated with the first AP, a TDLS Action frame intended to a second (peer) non-AP station associated with a second AP instantiated in a second communication device physically separated from the first communication device, and forwarding the received TDLS Action frame to the second AP over a communication link established between the first and second communication device.

Either the frame itself can designate the second AP or the first AP or a controller between the two APs can use a routing table that allows the second AP to be identified based on the addressed second non-AP station.

Correspondingly, a method of communication in a wireless network is also proposed, wherein the method comprises, at a second access-point, AP, instantiated in a second communication device: receiving, from a first access-point, AP, instantiated in a first communication device physically separated from the second communication device, a TDLS Action frame initiated by a first non-AP station associated with the first AP and intended to a second non-AP station associated with the second AP, and transmitting the received TDLS Action frame to the second non-AP station over an operating channel of the second AP. Through the forwarding mechanism between two non-collocated APs (not hosted in the same physical device as it is the case for a collocated AP MLD), this approach allows the known limitations of TDLS (both TDLS peer STAs must be associated with the same BSS, hence AP, or with a collocated AP MLD since TDLS frames with a different MLD MAC address that its own AP MLD are discarded) to be overcome.

It turns out that the discarding process to filter received frames is modified at the TDLS peer stations. In that respect, a method of communication in a wireless network can also be proposed, wherein the method comprises, at a second non-access-point, non-AP, station that is associated with a second AP instantiated in a second communication device: receiving, from the second AP, a TDLS Action frame initiated by a first non-AP station, wherein the TDLS Action frame identifies an AP in a communication device physically separated from the second communication device. An identifying field may include a (physical) AP MAC address that does not match a (physical) MAC address of the second AP, in case the TDLS Action frame is intended to the second non-AP station, responding to the received TDLS Action frame with a TDLS Response frame addressed to the first non-AP station.

The conventional criterion on the identification of the AP (e.g. MAC address) is no longer taken into account to process (to discard when concerning another infrastructure BSS) the TDLS Action frame, hence to respond thereto. In some embodiments, the TDLS Action frame, such as a TDLS Discovery Request frame, includes a TDLS Multi-Link element having a MLD MAC address in an AP MLD MAC Address field not matching an MLD MAC address of an AP MLD implementing the second AP as affiliated AP. This may correspond to a scenario where the two AP MLDs instantiating the first and second APs are different AP MLDs within an ESS.

In other embodiments related to non-collocated AP MLDs, i.e., logical AP MLDs each having affiliated APs that are instantiated in physically separate devices, the TDLS Action frame includes a TDLS Multi-Link element having a MLD MAC address in an AP MLD MAC Address field matching a logical MLD MAC address of an AP MLD implementing the second AP as affiliated AP and having an identifier in a physical device identifier field not matching a physical identifier of the second communication device. The different physical identifier together with the same logical MAC address allows the station to identify the non-collocated AP MLD scenario.

This filtering approach may apply to any TDLS Action frame and its corresponding response. The TDLS Action frame related to the ESS scenario or the non-collocated AP MLD scenario are no longer discarded by the stations.

In embodiments, the first and second APs belong to the same ESS. In a variant mentioned above, they belong to a logical AP MLD having two or more affiliated APs that are instantiated in physically separate communication devices. More generally, the two APs are instantiated by physically separate devices.

The above frame exchange (TDLS Action frame and possible response) may belong to a more complex procedure where multiple exchanges (frames) are performed in both directions. In embodiments, the forwarding is made on the same channel as the one on which the TDLS Action frame is received. In a variant, the forwarding is made on an operating channel of the second AP. A correspondence table may help the first AP to determine the (second) AP with which the second non-AP station is associated. In another variant, the forwarding is made to through a backhaul link connecting a plurality of APs including the first and second APs. In particular, the TDLS Action frame may be forwarded to a controller of the backhaul link, which in turn forwards the frame to the second AP.

Correlatively, the invention also provides a wireless communication device comprising at least one microprocessor configured for carrying out the steps of any of the above methods. The wireless communication device may be either of a non-AP MLD and an AP MLD.

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 defined 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, non-transitory carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, 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 a typical wireless communication system in which embodiments of the invention may be implemented;

Figures 1a, 1 b and 1c illustrate different examples oftypical 802.11 network environment between MLDs in which peer-to-peer communication occurs concurrently (either temporal or frequency) to communication with an AP MLD;

Figure 1a1 illustrates, using frame exchanges in a timeline, a possible scenario for an initiator peer non-AP STA (affiliated non-AP STA) to handle P2P traffic in the environment of Figure 1a; Figure 1 b1 illustrates, using frame exchanges in a timeline, a possible scenario for a P2P group formation by two peer stations, belonging or not to non-AP MLDs in the environment of Figure 1b;

Figure 1d illustrates an example of typical 802.11 network environment between MLDs in different BSSs in which concurrent communications occur and create coexistence issues;

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 3d illustrates an exemplary Event Type table, different from table of Figure 3b, according to embodiments;

Figure 4a illustrates a format of a peer-to-peer link Event Request field included in a peer- to-peer link Event Request element according to the 802.11 standard;

Figure 4b illustrates a format of a peer-to-peer link Event Report element included in a peer-to-peer link Event Report element according to the 802.11 standard;

Figure 4c illustrates values that the Peer Status field of Figure 4b can take;

Figure 4d illustrates an augmented format of a peer-to-peer link Event Report element according to embodiments of the invention;

Figure 4e illustrates a format of a Coexistence element according to embodiments of the invention;

Figure 5a illustrates a format of a Channel Usage element according to the 802.11 standard;

Figure 5b illustrates a format of a Channel Usage Request frame according to the 802.11 standard;

Figure 5c illustrates a format of a Channel Usage Response frame according to the 802.11 standard;

Figure 5d illustrates an augmented format of a Channel Usage Request frame according to embodiments of the invention;

Figure 5e illustrates another augmented format of a Channel Usage Request frame according to embodiments of the invention;

Figures 6a and 6b illustrate, using flowcharts, exemplary steps at the AP MLD (or AP) and an associated non-AP MLD (or station) to report P2P activity, according to some embodiments of the invention;

Figure 7a illustrates, using frame exchanges in a timeline, the scenario of Figure 1a with Coexistence or P2P link reports according to embodiments of the invention;

Figure 7b illustrates, using frame exchanges in a timeline, the scenario of Figure 1b with Coexistence or P2P link reports according to embodiments of the invention; Figure 7c illustrates, using frame exchanges in a timeline, the scenario of Figure 1 c with Coexistence or P2P link reports according to embodiments of the invention;

Figure 7d illustrates Coexistence or P2P link reports sent in response to explicit requests from the AP, according to embodiments of the invention;

Figure 7e illustrates Coexistence or P2P link reports sent during the association with the AP MLD, according to embodiments of the invention;

Figure 7f illustrates a Coexistence report sent in response to an explicit Coexistence request from an AP, according to embodiments of the invention;

Figure 7g illustrates a Coexistence report sent to a soft AP acting as Group Owner, according to embodiments of the invention;

Figure 8a illustrates a format of a Notice of Absence element according to the Wi-Fi alliance specification;

Figure 8b illustrates a format of a TWT element according to the 802.1 1 standard;

Figure 8c illustrates a format of a Wakeup Schedule element according to the 802.11 standard;

Figure 9a shows a schematic representation a communication device according to at least one embodiment of the present invention;

Figure 9b illustrates schematically the architecture of the communication device of Figure 9a;

Figure 10a illustrates a format of a Coexistence Request frame according to embodiments of the present invention;

Figure 10b illustrates a format of a Coexistence Report frame according to embodiments of the present invention; and

Figure 11 illustrates a format of a Collocated Interference Report element.

DETAILED DESCRIPTION OF THE INVENTION

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. A SDMA system may utilize sufficiently different directions to transmit simultaneously data belonging to multiple user terminals, i.e., wireless devices or stations. A TDMA system may allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units, each time slot being assigned to different user terminal. An OFDMA system utilizes orthogonal frequency division multiplexing (OFDM), which is a modulation technique that partitions the overall system bandwidth into multiple orthogonal sub-carriers or resource units. These sub-carriers may also be called tones, bins, etc. With OFDM, each sub-carrier may be independently modulated with data. A 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).

While the examples are described in the context of WiFi (RTM) networks, the invention may be used in any type of wireless networks like, for example, mobile phone cellular networks that implement very similar mechanisms.

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 STA (gNB), Base STA Controller (“BSC”), Base Transceiver STA (“BTS”), Base STA (“BS”), Transceiver Function (“TF”), Radio Router, Radio Transceiver, Basic Service Set (“BSS”), Extended Service Set (“ESS”), Radio Base STA (“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 stations that together organize their accesses to the wireless medium for communication purposes. The stations (including the AP) form a service set, here below referred to as basic service set, BSS (although other terminology can be used). A same physical station 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.

The 802.1 1 family of standards define various media access control (MAC) mechanisms to drive access to the wireless medium. The current discussions in the task group 802.1 1 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 (AP or non- AP) station (ST A) and has a single medium access control (MAC) service access point (SAP) to logical link control (LLC), which includes one MAC data service. Besides, the MLD also comprises a single address associated with the interface, which can be used to communicate on the distribution system medium (DSM).

The stations forming the same MLD may be partly or all collocated within the same device or geographically dispersed.

An access point multi-link device (AP MLD) corresponds to a MLD where each station (STA) affiliated with the MLD is an AP, referred to as “affiliated AP” hereinafter.

A non-access point multi-link device (non-AP MLD) corresponds to a MLD where each station (STA) affiliated with the MLD is a non-AP station, referred to as “affiliated non-AP station”.

When referring hereinafter to either an AP MLD or a non-AP MLD, the general term “station MLD” may be used.

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), following by ML Authentication and finally by ML Setup where the non-AP MLD associates with the AP MLD (hence obtained an Association I Dentifier, AID) and sets up the ML links for its affiliated non-AP STAs with the APs affiliated with the AP MLD.

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) 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.

Although not MLD, a P2P Concurrent Device is made of two separate MAC entities: a first one operating as a WLAN STA (hence associating with an AP) and a second one operating as a P2P Device (hence involved in P2P operations.)

Figure 1 illustrates a wireless communication system in which several communication station devices 101-107, 110 exchange data frames over a radio transmission channel 100 of a wireless local area network (WLAN), under the management of a central station, namely access point device (AP) 110. Direct communications between STAs can also be implemented without the use of an access point (known as an Ad-hoc mode). The radio transmission channel 100 is defined by an operating frequency band constituted by a single channel, a plurality of channels forming a composite channel, or a plurality of distinct channels (links) forming a multi-link operation.

In the following description, the term “station” or “STA” may be used to describe a non- AP station operating on a given link of 100, which may be a standalone non-AP station or an affiliated non-AP station entity of a non-AP MLD device or a MAC entity of a P2P Concurrent Device. Similarly, the term “AP” describes an AP station operating on a given link, which may be a standalone AP station or an affiliated AP station entity of an AP MLD device.

Exemplary situations of direct communications, corresponding to an increasing trend nowadays, include the presence of peer-to-peer (P2P, also known as Direct Link or “DiL”) transmissions in between non-AP stations, e.g. STA 102 and STA 104 as illustrated in the Figure. Technologies that support P2P transmissions are for example WiFi-Miracast (RTM) or Wireless Display scenario, or Tunneled Direct Link Setup (TDLS), or the "Software Access Point" (Soft AP). Note that even if P2P flows are usually not numerous, the amount of data per flow may be huge (typically low-compressed video, from 1080p60 up to 8K UHD resolutions).

Each STA 101-107 registers to the AP 110 during an association procedure. During the association procedure, the AP 110 assigns a specific Association IDentifier (AID) to the requesting STA. For example, the AID is a 16-bit value uniquely identifying the STA. When the AP and non- AP STA are respectively an affiliated AP of an AP MLD and an affiliated non-AP of a non-AP MLD, they establishing a ML association wherein a unique AID is assigned to the entire non-AP MLD: all affiliated non-AP STAs are identified by same AID value on their respective operation link.

The stations 101-107, 110 may compete on a given link one against the other using EDCA (Enhanced Distributed Channel Access) contention, to access the wireless medium in order to be granted a transmission opportunity (TXOP) and then transmit (single-user, SU) data frames. The stations may also use a multi-user (MU) scheme in which a single station, usually the AP 110, is allowed to schedule a MU transmission, i.e., multiple simultaneous transmissions to or from other stations, in the wireless network. One implementation of such a MU scheme has been for example adopted in IEEE Std 802.11 ax-2021 standard, as the Multi-User Uplink and Downlink OFDMA (MU UL and DL OFDMA) procedures.

Formerly endorsed by IEEE 802.11z standard in 2008, TDLS enables devices (called TDLS peer STAs) to link directly to one another when connected to a traditional AP. To set up and maintain a direct link, both TDLS peer STAs are associated with the same infrastructure BSS (in short, the same AP). The TDLS mechanism provides encapsulation of the setup frames, exchanged between the two TDLS peer STAs, in Data frames. This allows the setup frames to be transmitted transparently (or “tunneled”) through the AP. As shown below, e.g., with reference to Figure 1a1 , the setup frames include so-called TDLS Action frames. Besides, as the setup frames are transmitted transparently through the AP, the AP does not need to be TDLS-aware or to have the same capabilities as the TDLS peer STAs involved in the TDLS-based peer-to-peer communication. Then, once the direct link is setup, the TDLS peer STAs can communicate directly with one another through the setup direct link, without involving the AP although they remain associated with the AP. It can be noted that when the TDLS peer STAs communicate directly via the direct link, the P2P traffic competes with other traffic to/from the AP since the P2P traffic and the other traffic to/from the AP are performed over the same communication link, that is to say the same frequency channel.

As an alternative to the P2P transmission through TDLS, "Software Access Point" (Soft AP) is a way to support Wi-Fi Direct. Indeed, in Wi-Fi Direct similarly to the soft AP, one of the P2P stations takes the lead on a P2P group, by providing some AP functionalities to the other P2P stations (such as discovery and registration services), to perform direct communications. A soft AP represents a software enabled AP and implies a software enabling a device which has not been specifically made to be a router into a wireless AP, to operate as a soft AP. The use of the "Software Access Point" (Soft AP) is a new trend that allows devices to communicate directly with each other using methods similar to traditional WLAN, except without requiring the use of a central access point provided as an infrastructure of the WLAN.

To reduce competition with the infrastructure, i.e., with the traffic involving the AP, a switching between the channel used by the AP, referred to as “base channel”, and an associated off-channel has been proposed. The mechanism is known as a “TDLS channel switching”.

The IEEE P802.11-REVme/D3.0 version (April 2023) defines the off-channel. An off- channel is a channel used by TDLS peer STA that does not overlap the channel(s) used by the AP with which the TDLS peer STA is associated. In other words, an off-channel is a channel that does not belong to the AP’s operating channel(s) and that can be used for P2P communication. TDLS devices can negotiate to move (i.e., switch) from the base channel (i.e., shared with the AP and used to setup the TDLS direct link) to such an off-channel (not shared with the AP). The two TDLS devices previously advertise in the TDLS setup frames, usually request and response, that they support at least partially the same channels) including the off-chan nel(s). Before moving (switching) from the base channel to the off-channel, the TDLS device is in PS (Power Save) mode with the AP and is not involved in an active Service Period with the AP. When operating via the off-channel, the TDLS devices remain in power save mode in the base channel and can no longer communicate with the AP. Thus, they have to regularly, hence repeatedly, return to the base channel in order to perform some actions, such as to receive beacons, look at the TIM (Traffic Indication Map) for any buffered packets, and communicate with other devices in the network.

In addition to the legacy off-channel management, the IEEE P802.11-REVme/D3.0 version (April 2023) has recently adopted an improvement of the channel usage procedure by adding a new usage mode (value set to 2 in a Channel Usage element - see Figure 5a) that allows a non-AP STA to request the assistance of its associated AP to setup a non infrastructure BSS on an off-channel that does not overlap the operating channels of any APs belonging to the ESS of its associated AP. Moreover, the recent modification of the standard allows a non-AP STA to negotiate with its associated AP the establishment of a peer-to-peer TWT agreement through the Channel Usage procedure (Request/Response) that includes in that case a TWT element. The peer-to-peer TWT thus negotiated may be used for off-channel TDLS (usage mode set to 1) or noninfrastructure BSS, typically softAP (usage mode set to 2).

The Target Wake Time (TWT) mechanism, originally defined in the IEEE 802.11 ah and 802.1 1 ax standards, has been adapted to be included in the 802.11 be standard. An adaptation is known as the Restricted Target Wake Time (rTWT) which schedules dedicated (and protected) service periods (SPs) for stations to convey their latency sensitive traffic(s) over their BSS. An rTWT 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 rTWT) schedule. The rTWT Service Periods (SPs) of the rTWT schedule are advertised in broadcast management frames (e.g. beacons, FILS Discovery frames and broadcast Probe Response frames), using an rTWT information about the negotiated rTWT SPs, typically a Broadcast TWT ID (bTWT ID).

The D3.2 standard has adapted the Peer-to-Peer functionalities such as TDLS or Wi-Fi Direct through the support of the Software Access Point to enhance P2P communication. For example, the Tunneled Direct Link Setup (TDLS) has been adapted to coexist with the MLDs, by adjusting the signalling of MAC addresses in the setup frames when establishing a TDLS session over one of the multiple setup links. As a result, a direct link, made of a single communication link (e.g. a 20MHz channel on either of the 2.4, 5 and 6 GHz bands), is established in between two wireless STAs (TDLS peer STAs), each one affiliated with an MLD. Also, the soft AP in the D3.2 standard allows a non-AP MLD station to be temporally turned to adopt AP functionality, meaning all its affiliated stations adopt the AP behaviours to be soft APs on their respective channels.

However, the P2P capabilities of the non-AP MLD face some communication restrictions at the non-AP MLD due to the multi-link nature of the communications.

Non-AP MLDs may be non-STR (NSTR - non simultaneous transmit and receive) meaning the MLD cannot transmit on one link while receiving on another link (vice and versa). Those links are referred to as a “NSTR link pair”. It is a pair of links corresponding to stations affiliated with a MLD for which the receiver requirements according to the Extremely high throughput (EHT) PHY specification are not met on one of the links when a station affiliated with the MLD is transmitting on the other link. Each link of such a pair is a member of the NSTR link pair.

Also, non-AP MLDs may operate according to Enhanced Multi-Link Operating Modes (EML OM) as introduced in the D3.2 standard, namely the EMLSR (Enhanced Multi-Link Single Radio) mode and the EMLMR (Enhanced Multi-Link Multi-Radio) mode that are mutually exclusive. In operation mode, the activation and the deactivation of an EML Operation Mode is initiated by the non-AP MLD which sends a specific EHT Action frame referred to as “EML OM Notification”.

The EMLMR mode, once activated, allows the non-AP MLD to simultaneously listen to a set of enabled links (so-called EMLMR links, usually made of two enabled links) to receive an initial frame transmitted by the AP MLD to initiate frame exchange and next to aggregate some physical resources of its different radios used on different links (so-called EMLMR links) in order to transmit or receive data up to a pre-defined number of supported Rx/Tx spatial streams, over only one EMLMR link at a time, usually the link over which the initial frame is received. The number may be greater than the number of supported Rx/Tx spatial streams of each radio.

The EMLSR mode, once activated, allows the non-AP MLD to simultaneously listen to a set of enabled links (so-called EMLSR links, usually made of two enabled links) to receive an initial control frame (e.g. an MU-RTS trigger frame, a BSRP trigger frame) from the AP MLD to initiate frame exchange and next to perform data frames exchange with the AP MLD over only one EMLSR link at a time, usually the link over which the initial control frame is received.

In the context of Wi-Fi Direct, a P2P group is made of P2P Devices, one acting as soft AP (called P2P Group Owner) and the others as P2P clients. A P2P Concurrent Device is a P2P Device that has one MAC entity operating as a WLAN STA and the second MAC entity operating as P2P Device. The P2P Concurrent Device may be a single radio device or multi-radio device. Thereby, the P2P Concurrent Device suffers from the similar aforementioned constraints, in that way, the WLAN STA and P2P Device are concurrent and the two entities of the P2P Concurrent Device could be assimilated to the constrained links of an MLD.

Such constraints on the links (NSTR link pair or EMLSR links or links of the P2P Concurrent Device) raise issue when P2P communication of non-AP MLDs (e.g. TDLS non-AP MLD or soft/mobile AP MLD having NSTR or EMLSR limitations) coexist with the infrastructure network which has its own communication. It would be appropriate if the AP or AP MLD could consider these constraints in its scheduling of communication within its infrastructure network to prevent concurrent transmission and reception (i.e., scheduling of Downlink and Uplink during an overlapping period of time) over the constrained links of the non-AP MLDs and/or P2P Concurrent Devices. Also, the D3.2 standard provides that the TWT mechanism can be used at affiliated station level, i.e., by each affiliated non-AP station of a non-AP MLD. An improved scheduling of transmission within the infrastructure network could take into account the TWT specificities.

Figures 1a, 1 b and 1c illustrate different examples oftypical 802.11 network environment between MLDs in which peer-to-peer communication occurs concurrently (either temporal or frequency) to communication with an AP MLD. In the example of the following figures, stations with the same colour share the same operating channel.

Figure 1a illustrates an example wherein two non-AP MLDs 102 and 104 are associated with an AP MLD 110. The two non-AP MLDs communicate directly each other through a peer-to- peer link 173 which is established according to TDLS or WiFi Direct procedure.

AP MLD 110 has multiple affiliated APs, two affiliated APs 1 11 and 112 (also referenced AP1 , AP2 respectively) in the exemplary Figure 1a, each of which behaves as an 802.11 AP over its operating channel within one frequency band. Known 802.1 1 frequency bands include the 2.4 GHz band, the 5 GHz band and the 6 GHz band. Of course, other frequency bands may be used in replacement or in addition to these three bands.

The non-AP MLDs 102, 104 have multiple affiliated non-AP STAs, each of which behaves as an 802.11 non-AP STA in a BSS (managed by an affiliated AP 111 or 112) to which it registers. In the exemplary Figure 1a, two non-AP STAs 121 and 122 (also referenced A1 and A2 respectively) are affiliated with non-AP MLD 102 and two non-AP STAs 141 and 142 (also referenced B1 and B2 respectively) are affiliated with non-AP MLD 104.

For example, AP 111 is set to operate on channel 38 corresponding to an operating 40 MHz channel in the 5 GHz frequency band and AP 112 is set to operate on channel 151 corresponding to another operating 40 MHz channel in the 5 GHz frequency band too. In another example, the affiliated APs could operate on different frequency bands.

Each affiliated AP offers a link towards the AP MLD 1 10 to the affiliated non-AP STAs of a non-AP MLD (102 or 104). Hence, the links for each non-AP MLD can be merely identified with the identifiers of the respective affiliated APs. In this context, each of the affiliated APs 111 and 112 can be identified by an identifier referred to as “Link ID”. The Link ID of each affiliated AP is unique and does not change during the lifetime of the AP MLD. AP MLD 110 may assign the Link ID to its affiliated APs by incrementing the IDs from 0 (for the first affiliated AP). Of course, other wording, such as “AP ID”, could be used in a variant.

To perform multi-link communications, each non-AP MLD 102, 104 has to discover, authenticate, associate and set up multiple links with the AP MLD 110, each link being established between an affiliated AP of the AP MLD 110 and an affiliated non-AP STA of the non-AP MLD. Each of such setup communication links, referred to as “enabled link”, enables individual channel access and frame exchanges between the non-AP MLD and the AP MLD based on supported capabilities exchanged during association.

During the ML setup procedure, the non-AP MLDs declare part or all of their capabilities. For instance, they may declare their Tunneled Direct Link Setup (TDLS) capability, which enables stations of the non-AP MLDs (called TDLS peer STAs) to communicate directly to one another when connected to a traditional AP. For this, appropriate fields are provided in the management frames. De facto, in all Management frames, a non-AP MLD which may act as TDLS initiator STA or TDLS responder STA (dot1 ITunneledDirectLinkSetupImplemented to true) sets the TDLS Support bit (bit 37) in the Extended Capabilities element to 1 .

Similar to the TDLS support, a non-AP MLD or AP MLD may also declare whether the Channel Usage is activated (dot1 I ChannelUsageActivated is true) and thus allows its affiliated STAs to exchange their Channel Usage Information, by setting the Channel Usage bit (bit 24) in the Extended Capabilities element to 1 ; whether the Event Report is activated (dot11 EventsActivated is true) and thus allows its affiliated STAs to use the event request/report messaging, by setting the Event bit (bit 7) in the Extended Capabilities element to 1. Also, TIM broadcast capability (bit 18), TDLS Peer PSM (Power Save Mode) Support capability (bit 29), TDLS Channel Switching capability (bit 30), TDLS Prohibited capability (bit 38), TDLS Channel Switching Prohibited capability (bit 39), FILS capability (bit 72), TWT Requester Support capability (bit 77), TWT Responder Support capability (bit 78) and/or Peer-to-peer TWT Support (bit 100) can also be signalled as enabled in the Extended Capabilities element.

For illustrative purpose, in wireless communication network 100, during the ML setup procedures, two candidate setup links have been requested by non-AP MLD 102 and accepted by AP MLD 1 10: a first link 151 between affiliated AP 11 1 (AP1) and affiliated non-AP STA 121 (A1), a second link 152 between affiliated AP 112 (AP2) and affiliated non-AP STA 122 (A2). Similarly, two candidate setup links have been requested by multi-radio non-AP MLD 104 and accepted by AP MLD 1 10: a first link 161 between affiliated AP 1 11 (AP1) and affiliated non-AP STA 141 (B1), a second link 162 between affiliated AP 1 12 (AP2) and affiliated non-AP STA 142 (B2).

When the non-AP MLDs are associated with the same AP MLD, they may decide to establish a TDLS setup targeting one of the links of the AP-MLD. This procedure is described in the standard IEEE 802.11 REVme/D3.0 and its adaptation to the multi-link is described in the standard IEEE802.11 be/D3.2. The setup is mainly based on an optional discovery phase and a three-step setup frame exchange relayed by the associated AP.

The single link TDLS direct link mechanism in the context of MLDs is now explained with reference to Figure 1a1 which illustrates, using frame exchanges in a timeline, a possible scenario for an initiator peer non-AP STA (affiliated non-AP STA) to handle P2P traffic.

This example involves STA A2 122 as the initiator for the P2P communication and STA B2 142 as the partner or responder for the P2P communication 173. They both take part of the same BSS on a given link 2 (152/162), and are associated with AP 112. As mentioned above, STA A2 and STA B2 may be non-AP stations affiliated with respective non-AP MLDs, while AP 112 may be an AP affiliated with an AP MLD 110.

In the sequence, once STA A2 and STA B2 are associated with the AP (association not shown), they can exchange data over their operation link through the AP. To reduce the amount of traffic that is transferred in the network and prevent congestion at AP 112, they may set up a TDLS session, i.e., a direct link between them to directly exchange data (P2P communication), while also remaining associated with the AP.

In the sequence shown, a TDLS session or “TDLS direct link” is established between STA A2 and STA B2 (either of both can be the initiator of the TDLS direct link establishment). The establishment may include a TDLS discovery procedure (optional) and a TDLS setup procedure.

TDLS discovery and setup procedures between STA A2 and STA B2 involve frames, known as TDLS Action frames, that are usually sent and received via intermediate AP 1 12. The TDLS procedure is characterized by encapsulating signalling frames (TDLS Action frames) in 802.11 Data frames, which allows them to be transmitted through the AP transparently.

When attempting to discover TDLS stations in the same BSS, a series of frame exchanges is used. STA A2, which is the initiator in the proposed scenario, sends a TDLS Discovery Request frame 221 , tunneled through AP 112 (relay illustrated by the black dot), to an individual destination station, here STA B2.

Destination station STA B2 responds to the TDLS Discovery Request frame 221 with a TDLS Discovery Response frame 222 sent directly to STA A2 (without relay by AP 112).

From that point, STA A2 and STA B2 know each other, meaning they know the other operate on the communication link setup with AP 112. They can then establish a TDLS direct link.

When attempting to establish a TDLS direct link over a single link with the discovered TDLS station, a series of TDLS Action frame exchanges is used to set up the single link TDLS direct link.

TDLS initiator STA A2 first sends a TDLS Setup Request frame 223, tunneled through AP 112 (relay illustrated by the black dot), to target TDLS responder STA B2. This request frame conveys a “Link Identifier” element and a “TDLS Multi-Link” element amongst the available lEs as defined in Table 9-497 of IEEE 802.11-REVme/D1 .3 (June 2022), which include information about the capabilities (such as Power saving) of TDLS initiator STA A1 and an AID thereof.

TDLS responder STA B2 responds with a TDLS Setup Response frame 224, also tunneled through AP 112. This response frame conveys a “Link Identifier” element and a “TDLS Multi-Link” element along with information about the capabilities (such as Power saving) of TDLS responder STA B2, its AID plus a status code that either accepts or rejects the setup request.

If the Setup Request is accepted, TDLS initiator STA A2 then sends a confirmation, TDLS Setup Confirm frame 225, still tunneled through AP 112.

This concludes the TDLS setup handshake. At this point, the two non-AP MLDs know the identity of each other on the one hand with their MLD MAC address and on the other hand with the AID assigned by the AP MLD.

When the TDLS is established, the stations can then start to communicate directly over link 173 (direct link): P2P traffic can then be directly exchanged between STA A2 and STA B2 using the established TDLS session. TDLS peers STA A2 and STA B2 are then configured to accept Data frames received directly from the other peer station. The frame exchanges are performed over the same link, that is to say the same frequency channel so that this P2P traffic becomes concurrent to other traffic for AP2 112.

To avoid the competition with the AP‘s traffic, the TDLS peer stations that support TDLS channel switching can decide to perform a TDLS Channel Switch 230 to a Supported Channel. The TDLS peer stations inform each other about their supported channels during the TDLS setup procedure, i.e., the TDLS peer stations include Supported Channels element and Supported Operating Classes element in all TDLS Setup Request and TDLS Setup Response frames that have a TDLS Channel Switching subfield equal to 1. More advantageously, the TDLS peer stations may move from the base channel of the link considered to an off-channel, that is to say a channel that does not overlap the channels) used by the access point (AP) with which the TDLS peer stations are associated. It is recalled that the off-channel available for TDLS is supplied by the AP through a so-called Channel Usage element (described below with reference to Figure 5a) transmitted in Probe Response or Channel Usage Response frames.

The TDLS STA initiator 122 sends a TDLS Channel Switch Request frame 231 over the TDLS direct link. This frame includes a target channel, i.e., the destination channel (off-channel) of the intended channel switch. The target channel is specified by the TDLS STA initiator that initiates the channel switch, from the set of operating classes supported by both TDLS peer STAs. Upon receiving the TDLS Channel Switch Request frame 231 , the target partner STA B2 142 responds with a TDLS Channel Switch Response frame 232 to accept or reject the Channel Switch. If the status code indicated in the response frame is set to REQUEST_DECLINED, both stations continue to operate on the current channel. Otherwise, if the status code is set to SUCCESS in the response frame, both stations move to the target channel (off-channel) before a switch time also indicated in the TDLS Channel Switch frames. The first transmission over the target channel does not start before the end of the Switch Time. Finally, after the switch time has elapsed, the initiator STA A2 can start transmitting P2P data frame on the target channel.

When operating via the target channel (off-channel), the TDLS peer STAs are in power save mode with the AP and can no longer communicate with him. Thus, they have to regularly switch back to the base channel associated with the same link, in order to receive Beacon frames, look at the TIM (Traffic Indication Map) for any buffered packets, and communicate with other stations in the infrastructure network (BSS) managed by the AP.

Details on the TDLS procedure are provided in IEEE 802.11 z, and have been upgraded to be established over one link among possibly multiple links as provided in the D3.2 standard.

An issue arises when the pair of links (151 , 152) of the non-AP MLD 102 is or become NSTR (NSTR relation is shown with dotted line in non-AP MLD 102 in Figure 1a), that is to say the non-AP MLD is unable to receive on the link 151 when it is transmitting on the link 152 or 173 as the link 152 and 173 are operating on the same channels. The NSTR constraint may appear due to the TDLS Channel Switch because the off-channel may interfere with the other link (here 151). Consequently, when the non-AP MLD 102 communicates directly with the non-AP MLD 104 in peer-to-peer, it is blind on link 151. A similar issue occurs when links 151 and 152 belong to an EMLSR set, i.e., they cannot be used to transmit simultaneously because the corresponding MLD has a single full radio.

Benefits for efficient communication in the infrastructure could be obtained if the AP MLD become aware of this kind of constraints between links including a link over which a P2P session is taking place.

As an example, the AP MLD could avoid transmitting downlink data over such a constrained link to a non-AP MLD involved in a P2P session over an associated constrained link. Similarly, if either non-AP MLD negotiates a TWT agreement over such a constrained link to get Service Period to transmit P2P traffic, the peer station could not be aware of the TWT SP and miss the communication. The AP MLD could intervene to facilitate the registration of the peer station to the TWT agreement.

Plenty of those limitations exist during the lifetime of the TDLS session. Their impact on the infrastructure communication should be reduced should the AP MLD be aware of them in due time.

To end the TDLS session, one of the non-AP MLDs sends a TDLS Teardown frame 229 to its peer. The TDLS Teardown Action field is encapsulated in a Data frame and transmitted to the TDLS peer STA directly or through the AP to tear down a TDLS direct link.

In addition, the TDLS peer stations may organise their TDLS session as they desire. For example, they may negotiate together periods of P2P activity and periods of P2P inactivity. They may negotiate a power saving mode (PSM) and agree on a periodic wakeup schedule that defines such periods of P2P activity and periods of P2P inactivity. In order to enter TDLS peer PSM, one of the TDLS peer STA (TDLS peer PSM initiator) sends a TDLS Peer PSM Request frame 241 to the TDLS peer STA (TDLS peer PSM responder), including a proposed periodic wakeup schedule. A Wakeup Schedule element is used to that end, which is shown as reference 820 in Figure 8c. It includes seven fields:

Element ID field 821 set to a value (equal to 102) indicating that the information element is a Wakeup Schedule element.

Length field 822 set to various values depending on the length of the Wakeup Schedule element 820.

Offset 823 and Interval 824 fields set to define, in microseconds, when the awake windows begin. The Interval field is nonzero and the Offset field is less than the Interval field.

Awake Window Slots field 825 set to the duration of the awake window in units of backoff slots (such as defined by EDCA).

Maximum Awake Window Duration field 826 set to the maximum duration of the awake window, in units of microseconds.

Idle Count field 827 set to the number of consecutive awake windows during which no individually addressed frame is received from the TDLS peer STA before a TDLS peer STA deletes the wakeup schedule. When the TDLS peer PSM responder accepts the proposed wakeup schedule, it responds with a TDLS Peer PSM Response frame 242 indicating status code SUCCESS. Otherwise, the TDLS peer PSM responder responds with a TDLS Peer PSM Response frame indicating the appropriate status code for rejecting the schedule. An alternative schedule may be included in the TDLS Peer PSM Response frame when the status code is equal to TDLS_REJECTED_ALTERNATIVE_PROVIDED. The alternative schedule may be used by the TDLS peer PSM initiator to generate a new TDLS Peer PSM Request frame 241 .

After successfully transmitting or receiving a TDLS Peer PSM Response frame indicating status code SUCCESS, the TDLS peer PSM initiator and TDLS peer PSM responder have established a periodic wakeup schedule between them.

In that case, the NSTR or EMLSR constraints mentioned above only exist when the TDLS peer station is awake. Therefore, a knowledge by the AP MLD of the periods of P2P activity and periods of P2P inactivity (hence of the PSM Awake Windows) could be very helpful for the AP MLD to properly schedule infrastructure communications that reduce interference with the P2P communications.

Figure 1 b illustrates a variant to Figure 1a in which only one non-AP MLD 102 is associated with AP MLD 110. The P2P communication in that example is established following the WiFi direct procedure as the second MLD device 104 is not associated with AP MLD 1 10. In the example of the Figure, MLD 104 acts as a soft-AP or NSTR Mobile AP (such as defined in standard D3.2) or a P2P Group Owner.

The process of forming a P2P group (or the like) is now explained. A Wi-Fi Direct connection is mainly performed through three processes including a device discovery, a service discovery and group establishment. The processes are shown in Figure 1 b1 which illustrates, using frame exchanges in a timeline, a possible scenario for a P2P group formation by two peer stations, belonging or not to non-AP MLDs.

First process is the device discovery process 250 which is required when Wi-Fi P2P devices or stations, for example, a first and a second P2P stations (122, 141), recognize each otherto configure a connection to establish the Wi-Fi P2P group. In this phase, a station alternates between a listen state and a search state. A first P2P station searches for neighbouring Wi-Fi P2P stations by repeatedly performing channel scan of IEEE 802.11 channels through listening to the so-called “social channels”, defined as channel 1 , 6 and 11 in the 2.4GHz band, and searching these channels for a predetermined time period. A basic operation of the device discovery process performed during the Wi-Fi P2P group establishment is implemented by exchanging a Probe Request frame and a Probe Response frame of an IEEE 802.11 MAC protocol. These exchanges enable the P2P stations to discover each other on a nearby environment.

Second process is the service discovery 260 which is performed after the device discovery process, to provide a function of exchanging information on services that each P2P station can support. That is, each P2P station may identify a supportable service protocol, a service and the like through exchange of a Request frame and a Response frame. P2P stations therefore exchange queries to discover the set of available services of each other and, based on this information, decide whether to continue the group formation or not.

Third process is the group generation or establishment. A group owner (GO) negotiation process is performed by a three-way exchange including a GO Negotiation Request frame 261 , a GO Negotiation Response frame 262 and a GO Negotiation Confirm frame 263. These frames allow the two stations to agree on which station will act as P2P GO, while the other one will act as a P2P client of the GO, and to agree on which channel the group will operate, which can be, for example, in the 2.4 GHz or 5 GHz bands and to share their P2P attributes. These information (P2P attributes) may be carried in P2P Information Element. For example, the P2P Capability attribute contains a set of parameters that can be used to establish a P2P connection.

In the example of the figure, as the non-AP MLD supports connections to both an infrastructure network and a Wi-Fi Direct group at the same time, it may take the form of a P2P Concurrent Device. Its P2P Device informs its peer (Group Owner in the figure) of this constraint by setting the Concurrent Operation field to 1 in the Device Capability Bitmap of the P2P Capability attribute. On the other hand, the WLAN-STA interface of the P2P Concurrent Device may include the P2P Interface attribute within a P2P IE in the (Re)association Request frame that is transmitted to the WLAN AP (AP MLD 110 or one of its affiliated AP 111 and 112) for example if the WLAN AP is capable of managing P2P devices. In other words, the P2P Concurrent device has to declare its constraints to the AP.

Security provisioning (not shown) starts after discovery has taken place and, if required, the respective roles have been negotiated upon forming the group.

Once the P2P Group is established, new P2P stations can discover and join the P2P Group using active or passive scanning mechanisms like the ones used in traditional Wi-Fi networks. Like a traditional AP, a P2P GO announces itself through beacons, and has to support power saving services for its associated clients. The P2P GO is also required to run a Dynamic Host Configuration Protocol (DHCP) server to provide P2P Clients with IP addresses (not represented in the figure).

Upon successful Wi-Fi Direct Connection Setup between stations, the stations can then start to communicate directly over link 173 (direct link). The frame exchanges are performed over the same frequency channel so that this P2P traffic becomes concurrent to other traffic for AP2 112.

In a variant to the scenario of Figure 1 b, STA A2 joins the (already established) P2P group of the Group Owner 141 such as described above.

Similar to Figure 1a, the pair of links (151 , 152) of non-AP MLD 102 may be or become NSTR (NSTR relation is shown with dot line in the figure) or EMLSR links. The same issues as mentioned above arise with the risks of interference between the P2P communication and the infrastructure communication. Also, TWT agreement for P2P traffic may be negotiated by STA A2. Power Saving mode (PSM) may be organized between the two peer stations, as well as a channel switch to an off-channel, that the AP MLD may not be aware of.

As for TDLS session, the P2P stations belonging to the P2P group may negotiate power saving mode in order to be awake only on certain periods of time. WiFi Direct provides that the Group Owner may inform about its period or periods of absence (when it is in power saving mode) by including a Notice of Absence attribute or element in its Beacon frame 270 or in Probe Response frame (not shown in the figure), or using a Notice of Absence Action frame (not shown in the figure). Main information of this element is shown in Figure 8a under reference 800. Element 800 includes four fields:

Count field 801 to indicate the number of absence intervals. The field may be set to a value from 1 to 255. 255 means a continuous schedule; 0 is reserved and not used.

Duration field 802 to indicate the maximum duration in units of microseconds that the P2P Group Owner can remain absent following the start of a Notice of Absence interval.

Interval field 803 to indicate the length of the Notice of Absence interval in units of microseconds.

Start Time field 804 to indicate the start time for the schedule expressed in terms of the lower 4 bytes of the TSF timer.

The P2P group owner may also send the Notice Of Absence (NoA) element according to the presence request/response mechanism (not shown in the figure) initiated by the P2P client. In that case, the NSTR or EMLSR constraints only exist when the P2P station is awake.

To disconnect from a group, a P2P client (STA A2 in the example of Figure 1 b) may send a Disassociation frame 264 to its group owner (STA B1 in the example of the Figure). Similarly, a group owner may disconnect a P2P client or end a group session.

Given the above constraints and the existence of TWTs or NoA that organize the P2P communications, there may be an interest for the AP MLD to be aware of such information about the P2P session, to properly schedule infrastructure communications that reduce interference with the P2P communications.

Figure 1c illustrates another variant to Figures 1a and 1 b in which both non-AP MLDs are associated with different AP MLDs, respectively non-AP MLD 102 is associated with AP MLD 110 while non-AP MLD 104 is associated with AP MLD 190. Both AP MLDs may be independent or tied by an ESS or part of a non-collocated AP MLD. In the latter cases (ESS or non-collocated AP MLD), both AP MLDs may be controlled by an entity 180 (or controller) which may be in charge of managing the security (authentication), the frequency sharing, the BSS transition and may act as a relay between AP MLDs 110 and 190...

In the Figure, AP MLD 110 has affiliated APs AP11 111 and AP12 112, while AP MLD 190 has affiliated APs AP21 191 and AP22 192.

In addition to their respective association with AP MLD 110 and 190, non-AP MLD 102 through its affiliated STA A2 and non-AP MLD 104 through its affiliated STA B1 have established a peer-to-peer link (e.g. TDLS session). This peer-to-peer link is operating on the same link/channel as AP 191 but is considered as an off-channel for AP MLD 110. Thereby, STA A2 122 is in power save mode from AP12 112 point of view when STA A2 122 communicates with STA B1 141 through the peer-to-peer link 173 and on the contrary P2P STA A2 122 is offline from STA B1 141 point of view when STA A2 122 communicates with its associated AP 112 over the operating channel of AP 112. The diagonal stripes of the STA A2 122 box represent the dual operation either on the operating channel of AP 112 when the station communicates with it or on the operating channel of AP 191 when the station communicates with STA B1 141 in a peer-to- peer way.

Similar to Figure 1a or 1b, the pair of links (151 , 152) of non-AP MLD 102 may be or become NSTR in particular when STA A2 operates on the off-channel (from AP MLD 110 point of view) for P2P communication (i.e., on the operating channel of AP 191). AP MLD 110 may not be aware of the use of this off-channel.

Also, the pair of links (161 , 162) of non-AP MLD 104 may be or become NSTR (NSTR relation is shown with dotted line in box 104 in the figure) or EMLSR links. The same issues as mentioned above arise with the risks of interference between the P2P communication and the infrastructure communication. Also, TWT agreement for P2P traffic may be negotiated by the stations. Power Saving mode (PSM) may be organized between the two peer stations.

This risk also exists when one of the constrained links experiences interference from an OBSS.

Figure 1d illustrates another variant of the previous figures in which both non-AP MLDs are associated with different AP MLDs, respectively non-AP MLD 102 is associated with AP MLD

110 while non-AP MLD 104 is associated with AP MLD 190. Both AP MLDs does not see each other and the non-AP MLDs are close enough to be concurrent when they operate on the same frequency.

In the figure, similar to Figure 1a, non-AP MLDs 102, 104 have multiple affiliated non-AP STAs, each of which behaves as an 802.11 non-AP STA in a BSS (managed by an affiliated AP

111 or 112 and AP 191 or 192 respectively) to which it registers.

For example, AP 111 is set to operate on channel 38 corresponding to an operating 40 MHz channel in the 5 GHz frequency band and AP 112 is set to operate on channel 151 corresponding to another operating 40 MHz channel in the 5 GHz frequency band too. For the second AP MLD 190, AP 191 is also set to operate on channel 38 (concurrent to AP 111) and the AP 192 is set to operate on channel 102 corresponding to a third operating 40 MHz channel in the 5 GHz frequency band. In another example, the affiliated APs operate on different frequency bands.

The two AP MLD BSSs are not overlapping but as the two non-AP MLDs are closely located, they may disturb each other on the shared frequency (e.g. channel 38). Therefore, stations STA A1 121 and STA B1 141 (respectively affiliated to non-AP MLD A 102 and non-AP MLD B 104) compete to each other to access the medium. Moreover, as they are close, when one of the stations is transmitting, it disturbs the other one. Indeed, the transmit power to reach the AP is such that it overwhelms the other station’s signal reception. That is these two stations affiliated to different non-AP MLDs may be considered as belonging to a NSTR station pair (relation shown by the dotted line).

In addition, a P2P link 173 may be established between STA A1 121 and STA B1 141 using the mechanisms described previously. The aforementioned limitations may thus be cumulated to the ones described in the previous Figures in relation to the P2P communication that can occur through P2P link 173.

Again, there may be an interest for the AP MLD to be aware of such information about the P2P session or the OBSS or interference or disturbance, to properly schedule infrastructure communications that reduce interference with the P2P communications or infrastructure communications themselves.

The present disclosure proposes embodiments to inform an AP MLD about P2P operation of one of its associated non-AP MLDs or of OBSS impacting one of its links. Such a mechanism to inform provides benefit to the overall network communication when the non-AP MLD experiences constraints between the “P2P” or “OBSS” link and another link enabled with the AP MLD. The non-AP MLD may thus declare, to the AP MLD, transmission constraints between links enabled with the AP MLD. Constrained links include for example EMSLR links or a NSTR link pair.

For ease of explanation, it is now made reference to a P2P communication or session over one of the constrained links, rather than the presence of an OBSS. However, the mechanisms described below also apply to two constrained links when one of them experiences interference with an OBSS.

When there is any change or new information related to P2P communication (e.g. PSM or P2P TWT with an established P2P session, establishment or termination of a P2P session), the non-AP MLD may send, to the AP MLD, a P2P link report (and more generally a Coexistence link report) about the P2P session taking place on one of the constrained links.

In response, the AP MLD may take appropriate measures to adjust the infrastructure communication to the P2P information provided in the P2P link report. It may for example include enrolling the other peer station into an existing TWT dedicated to P2P traffic, or avoiding transmitting downlink frames to the peer stations during P2P activity, or releasing any of such restriction when the P2P activity stops (e.g. due to PSM or termination of the P2P session).

Exemplary reporting includes using an Event Report element or a Channel Usage element.

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 req uest/re port elements. Event req uest/re port 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.

More specifically for the peer-to-peer link Event report (or P2P link Event report), a peer- to-peer event occurs when a peer-to-peer link is initiated or terminated. This may be the case of a TDLS session being established or torn down, or a P2P Group being joined or created. Also, a P2P event may occur when the P2P link substantially changes (e.g., modification of the channel used).

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 embodiments (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 non-AP STAs.

The requesting STA transmits an Event Request frame 290 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 291 .

The Event Request frame 290 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 290 with Event Report frame 291 .

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). The peer-to-peer link Event corresponds to value 2.

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 Peer-to-peer link event request is described in 9.4.2.66.4.

The requested STA or the reporting STA processes (299) the received Event Request frame, generates an Event Report frame 291 and sends it to the requesting STA in response to the Event Request frame 290. The Event Report frame (291) 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 291 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 291 is transmitted spontaneously, i.e., for another reason than in response to an Event Request frame 290, 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 whetherthe 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. Focus in now made on the peer-to-peer link Event Request element (i.e., when Event Type field 330 is set to value 2) and on the peer-to-peer link Event Report element (i.e., when Event Type field 340 is set to value 2).

Figure 4a illustrates a format of a peer-to-peer link Event Request field included in a peer- to-peer link Event Request element 320. This field corresponds to Event Request field 325 of an Event Request Action frame 290 with Event Type field 330 set to value 2.

The requesting STA may include zero or more peer-to-peer link Event Request subelements 400 in peer-to-peer link Event Request field 325.

Subelements 400 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 subelementspecific 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.

Subelements are defined for the peer-to-peer link Event Type according to Table 9-234 in IEEE P802.11-REVme/D3.0, April 2023, by distinct Subelement IDs, including: a Peer Address ID subelement 400-a when Subelement ID is set to value 0. This subelement identifies the peer STA, BSS, or IBSS of the peer-to-peer links to be reported. Excluding this subelement from the Event Request field 325 indicates a request for peer-to-peer link events for any peer STA, any BSS, and any IBSS. The Peer STA/BSSID Address field contains a MAC address of a peer STA or a BSSID for peer-to-peer links in an IBSS. If the indicated address matches the Address 1 field of the MAC header contents, then the address is a peer STA address for a TDLS peer STA or an IBSS STA. If the indicated address matches the Address 3 field of the MAC header contents, then the address is a BSSID for the TDLS direct link or for the IBSS. a Channel Number subelement(s) when Subelement ID is set to value 1. This subelement identifies the channel for the peer-to-peer links to be reported. Excluding this subelement from the Event Request element 325 indicates a request for peer-to-peer link events for any channel. The format of the Channel Number subelement is shown in 400-b. The Operating Class field indicates the channel set of the link to be used for the peer-to-peer link event report. (Operating Classes are defined in Annex E of 802.1 I REVme D3.0). The Channel Number field indicates the channel number for peer-to-peer link events requested. A Channel Number of 0 in all Channel Number subelements indicates a request to report any peer-to- peer link event for any supported channel in the specified filtering Operating Class.

Figure 4b illustrates a format of a peer-to-peer link Event Report element included in a peer-to-peer link Event Report element 360. This field corresponds to Event Report field 369 of an Event Report Action frame 291 with Event Type field 364 set to value 2. A peer-to-peer link is defined to be either a Direct Link within a QoS BSS, a TDLS, or a STA-to-STA communication in an IBSS. Peer-to-peer Event Report subelement 450 is used by the reporting STA to report an event. This subelement is defined in the figure 9-468 in IEEE P802.11-REVme/D3.0, April 2023.

Peer STA/BSSID Address field 451 contains a MAC address. If this event is for a peer-to- peer link in an infrastructure BSS, this field contains the MAC address of the peer STA. If this event is for a peer-to- peer link in an IBSS, this field contains the BSSID.

Operating Class field 452 indicates the channel set of the peer-to-peer link. Valid values of the Operating Class are shown in Annex E of 802.11 REVme D3.0.

Channel Number field 453 indicates the peer-to-peer channel number of the peer-to-peer link. The Channel Number is defined within an Operating Class as shown in Annex E of 802.11 REVme D3.0.

STA Tx Power field 454 indicates the target transmit power at the antenna (i.e., EIRP) in dBm with a tolerance of ± 5 dB of the lowest basic rate of the reporting STA.

Connection Time field 455 contains the connection time in seconds. If the Peer Status is 0, this field indicates the duration of the Direct Link. If the Peer Status field is 1 , this field indicates the time difference from the time the Direct Link was established to the time at which the reporting STA generated the event report. If the Peer Status field is 2, this field indicates the duration of the IBSS membership. If the Peer Status is 3, this field indicates the time difference from the time the STA joined the IBSS to the time at which the reporting STA generated the event report.

Peer Status field 456 indicates the Peer link connection status. The values of the Peer Status field are defined per Figure 4c (Table 9-237 of IEEE P802.11-REVme/D3.0, April 2023) to distinguish between active and terminated P2P links/sessions.

As mentioned above, an alternative to the Event Report element to report to the AP MLD may include using a Channel Usage element.

The Channel usage procedure is used by the AP to recommend, to a non-AP STA, channels for BSSs that are not infrastructure BSSs or an off-channel TDLS direct link. The non- AP STAs can use the channel usage information as part of channel selection processing for a BSS that is not an infrastructure BSS or an off-channel TDLS direct link. Hence, the channel usage information provided by the AP to the non-AP STA is to advise the STA on how to coexist with the infrastructure network. Besides, the non-AP STA may negotiate a peer-to-peer TWT agreement by including a TWT element in the Channel Usage request frame (described below with reference to Figure 5b) and the AP may accept the establishment of this TWT agreement by including in its turn a TWT element in the Channel Usage response frame (described below with reference to Figure 5c). Moreover, a non-AP STA that has already selected a Channel for peer-to-peer communication may transmit a Channel Usage Request frame with the Usage Mode field of the Channel Usage element set to 3 (peer-to-peer link indication) and without a Channel Entry field to inform the AP about its unavailability during the peer-to-peer TWT agreement. With reference to the Figure 5a, the data payload of a Channel Usage element is shown under reference 500. The Channel Usage element is made up of four fields: Element ID field 510, Length field 520, Usage Mode field 530 and Channel Entry field 540.

Four different values are defined for Usage Mode field 530 in the IEEE P802.11- REVme/D3.0 version (April 2023), i.e., value 0 for Non infrastructure IEEE 802.11 network, value 1 for Off-channel TDLS direct link, value 2 for Non infrastructure IEEE 802.11 network in which none of the APs belonging to the same ESS operate on the channels identified by the Channel Entry field and finally value 3 for peer-to-peer link indication. Values 4 to 255 are reserved.

Channel Entry field 540 includes zero or more Operating Class 541 and Channel 542 fields. Operating Class field 541 indicates an operating class value. The operating class is interpreted in the context of the country specified in the Beacon frame. Channel field 542 indicates a channel number, which is interpreted in the context of the indicated operating class. Operating Class and Channel numbers are defined in Annex E in the IEEE P802.11-REVme/D3.0 version. Operating Class and Channel fields can be grouped together to identify a noncontiguous channel as described in 9.4.2.69.3 (Location Indication Channels subelement).

A Channel Usage Request frame is sent by a non-AP STA to the AP to request the specified Channel Usage information. Channel Usage Request frame 580 is described with reference to the Figure 5b. It includes Category field 581 , WNM field 582, Dialog token field 583, Channel Usage Element field 584, Supported Operating Classes Element field 585 and optional fields TWT elements field 586 and Timeout Interval Element 587, as follows:

Category field 581 is similar to Category field 300 described above (value 10).

WNM field 582 defines the type of the frame, i.e., Channel Usage Request Frame (WNM Action field value equals 21 , according to Table 9-510 in IEEE P802.11-REVme/D3.0, April 2023).

Dialog Token field 583 is the nonzero value chosen by the non-AP STA sending the Channel Usage Request frame to identify the request/response transaction.

Channel Usage Element field 584 includes one or more Channel Usage elements to identify the request Usage Mode.

Supported Operating Classes Element field 585 contains a Supported Operating Classes element to indicate the supported operating classes for the requested network type, consistent with the Country element advertised by the AP.

TWT Elements field 586 includes zero or more TWT elements each containing only one individual TWT parameter set. When included in a Channel Usage Request frame, the TWT Elements field contains only one TWT element, except if used for the establishment of a peer- to-peer TWT agreement with a range of TWT parameter values. In this case, an additional TWT element is present.

Timeout Interval Element field 587 is present when the TWT Elements field contains at least one TWT element; if present it contains a TIE. Otherwise, the Timeout Interval Element field is not present in this frame. A Channel Usage Response frame is sent by an AP in response to a Channel Usage Request frame, or spontaneously. Channel Usage Response frame 590 is described with reference to the Figure 5c. It includes Category field 591 , WNM field 592, Channel Usage Element field 593, Country String field 594, optional Power Constraint Element field 595, optional EDCA Parameter Set Element field 596, optional Transmit Power Envelope Element field 597, optional TWT elements field 598 and optional Timeout Interval Element 599. Only fields that differ from the Channel Usage Request frame 580 are further described hereafter:

Country String field 594 is the value contained in the dot11 Countrystring attribute.

Power Constraint Element field 595 includes zero or one Power Constraint elements.

EDCA Parameter Set Element field 596 includes zero or one EDCA Parameter Set elements. Transmit Power Envelope element field 597 is defined in 9.4.2.160 (Transmit Power Envelope element in 802.11 REVme D3.0).

The present invention provides enhanced reporting to the AP MLD in particular with respect to the multi-link nature of the MLD.

Figures 6a and 6b illustrate, using flowcharts, exemplary steps at the AP MLD (or AP) and an associated non-AP MLD (or station) to report P2P activity, according to some embodiments of the invention.

The left part of the Figure represents steps at a non-AP station affiliated to the non-AP MLD concerned by P2P activity, while the right part represents steps at the affiliated AP corresponding to the non-AP station.

The affiliated non-AP station may be the station involved in the P2P session to report information about the P2P session (e.g. establishment, termination, timing information, TWT). In a variant, it may be a different station, i.e., another affiliated non-AP station than the one experiencing the P2P session. For example (as illustrated below with reference to Figure 7c for instance), it may be an affiliated non-AP station performing a Channel Switch that creates a NSTR constraint with the P2P link (the link over which the P2P session takes place).

At step 600, an AP may send a P2P link Report registration indication enabling a P2P link reporting, i.e., to ask its associated stations to send it information related to any P2P link or session to which they participate. This indication may be conveyed in a P2P link Report registration frame.

In some embodiments, the frame is a peer-to-peer link Event Request Action frame 290, meaning it includes a peer-to-peer link Event Request element 320. In that case, the indication may be the Event Type field 330 set to value 2, optionally with at least one peer-to-peer link event request subelement 400.

In other embodiments, the frame is a Channel Usage Request frame 580, meaning it includes a Channel Usage element 500 with a peer-to-peer indication. In that case, the indication may be the Usage Mode field 530 set to value 3 (i.e., Peer-to-peer link indication).

In other embodiments, the frame is a Probe Response frame, meaning the P2P link Report registration indication is transmitted during the association procedure of the affiliated non- AP station. The indication may be provided in a Channel Usage element included in the frame, with the Usage Mode field 530 set to value 3.

In other embodiments, the P2P link Report registration indication may also be inferred from one or more specific capabilities declared by the AP either in a Beacon frame or a Probe Response frame. The indication may include a P2P-related capability declared by the AP MLD in a frame. Exemplary capabilities include the TDLS Prohibited capability field when it is set to 0 (means TDLS is allowed) or the Peer-to-peer TWT Support capability when it is enabled.

More generally, any P2P bit in the Beacon or Probe Response frame may be used to indicate the P2P link Report registration enabling a P2P link reporting.

At step 610, the affiliated non-AP station receives the P2P link Report registration indication sent by the AP at step 600. The non-AP MLD is now aware that a P2P link Report is required by the AP MLD to optimize its scheduling within the infrastructure network.

As mentioned above, such an adapted scheduling is sought when there are constrained links. In that respect, at step 620, the non-AP MLD (either of its affiliated non-AP stations) declares, to the AP MLD, transmission constraints between links of the non-AP MLD. This may include EMLSR constraints. Hence, step 620 may be triggered upon activation of the EMLSR mode. In a variant, a report regarding NSTR links, e.g., including a NSTR bitmap, may be provided. Hence, step 620 may be triggered upon Channel switching, because the target channel creates interference with another channel, hence they are NSTR links.

The AP MLD thus received the link constraint declaration at step 630. As apparent from below, this drives the AP MLD on which link or links it has to adapt its scheduling within the infrastructure network.

The link constraint declaration may be performed before the P2P link Report registration indication (hence steps 620 and 630 are before steps 610 and 600 respectively). Also, steps 600 and 610 may be omitted, when the affiliated non-AP station systematically reports link constraints (whatever the AP’s capabilities).

In other variants explained below, in particular with respect to the proposed formats of the P2P link Report (see NSTR Indication Bitmap 459 as an example), the link constraint declaration may be included in the P2P link Report sent by the non-AP MLD.

Next, at step 640, the non-AP MLD participates to a P2P session over one link (of either of its affiliated stations), denoted “P2P link”, and a triggering event occurs at an affiliated non-AP station to send such a P2P link report to its associated AP.

Various triggering events may be contemplated.

In some embodiments, the triggering event includes receiving, from the AP, a P2P link report request frame, such as the peer-to-peer link Event Request Action frame or Channel Usage Request frame 580 with a peer-to-peer indication that have been sent at step 600. In that case, step 640 directly follows step 610: the P2P link report is sent as an immediate response to a request frame. In other embodiments, the triggering event includes creating a P2P session, such as establishing or joining a TDLS session or a P2P group. In that case, it is the affiliated non-AP station involved in the P2P session that sends the P2P link report.

In yet other embodiments, the triggering event includes terminating the P2P session, such as tearing down a TDLS session or sending a disassociation frame for disassociating from a P2P group. In that case, it is the affiliated non-AP station involved in the P2P session that sends the P2P link report.

In yet other embodiments, the triggering event includes obtaining Timing Information about the P2P session, defining a period of P2P communication in the P2P session or a power saving period for the affiliated non-AP station. This may include obtaining new Awake Window Slots or Notices of Absence for the P2P session or group.

In yet other embodiments, the triggering event includes modifying, i.e., enabling or disabling, a transmission constraint between links including the P2P link, e.g. enabling or disabling enhanced multi-link single radio, EMLSR, operation for the links, or performing a Channel Switch modifying the STR or NSTR relationship between two links. For example, the affiliated non-AP station may switch the channel of a link on which the P2P session takes place to an off-channel that becomes NSTR with another link enabled with the AP MLD. In a variant, the AP MLD may switch the operating channel of one of its links enabled with the non-AP MLD, which link becomes NSTR with the P2P link on which the P2P session takes place.

In yet other embodiments, the triggering event includes detecting an interference from an OBSS that disturbs a link of the non-AP MLD.

Due to the triggering event detected at step 640, the affiliated non-AP station prepares and sends, at step 650, a P2P link report about the P2P session taking place on the one constrained P2P link, to its associated AP.

Various pieces of information may be included in the P2P link report, including all or part (at least one) of the following information:

- a Link ID field including an identifier of the P2P link on which the P2P session takes place,

- a peer STA address field including an identifier of the other peer station involved in the P2P session,

- a NSTR field, such as a NSTR indication bitmap, reporting a non-simultaneous transmit and receive, NSTR, link pair of the non-AP MLD, and

- a Timing Information field specifying a period of P2P communication in the P2P session or a power saving period for the affiliated non-AP station (e.g., Awake Window Slots or Notices of Absence),

- a P2P Session Identifier field including an identifier of the P2P session, and

- a P2P Session Status field including a current status of the P2P session (e.g., active or terminated).

The P2P link report may be included in a peer-to-peer link Event Report frame 291 in which case a peer-to-peer link Event Report element 450 carries the above information, or in a Channel Usage Request frame 580 in which case a Channel Usage element 500 with peer-to- peer indication carries the above information. Of course, any other frame conveying an appropriate element to provide coexistence information (about a P2P session or an OBSS) may be used.

Next, at step 660, the AP receives the P2P link report that includes P2P link characteristics. Its AP MLD may use this information to properly schedule communications in its infrastructure network. To do so, it determines appropriate P2P Rules depending on the situation at step 670.

A first P2P rule may seek to reduce or avoid downlink communications to the non-AP MLD over the constrained links while the P2P session is running, or at least while it is not known that the corresponding affiliated non-AP station is not in a power saving mode but it is active. For example, it means the AP MLD avoids scheduling simultaneous communications on EMLSR link set or NSTR link pair when one of the links is dedicated to P2P communication.

A second P2P rule may seek to enroll the other peer station in a TWT agreement negotiated with the non-AP station on the one constrained link. Indeed, the affiliated non-AP station performing P2P communication may have negotiated a TWT for P2P communication to its associated AP. By knowing the identity of the other peer station (as reported in the P2P link report), this AP is able to enroll that other peer station to make sure it is awake when a service period of the TWT for P2P communication will start.

A third P2P rule may seek to schedule a TWT to be aligned with a period of P2P inactivity or absence of peer stations of the P2P session as notified in the P2P link report (e.g., inferred from reported Awake Window Slots or Notices of Absence). Indeed, the affiliated non-AP station (or even the other peer station) may have negotiated a conventional TWT (not P2P) with its associated AP. Knowing that and the period of P2P inactivity, this AP may try to schedule the TWT during the period of P2P inactivity to increase the chances the non-AP station is available and thus ready to efficiently use the communication resources allocated to it in the infrastructure network.

Once the P2P rule or rules have been selected, they are applied at step 680 to adapt or adjust the scheduling of the infrastructure communication by the AP MLD.

Note that in case the P2P link report reports termination of the P2P session, the adaption of the scheduling can be released.

Figure 7a illustrates, using frame exchanges in a timeline, the scenario of Figure 1a where two non-AP MLDs are associated with an AP MLD and the non-AP MLDs are about to establish a peer-to-peer link to directly communicate with each other. The same references as in Figure 1a1 correspond to the same phases I steps I frames I entities.

To ease the coexistence between P2P communication and its own infrastructure communication (inside a BSS or ESS), an affiliated AP can send a P2P link report registration frame 710 to ask its associated non-AP stations to report about their P2P sessions. Any frame or indication as described above with reference to step 600 can be used. As in Figure 1a1 , the initiator peer non-AP station, STA A2, negotiates a Tunneled Direct Link Setup (state 220), TDLS, session with the partner peer non-AP station, STA B2, as described above (TDLS discovery and setup).

Therefore, AP 1 12 relays the TDLS Discovery Request frame 221 , TDLS Setup Request frame 223, TDLS Setup Response frame 224 and TDLS Setup Confirm frame 225 between STA A2 and STA B2.

At the end of the TDLS establishment process e.g. upon transmission or reception of the TDLS Setup Confirm frame 225, the non-AP MLDs involved in the TDLS establishment may inform their associated AP about the establishment of the peer-to-peer link through the P2P link report 715. Alternatively, the message may be transmitted by only one of the peer stations for instance the TDLS initiator STA.

As mentioned above, the P2P link report 715 may be a peer-to-peer link Event Report frame 291 which includes a peer-to-peer link Event Report element 450.

The peer-to-peer link Event Report element may be as described above with reference to Figure 4b. In variants, it is augmented with additional information as shown in Figure 4d.

In both cases, the element includes among others the operating channel (field 453) in which the P2P session takes place, the peer status (field 456) to indicate that the connection is active (peer status is set to value 1 for Direct Link or 3 for IBSS membership) or terminated (peer status is set to value 0 for Direct Link or 2 for IBSS membership).

The augmented format includes four optional fields, meaning all or part of them can be included:

Link ID field 457 indicates the link on which the P2P communication operates. This information is complementary to fields 452 and 453 indicating the operating channel. This information may allow to transmit the P2P link report 715 on another link that the P2P link on which the P2P session takes place. In case of off-channel for the P2P session, the link ID indicates which affiliated station of the non-AP MLD is used for the off-channel P2P communication, in that case the link ID is considered as a station identifier. This field 457 may not be present if the report is transmitted on the link where the P2P session takes place, and if NSTR field 459 is not present.

Other peer STA address field 458 carries the identifier of the other peer station involved in the P2P communication. This identifier may be the AID or the MAC address of the other TDLS peer station in case of TDLS. This identifier may be the MAC address of the group owner in case of WiFi Direct. This information allows to inform the AP about the other station involved in the P2P communication. Thereby, if a broadcast or peer-to-peer TWT is established between the AP and the non-AP STA such as defined by field 451 (or reporting STA), the AP may inform or enroll the other peer STA in the TWT agreement as already described above. This information is also a way to link both P2P stations and to adopt similar behavior especially if the report is only sent by one of the two or more stations. This field 458 may not be present if the other peer station is not associated with the AP or associated with another AP of the ESS. If the field 458 carries the MAC address of the group owner who serves the reporting STA, the AP may use this information to perform inter-BSS coexistence procedure. NSTR Indication Bitmap 459 indicates NSTR link pairs. Each bit Bj(j i) in the NSTR Indication Bitmap subfield included in the current element with Link ID subfield 457 equal to i (where 0 < i < 15) is set to 1 if the link pair corresponding to link IDs equal to <i, j> is an NSTR link pair; otherwise bit Bj is set to 0. Bit Bi in the NSTR Indication Bitmap subfield included in the current element with Link ID subfield value equal to i is reserved. The bitmap therefore defines all the NSTR pairs involving link T defined in subfield 457. The NSTR information is particularly useful when the P2P transmission occurs on an off-channel. Indeed, the AP is not aware of the NSTR limitation of the non-AP MLD on other channels that the channels on which the APs affiliated to the AP MLD operate. The bitmap may not be present if the station has no NSTR limitations.

Wakeup schedule element 460 already described indicates the period when the station is awake from P2P communication viewpoint. The information carried by the element 460 can help the AP to not schedule concurrent communication with the P2P communication when the P2P station is awake. Concurrent communication encompasses communication with the reporting station, or with other station(s) affiliated to the same non-AP MLD of the reporting station if the non-AP MLD suffers from NSTR or EMLSR limitations (for instance stations indicated by the NSTR indication bitmap) or with the peer station of the reporting station indicated by the other peer STA address field.

As apparent from the explanation, the Wakeup schedule element 460 provide Timing Information specifying a period of P2P communication in the P2P session or a power saving period for the affiliated non-AP station.

Other elements could be used to provide Timing Information, rather than the Wakeup schedule element 460. For example, a TWT element (shown in Figure 8b) can be used to provide information about an individual (P2P) TWT agreed by the P2P stations to schedule their P2P communication. Of course, the element may inform the AP about all kinds of TWT (individual TWT, broadcast TWT, restricted TWT, OBSS TWT...). This element informs the AP of the scheduling of communication between both peers and so when concurrent communications will occur.

Similarly, a Notice of Absence (shown in Figure 8a) can be used to provide information about the scheduling of the power saving period of a Group Owner and so when the P2P stations will not be involved in P2P communications. The AP can thus schedule infrastructure communication for these stations (both the reporting and the other peer stations) during that period without risks of interference with P2P communication, whatever the limitations such as EMLSR or NSTR.

In another variant, the TWT element or the Wakeup element could be used to carry timing information of the Group Owner. To do so, the reporting station may be capable to transform the timing requirement supplied by the group owner (e.g. from Notice of Absence) into the timing information carried in the Wakeup or TWT element.

In a similar way, as illustrated by Figure 7g, the P2P Client (STA A2 122 in Figure 1 b) of a non-AP MLD or a P2P Concurrent Device may inform the Group Owner about a P2P TWT timing negotiated with the associated AP (associated with another affiliated non-AP STA or the WLAN STA). Typically, the P2P client may negotiate a P2P TWT schedule through the channel usage request/response with a usage mode set to 3 as described with reference to Figures 5b and 5c and then informs the Group Owner through the P2P Presence procedure. Indeed, a P2P Client that has requirements on the P2P Group Owner presence periods may submit a P2P Presence Request (including a Notice of Absence as described in Figure 8a) to the P2P Group Owner to influence P2P Group Owner power management timing. The P2P Presence Request may include a bit to indicate to the Group Owner that the timing information carried in the Notice of Absence is issued from a P2P TWT negotiated with the infrastructure AP. In that case, the Group Owner may follow this timing information to improve coexistence.

In a variant, if the STA A2 122 is a Group Owner rather than a P2P client, the STA A2 may inform its P2P clients about the TWT timing negotiated with its associated AP.

As mentioned above, the P2P link report 715 may be a Channel Usage Request frame 580 which includes a Channel Usage element 500 with peer-to-peer indication, in a variant to the peer-to-peer link Event Report frame.

The Channel Usage Response frame 580 may be as described above with reference to Figure 5b.

In variants, it is augmented with additional information as shown in Figure 5d or 5e. In Figure 5d, it is augmented with all or part of Link ID field 457, Other peer STA Address field 458, NSTR Indication bitmap field 459, Wake up schedule field 460 (or variants thereof) described above, plus the optional Peer Status field 456 also described above.

In the variant of Figure 5e, Channel Usage Request frame 580 is augmented with a peer- to-peer link Event Report element 450 as described above (with reference to Figures 4b or 4d).

Whatever the frame considered (peer-to-peer link Event Report frame 291 or in a Channel Usage Request frame 580), the frame may also contain a session ID that is used in the subsequent P2P link Reports (if any) to identify these new messages as an update of the session identified by the session ID. The session ID may also be carried in the Dialog Token field 583 or 352. In the TDLS case, the session ID could be the link identifier exchange during the TDLS setup and describe in the clause 9.4.2.60 in standard D3.2.

In another different variant to the peer-to-peer link Event Report element or the additional fields of the Channel Usage Request frame 580, the P2P link report message 715 may carry a Coexistence element 490 as described with reference to Figure 4e that includes the following fields: Link ID field 457 to indicate the link on which the P2P communication operates, as already described above. This field could not be present if the report is transmitted on the link where the P2P operates and if Coexistence Indication bitmap field 462 is not present.

Other peer STA address field 458 as already described above. This information may also be used with the OBSS list Indication field 463. If present in the same Coexistence element, the first BSS included in the OBSS List Indication field 463 may indicate the BSS (or other information that allows to identify another AP/BSS) with which the other peer is associated. This can allow the AP receiving the report to setup an OBSS TWT or more generally a service period that facilitates the communication inter-BSS and so the OBSS coexistence.

Coexistence Indication Bitmap field 462 to indicate link pairs with coexistence constraints (for instance EMLSR, NSTR or affected by OBSS). The NSTR Indication Bitmap described above is one possible implementation for bitmap 462. Each bit Bj(j i) in the Coexistence Indication Bitmap field 462 included in the current element with Link ID field 457 equal to i (where 0 < i < 15) is set to 1 if the link pair corresponding to link IDs equal to <i, j> is inter-constrained (NSTR, EMLSR or affected by OBSS); otherwise bit Bj is set to 0. Bit Bi in the Coexistence Indication Bitmap subfield included in the current element with Link ID subfield value equal to i is reserved. This Coexistence information is particularly useful when the P2P transmission occurs on an off-channel. Indeed, the AP is not aware of the link limitation of the non-AP MLD on other channels than the channels on which the APs affiliated to the AP MLD operate. This information is also useful if the non-AP MLD suffers from interference from other BSSs, for example if the station is stationed at the BSS boundary. This bitmap could not be present if the station has no Coexistence limitations.

OBSS List Indication field 463 to indicate the OBSS or OBSSs that disturb the reporting station. This list may contain several BSSIDs and/or AP IDs that identify the OBSSs. The information is helpful for the AP MLD receiving the report to setup a MAP coordination for instance an inter-BSS TWT. In addition, the reporting station may add, for each entry in the list, a Collocated Interference Report element (as described in IEEE P802.11-REVme/D3.0 version (April 2023) in section 9.4.2.83) as shown in Figure 11 to report some characteristics of a collocated interference.

The Report Period field indicates whether the reporting is periodic or not, and the period when appropriate. The Interference Level field indicates the maximum level of the collocated interference power. The Interference Level Accuracy/lnterference Index field includes the Expected Accuracy field to indicate the expected accuracy of the estimate of interference and includes the Interference Index field to indicate the type of interference source. The Interference Interval field indicates the interval between two successive periods of interference. The Interference Burst Length field indicates the duration of each period of interference. The Interference Start Time/Duty Cycle field indicates the start of the interference burst, based on the TSF timer. When either the Interference Interval or the Interference Burst. The Interference Center Frequency field indicates the center frequency of interference. The Interference Bandwidth field indicates the bandwidth of the interference signal.

If the reporting station fails to identify the OBSS that creates the interference, the reporting station may set the AP ID to a specific value used for unknown identity. However, to identify an OBSS and to report on that specific OBSS, the reporting station may previously send a beacon request so as to obtain a beacon report from surrounding stations. The beacon report or reports may provide all or parts of the information to feed the OBSS List Indication.

Coexistence Schedule element 464 to indicate the period when the reporting station may suffer from coexistence issue for example when the station is awake from P2P communication viewpoint. The information carried by the element helps the AP to not schedule concurrent communication with the P2P communication when the P2P station is awake. Also, if the coexistence issue is related to OBSS, the scheduling information may help the AP MLD to setup an OBSS TWT with the OBSS indicated in the OBSS list Indication 463 and aligned in time with the information carried by the Coexistence schedule element. The Coexistence Schedule element may be according to the formats described with reference to Figures 8a, 8b and 8c, i.e., reusing the fields of the elements of these Figures.

Coexistence Status field 465 to indicate whether a coexistence issue is ongoing and the reason of the coexistence issue: NSTR, EMLSR, OBSS, and so on.

When carrying the Coexistence element 490, P2P link report frame 715 can be seen more generally as Coexistence link report. The link report may include several Coexistence elements 490, if several links of the non-AP MLD suffer from limitations or the non-AP MLD may send a report per impacted link.

In some embodiments, the Coexistence element 490 can be used in the peer-to-peer link Event Report frame 291 or in the Channel Usage Request frame 580 (in replacement of the additional fields shown in Figure 4d, 5d and 5e).

The Coexistence link report may use a dedicated value in the table of Figure 3b which describes the different available Event Type 364 of the Event Report frame 291 . This dedicated value may be one of the reserved values from 6 to 220. For example, value 6 as shown in Figure 3d may correspond to a Coexistence type.

In a similar way, when carrying the Coexistence element, the Channel Usage element 500 may use a new value in the Usage Mode field 530. This dedicated value may be one of the reserved values from 4 to 255. For example, value 4 as shown in Figure 5a may correspond to Coexistence indication.

In another embodiment, the Coexistence element 490 can be carried in the Collocated Interference report element shown in Figure 11 as described below, in order to enrich its report with additional information.

In the example of Figure 1a, the links 151 and 152 belong to a NSTR link pair. As a result, the P2P link Report includes a link ID field set to 1 (corresponding to the link 152) and a NSTR (or Coexistence) indication bitmap with the 0^th bit is set to 1 while the remaining bit are set to 0. This configuration means that links 0 and 1 (respectively 151 and 152) belong to an NSTR link pair.

Then, the initiator peer non-AP station, STA A2, may further negotiate a Tunneled Direct Link Setup scheduled power saving (state 240), with the partner peer non-AP station, STA B2.

Therefore, TDLS Peer PSM Request frame 241 and TDLS PSM Response frame 242 are exchanged between STA A2 and STA B2.

When the TDLS stations agree on this scheduled power saving, one of the peer STAs (for instance the TDLS Peer PSM initiator) sends to the AP a new P2P link Report including the wakeup schedule element (or any other Timing Information element). As a result, the AP may adapt its scheduling with regard to the TDLS stations according to the timing information included in the wakeup schedule element and then release the constraints (e.g. EMLSR, NSTR) during the period of power saving of the P2P stations.

Only one of the P2P peer stations may send the P2P link Report, in particular when the association between the P2P peer stations has been done previously, i.e., it reuses the session ID previously allocated for this P2P session, or when the message includes the other peer STA address.

In a similar way as the P2P link report is sent in response to a new Awake Window Slot or Notice of Absence, a P2P link Report may be sent following the establishment of a new TWT agreement.

Next, in the example of Figure 7a, TDLS STA A2 122 can send P2P data traffic 226 to TDLS STA B2 142.

When a TDLS peer station wants to end the TDLS session, it sends a TDLS Teardown 229 to its partner peer station. Therefore, the transmission/reception of this TDLS Teardown message 229 finishes the TDLS session. It may further trigger the sending of a new P2P link Report to inform the AP that the TDLS session has just ended. In response, the AP may release all the constraints associated with the P2P session now ended.

Any type of frame already described above may be used (e.g., peer-to-peer link Event Report frame 291 and Channel Usage Request frame 580). The Peer Status field 456 may be set to indicate that the connection is terminated (peer status is set to value 0 for Direct Link or 2 for IBSS membership).

Figure 7b illustrates, using frame exchanges in a timeline, the scenario of Figure 1 b where one non-AP MLD is associated with an AP MLD and the non-AP MLD is about to join a peer-to-peer group to directly communicate with a group owner or other client of the P2P group. The same references as in Figures 1 b1 and 7a correspond to the same phases I steps I frames I entities.

As in Figure 7a, an AP can send a P2P link report registration frame 710.

As in Figure 1 b1 , the station, STA A2, negotiates (state 250), the creation of a P2P group with the partner peer station, STA B1 , or negotiates to join an existing group managed by the group owner STA B1 . When STA A2 eventually joins the P2P group, the non-AP MLD through its affiliated STA A2 informs its associated AP about the establishment of the peer-to-peer link/group through the P2P link report message 715. Any type of frame already described above may be used (e.g., peer-to-peer link Event Report frame 291 and Channel Usage Request frame 580). The Peer Status field 456 may be set to indicate that the connection is active (peer status is set to value 1 for Direct Link or 3 for IBSS membership).

In the example of Figure 1b, the links 151 and 152 belong to a NSTR link pair. As a result, the P2P link Report includes a link ID field set to 1 (corresponding to the link 152) and a NSTR (or Coexistence) indication bitmap with the 0^th bit is set to 1 while the remaining bit are set to 0. This configuration means that links 0 and 1 (respectively 151 and 152) belong to an NSTR link pair.

Next, the group owner STA B1 , may transmit beacon frame 270 including a Notice of Absence (Timing Information) element, to the group client including the peer non-AP station, STA A2.

Upon reception of a Notice of absence (new or updated), STA A2 sends to the AP a P2P link Report including the Notice of Absence element as Timing Information.

In a similar way, a P2P link Report may be sent following the establishment of a new TWT agreement or a following the reception of a Notice of Absence related to P2P Presence procedure.

Next, in the example of Figure 7b, STA A2 122 can send P2P data traffic 226 to the group owner STA B1 141 .

When a P2P station wants to disconnect from the P2P group, it performs a Disassociation procedure 264 (or Deauthentication procedure not shown) with its group owner such as defined in the IEEE 802.11 sections 11 .3.5.6 or 11 .3.4.4. In the same way a group owner may disconnect a client.

Next, after the disconnection or when the station decides to disconnect from the group, disconnected station A2 sends a new P2P link Report to inform the AP that the P2P session has just ended or will end. As a result, the AP may release all the constraints associated with the P2P session.

Figure 7c illustrates, using frame exchanges in a timeline, the scenario of Figure 1c where both non-AP MLDs are associated with different AP MLDs and the non-AP MLDs are about to establish or join a peer-to-peer group to directly communicate with a group owner or other client of the P2P group. The same references as in Figures 1a1 and 7a correspond to the same phases I steps I frames I entities.

This figure describes a TDLS setup between TDLS stations associated with different APs within an ESS or belonging to a non-collocated AP MLD. A non-collocated AP-MLD can be seen as an AP MLD with non-collocated affiliated APs. In other words, the logical AP-MLD has at least two affiliated APs that are instantiated on physically separate devices.

The setup procedure reuses the same signalling but the frames 221 , 223, 224, 225 are forwarded by several entities to reach the TDLS stations.

The frames may be forwarded to all APs belonging to the ESS or the non-collocated AP MLD over the channel on which the frame (from the station) is initially received or through a dedicated backhaul link used to connect the APs between them.

In a variant to forwarding to all APs, the AP MLDs may have a correspondence table indicating with which APs each station is associated (for the ESS case) or is physically connected (for the non-collocated AP MLD case, the station affiliated to the non-AP MLD is physically connected to one specific AP of the non-collocated AP MLD while remaining associated with the logical non-collocated AP MLD). In that case, the frames to forward are only sent to the AP (or AP MLD) with which the target peer station is associated or to which it is physically connected. However, due to the nature of the multi-link operation, a frame which is directed towards the non- AP MLD may be relayed on a different link than the one on which the frame has been received from the peer station, said different link reaching the AP MLD with which the target peer non-AP MLD is associated or to which it is physically connected.

In another variant, the frames are forwarded to the controller 180 and the controller, in turn, sends the frame to the AP or AP MLD with which the target peer station is associated or to which it is physically connected. This last variant assumes the controller owns a table indicating to which APs or AP MLDs each station is linked.

In any case, contrary to the conventional TDLS mechanism, affiliated AP12 receiving a TDLS Action frame from associated STA A2 determines that the TDLS Action frame is intended to STA B1 associated with AP21 itself instantiated in another physical device than AP12, and then forwards the received TDLS Action frame to AP21 over a communication link established between them (the two APs). In turn, AP21 receiving such TDLS Action frame transmits the received TDLS Action frame to associated STA B1 station over an operating channel of AP21 .

As shown, AP 1 12 relays the TDLS Discovery Request frame 221 , TDLS Setup Request frame 223, TDLS Setup Response frame 224 and TDLS Setup Confirm frame 225 between STA A2 and AP 192. And AP 192 in turn relays the TDLS Discovery Request frame 221 , TDLS Setup Request frame 223, TDLS Setup Response frame 224 and TDLS Setup Confirm frame 225 between AP 192 and STA B1 . In some embodiments, the relayed frames may also pass through the controller 180 as mentioned above.

In this timeline, each TDLS peer STA sends a P2P link report 715 to its associated AP because they are associated with different APs.

In a variant, the P2P link report from one of them may be forwarded by its associated AP to the controller and the controller may forward the report to the other APs of the ESS or of the non-collocated AP MLD.

TDLS peer STA A2 122 can then send P2P data traffic 226 to TDLS peer STA B1 141 . Besides, the timeline illustrates another use case in which a non-AP MLD initially has no NSTR constraints between its two affiliated stations operating on the AP links or between the stations STA A1 and STA A2 when the latter operates on an off-channel for P2P communication. However, AP1 111 may decide to change its operating channel by a channel switch procedure 720, resulting in link 1 of STA A1 (the new channel of AP1 111) becoming NSTR with link 2 of STA A2 when the latter operates on the off-channel for P2P communication. The AP MLD 110 may be unaware of this new constraint as this NSTR constraint is linked to the off-channel used for P2P. The channel switch in this case may trigger the sending of a P2P link report 715 by STA A1 to inform its AP about the newly formed NSTR link pair.

The timeline also shows a TDLS teardown 229 followed by the transmission of P2P link reports 715 by the two TDLS peer STAs.

Figure 7d illustrates P2P link reports that are sent in response to explicit requests from the AP, in case of TDLS session. As shown, a peer-to-peer link Event Request/Report procedure can be used. The P2P link report can also be sent in the Channel Usage Request during the usual Channel Usage Request/Response procedure.

Figure 7e illustrates a P2P link report that is sent in a Probe Request frame including a Channel Usage element during the procedure of association with the AP MLD that occurs after the P2P Group creation. As shown in this figure, a Probe Request/Response procedure can be used.

Figure 7f illustrates an example wherein a coexistence report is sent in response to explicit request from the AP. In other words, a station that supports Coexistence reporting (this capability may be indicated/shared during the association) may request to obtain Coexistence report from other stations.

In the example of Figure 7f, the STA A1 121 (affiliated to non-AP MLD A 102) is associated with AP11 111 (affiliated to AP MLD 110) and the STA B1 141 (affiliated to non-AP MLD B 104) is associated with AP21 191 (affiliated to AP MLD 190). The different stations support Coexistence reporting and have indicated this supported capability during the association with their respective AP. The two non-AP MLDs are about to establish a peer-to-peer link to directly communicate with each other.

After the association, AP1 111 may send a Coexistence Request frame 750 to its associated stations. The format of the Coexistence Request frame is further described with reference to Figure 10a. It includes Category field 581 , WNM field 582, Dialog token field 583, Coexistence Request Info Element field 1010, as follows:

Category field 581 is similar to Category field 300 described above (with value 10).

WNM field 582 defines the type of the frame. Any of the reserved values according to Table 9-510 in IEEE P802.11-REVme/D3.0, April 2023 can be used to signal the frame as being a Coexistence Request Frame. For example, WNM Action field is equal to 28.

Dialog Token field 583 is the nonzero value chosen by the STA sending the Coexistence Request frame to identify the req uest/res ponse transaction. Coexistence Request Info Element field 1010 includes one or more subfields, each being as follows: o OBSS subfield 1011 to request OBSS information (if any) to the receiving station.

This subfield may be one-bit long to request all information or several-bit long to specify which information the requesting station wants to obtain (e.g. Coexistence bitmap, OBSS list, schedule...) o P2P link subfield 1012 to request P2P link information (if any) to the receiving station. This subfield may be a one-bit long to request all information or several-bit long to specify which information the requesting station wants to obtain (other peer STA address, wake up schedule...) o Periodicity subfield 1013 to indicate the periodicity of the reporting. The periodicity may be for example set to ‘single’ meaning only one report is expected in response to the request, or to a value in units of TU meaning a report is expected at each such time period, or to ‘event based’ meaning a report is expected when a change in the condition occurs (e.g. new P2P link, end of P2P link, new OBSS or interference...)

Back to Figure 7f, upon reception of the Coexistence Request frame 750, station A1 121 responds with a Coexistence Report frame 751 which includes the information asked by the requesting station through field 1010 and its subfields. The Coexistence Report frame is described with reference to Figure 10b. It includes Category field 581 , WNM field 582, Dialog token field 583, Coexistence Report Elements field 1021 , as follows:

WNM field 582 defines the type of the frame. Any of the reserved values according to Table 9-510 in IEEE P802.11-REVme/D3.0, April 2023 can be used to signal the frame as being a Coexistence Report Frame. For example, WNM Action field is equal to 29.

Dialog Token field 583 is the nonzero value chosen by the STA sending the Coexistence Request frame to identify the request/response transaction.

Coexistence Report Elements field 1021 may include the different elements/ fields shown in Figure 4d, 4e, 5d and 5e. This element carries the information that are requested by the Coexistence Request Info 1010.

In some variants, when station A1 121 receives Coexistence request frame 750, the station may send a Beacon request frame 760 to its peer (station B1 141 in the example of the figure) so as to obtain information about the BSS of its peer and then to fill in the Coexistence report 751 accordingly. In response to the received beacon request from station STA A1 121 , station STA B1 141 sends a beacon report. Station A1 121 may also ask information about TWT in which the peer station could be involved in its own BSS. This information may be used for example to fill in the coexistence schedule field 464 in order to avoid concurrent communication for the two stations (STA A1 121 and STA B1 141) in their own BSS. Back to the Coexistence Report, when AP1 111 receives the information, it may create rules for the reporting station so as to improve the coexistence between the infrastructure communication 780 and the P2P communication 226 and/orthe communication 770 within OBSS.

Figure 9a schematically illustrates a communication device 900, either a non-AP MLD, embedding a plurality of non-AP stations 101-107, or an AP MLD, embedding a plurality of APs 110, of a radio network NETW, configured to implement at least one embodiment of the present invention. The communication device 900 may preferably be a device such as a micro-computer, a workstation or a light portable device. The communication device 900 comprises a communication bus 913 to which there are preferably connected: a central processing unit 901 , such as a processor, denoted CPU; a memory 903 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 902 connected to a wireless communication network, for example a communication network according to one of the IEEE 802.11 family of standards, via transmitting and receiving antennas 904.

Preferably the communication bus provides communication and interoperability between the various elements included in the communication device 900 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 900 directly or by means of another element of the communication device 900.

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 902, in order to be stored in the memory of the communication device 900 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 9b is a block diagram schematically illustrating the architecture of the communication device 900, adapted to carry out, at least partially, the invention. As illustrated, device 900 comprises a physical (PHY) layer block 923, a MAC layer block 922, and an application layer block 921 .

The PHY layer block 923 (here a multiple of 802.11 standardized PHY layer modules) has the task of formatting, modulating on or demodulating from any 20MHz channel or the composite channel, and thus sending or receiving frames over the radio medium NETW, such as 802.11 frames, for instance medium access trigger frames to reserve a transmission slot, MAC data and management frames based on a 20MHz width to interact with legacy 802.11 stations, 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 922 preferably comprises a MLE MAC 802.11 layer 924 implementing conventional 802.11 MAC operations, and additional block 925 for carrying out, at least partially, embodiments of the invention. The MAC layer block 922 may optionally be implemented in software, which software is loaded into RAM 903 and executed by CPU 901 . The MLE MAC 802.11 layer 924 may implement an Upper-MAC stack along with a series of Lower- MAC modules.

Preferably, the additional block 925, referred to as P2P management module for performing low-latency service for P2P streams over multi-link communications, implements part of embodiments of the invention (at a peer non-AP MLD). This block performs the operations of Figures 6 - 7 depending on the role of the communication device 900, TWT scheduling AP or peer station.

MAC 802.11-layer 924 and P2P management 925 interact one with the other in order to establish and process accurately communications over OFDMA RU in between multiple non-AP MLD stations according to embodiments of the invention.

On top of the Figure 9b, application layer block 921 runs an application that generates and receives data packets, for example data packets such as a video stream. Application layer block 921 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.

Many further modifications and variations will suggest themselves to those versed in the art upon referring to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular, the different features from different embodiments may be interchanged, where appropriate.

In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

1 . A method of communication in a wireless network comprising, at a non-access-point, non-AP, device having multiple stations operating on respective links: declaring, to an AP device, transmission constraints between links of the non-AP device; and sending, to the AP device, a Coexistence or P2P link report about an activity taking place on one of the constrained links.

2. The method of Claim 1 , further comprising determining the activity on the one constrained link by controlling an affiliated non-AP station of the non-AP device to participate in a peer-to-peer, P2P, session with a peer station over the one constrained link, wherein the Coexistence or P2P link report reports about the P2P session.

3. The method of Claim 2, wherein the non-AP device includes a P2P Concurrent Device hosting a first station associated with the AP device and a second station, collocated with the first station, that acts as a P2P Device operating in a P2P Group, wherein declaring the transmission constraints includes sending, by the first station to the AP device a capability for P2P concurrent mode of operation, and sending a Coexistence or P2P link report includes sending, by the first station to the AP device, Timing Information obtained by the collocated P2P Device about a P2P session, which Timing Information defines a period of P2P communication in the P2P session.

4. The method of Claim 3, wherein sending the obtained Timing Information includes sending a Channel Usage Request frame including a Target Wake Time (TWT) element representative of the Timing Information.

5. The method of Claim 3, wherein in case the P2P Device does not operate as a Group Owner of the P2P Group, the obtaining step includes receiving, from the P2P Group Owner by the collocated P2P Device, a Target Wake Time (TWT) element indicative of a P2P communication period or a Notice of Absence element indicative of a period of absence of P2P communication, and the sending step to the AP device includes sending a Channel Usage Request frame including a second Target Wake Time (TWT) element that includes Timing Information derived from the received TWT element or Notice of Absence element.

6. The method of Claim 3, wherein the first station acts as P2P Device operating in a second P2P Group and the AP device includes a soft AP operating as Group Owner of the second P2P Group.

7. The method of Claim 3, wherein the P2P Concurrent Device is a non-access-point, non-AP, multi-link device, MLD, having a first affiliated non-AP STA operating as WLAN Device in an infrastructure Basic Service Set and a second affiliated non-AP STA operating as P2P Device.

8. The method of Claim 1 , wherein the Coexistence or P2P link report is sent responsive to one of the following triggering events: creating a P2P session, such as establishing or joining a TDLS session or a P2P group, receiving, from the AP device, a Coexistence or P2P link report request frame, terminating a P2P session, such as tearing down a TDLS session or sending a disassociation frame for disassociating from a P2P group, enabling or disabling a transmission constraint between links, such as enabling or disabling enhanced multi-link single radio, EMLSR, operation for the links, or performing a Channel Switch modifying the STR or NSTR relationship between two links, switching the channel of a link on which a P2P session takes place to an off-channel that becomes NSTR with another link enabled with the AP device, switching the operating channel of a link of the AP device that becomes NSTR with the link on which a P2P session takes place, detecting an interference from an Overlapping Basic Service Set, OBSS, that disturbs a link of the non-AP device, obtaining Timing Information about a P2P session that defines a period of P2P communication in the P2P session or a power saving period for the affiliated non-AP station.

9. The method of Claim 1 , wherein the Coexistence or P2P link report is sent when enabling enhanced multi-link single radio, EMLSR, operation for the links.

10. The method of Claim 9, wherein enabling EMLSR operation for the links includes sending an EML Operating Mode Notification frame to the AP device.

11. The method of Claim 9, wherein the Coexistence or P2P link report includes a Coexistence Status field set to a first value to indicate the non-AP device has coexistence activities on one or more of the links, and otherwise, is set to a second value to indicate the non- AP device has no coexistence activities on one or more of the links.

12. The method of any preceding claim, wherein declaring the transmission constraints between the links includes activating an enhanced multi-link single radio, EMLSR, mode on the links.

13. The method of Claim 12, wherein activating the EMLSR mode includes sending an EML Operating Mode Notification frame to the AP device.

14. The method of any preceding claim, wherein the Coexistence or P2P link report includes the declaration of the transmission constraints between the links.

15. The method of Claim 1 , further comprising receiving, from the AP device, information enabling Coexistence or P2P link reporting, wherein the Coexistence or P2P link report is sent only when Coexistence or P2P link reporting is enabled.

16. A method of communication in a wireless network comprising, at an access-point, AP, device: receiving, from a non-AP device, a declaration about transmission constraints between links of the non-AP device, and a Coexistence or P2P link report about an activity that takes place on the one of the constrained links.

17. The method of Claim 16, wherein the Coexistence or P2P link report reports about a P2P session in which an affiliated non-AP station of the non-AP device participates with a peer station.

18. The method of Claim 16, further comprising sending, to the non-AP device, information enabling Coexistence or P2P link reporting to drive the non-AP device to send the Coexistence or P2P link report only when Coexistence or P2P link reporting is enabled.

19. The method of Claim 16, further including adapting communication in a Basic Service Set, BSS, managed by the AP device based on the received Coexistence or P2P link report.

20. The method of Claim 19, wherein adapting the communication in the BSS includes adapting communication to the non-AP device.

21. The method of Claim 19, wherein adapting the communication in the BSS is responsive to receiving the Coexistence or P2P link report reporting activity on EMLSR links of the non-AP device.

22. The method of Claim 16, further including adapting a scheduling of resources on the constrained links based on the received Coexistence or P2P link report.

23. The method of Claims 17 and 22, wherein adapting a scheduling includes one or more from amongst the following P2P rules: reducing or avoiding downlink communications to the non-AP device over the constrained links, enrolling the peer station in a TWT agreement negotiated with the non-AP device on the one constrained link, scheduling a TWT to be aligned to a period of P2P inactivity of peer stations of the P2P session as notified in the P2P link report.

24. The method of Claim 23, further including, responsive to receiving a P2P link report reporting a termination of the P2P session, releasing the adaptation of the scheduling.

25. The method of any one of Claims 16 to 24, further including selecting appropriate transmission parameters for the non-AP device.

26. The method of Claim 1 or 16 wherein the transmission constraints include a nonsimultaneous transmit and receive, NSTR, link pair or an enabled enhanced multi-link single radio, EMLSR, operation on the constrained links.

27. The method of Claim 26, wherein the NSTR link pair is signalled in the P2P link report.

28. The method of Claim 1 or 16, wherein the Coexistence or P2P link report includes a peer-to-peer link Event Report element or a Channel Usage element with a peer-to-peer link indication.

29. The method of Claim 28, wherein the peer-to-peer link Event Report element or Channel Usage element with peer-to-peer link indication includes one or more of the following fields: a Link ID field including an identifier of the link on which the P2P session takes place, a peer STA address field including an identifier of the peer station, a NSTR field reporting a non-simultaneous transmit and receive, NSTR, link pair of the non-AP device, and a Timing Information field specifying a period of P2P communication in the P2P session or a power saving period for the affiliated non-AP station, a P2P Session Identifier field including an identifier of the P2P session, and a P2P Session Status field including a current status of the P2P session.

30. The method of Claim 28, wherein the Channel Usage element with peer-to-peer link indication includes a peer-to-peer link Event Report element having one or more of said fields.

31. The method of Claim 1 or 16, wherein the Coexistence or P2P link report includes one or more of the following fields: a Link ID field including an identifier of the link on which the P2P session takes place, a peer STA address field including an identifier of the peer station, a Coexistence Indication Bitmap field indicating one or more pairs of links experiencing transmission constraints, an OBSS List Indication field indicating one or more overlapping Basic Service Sets that interfere with the constrained link, a Coexistence Schedule element indicating a time period when the constrained link experiences transmission constraints, and a Coexistence Status field indicating a current status of the transmission constraints.

32. The method of Claim 31 , wherein the Coexistence Status field is set to a first value to indicate the non-AP device has coexistence activities on one or more of own EMLSR links, and otherwise, is set to a second value to indicate the non-AP device has no coexistence activities on one or more of its own EMLSR links.

33. The method of Claim 1 or 12, wherein the Coexistence or P2P link report is included in a WNM Action frame having a WNM Action field value set to 1 to signal an Event Report Action frame or set to 21 to signal a Channel Usage Request Action frame or set to a reserved value between 28 and 255 to signal a Coexistence Report Action frame.

34. The method of Claim 15 or 18, wherein the information enabling the Coexistence or P2P link reporting includes at least one from: a peer-to-peer link Event Report element in a frame, a Channel Usage element with a peer-to-peer link indication in a frame, a P2P-related capability declared by the AP device in a frame.

35. The method of Claim 2 or 17, wherein the peer station is a non-AP MLD.

36. The method of Claim 1 or 16, wherein the non-AP device is a non-AP MLD.

37. The method of Claim 1 or 16, wherein the non-AP device or the AP device includes a soft AP operating as a Group Owner of a P2P Group.

38. The method of Claim 1 or 16, wherein the Coexistence or P2P link report is sent by an affiliated non-AP station of the non-AP device, said affiliated non-AP station participating in a P2P session on the one constrained link.

39. A frame to be sent by a non-access-point, non-AP, device to report about a P2P session in which it participates with a peer station, the frame including a peer-to-peer link Event Report element or Channel Usage element with a peer-to-peer link indication, the element including one or more of the following fields: a Link ID field including an identifier of the link on which the P2P session takes place, a peer STA address field including an identifier of the peer station, a NSTR field, including a non-simultaneous transmit and receive, NSTR, link pair of the non-AP device, and a Timing Information field specifying a period of P2P communication in the P2P session or a power saving period for the affiliated non-AP station, a P2P Session Identifier field including an identifier of the P2P session, and a P2P Session Status field including a current status of the P2P session.

40. A method of communication in a wireless network comprising, at a first access-point, AP, instantiated in a first communication device: receiving, from a first non-AP station associated with the first AP, a TDLS Action frame intended to a second non-AP station associated with a second AP instantiated in a second communication device physically separated from the first communication device, and forwarding the received TDLS Action frame to the second AP over a communication link established between the first and second communication device.

41. A method of communication in a wireless network comprising, at a second accesspoint, AP, instantiated in a second communication device: receiving, from a first access-point, AP, instantiated in a first communication device physically separated from the second communication device, a TDLS Action frame initiated by a first non-AP station associated with the first AP and intended to a second non-AP station associated with the second AP, and transmitting the received TDLS Action frame to the second non-AP station over an operating channel of the second AP.

42. A method of communication in a wireless network comprising, at a second non- access-point, non-AP, station that is associated with a second AP instantiated in a second communication device: receiving, from the second AP, a TDLS Action frame initiated by a first non-AP station, wherein the TDLS Action frame identifies an AP in a communication device physically separated from the second communication device, and in case the TDLS Action frame is intended to the second non-AP station, responding to the received TDLS Action frame with a TDLS Response frame addressed to the first non-AP station.

43. The method of Claim 40, 41 or 42, wherein the TDLS Action frame includes a TDLS Multi-Link element having a MLD MAC address in an AP MLD MAC Address field not matching an MLD MAC address of an AP MLD implementing the second AP as affiliated AP.

44. The method of Claim 40, 41 or 42, wherein the TDLS Action frame includes a TDLS Multi-Link element having a MLD MAC address in an AP MLD MAC Address field matching a logical MLD MAC address of an AP MLD implementing the second AP as affiliated AP and having an identifier in a physical device identifier field not matching a physical identifier of the second communication device.

45. The method of Claim 40, 41 or 42, wherein the first and second APs belong to the same ESS or belong to a logical AP MLD having two or more affiliated APs that are instantiated in physically separate communication devices.

46. The method of Claim 40, wherein the forwarding is made on the same channel as the one on which the TDLS Action frame is received or is made on an operating channel of the second AP determined, by the first AP, based on a correspondence table matching the second non-AP station with the second AP, or is made to through a backhaul link connecting a plurality of APs including the first and second APs.

47. A wireless communication device comprising at least one microprocessor configured for carrying out the steps of the method of Claim 1 , 16, 40, 41 or 42.

48. 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 , 16, 40, 41 or 42.