Improved coexistence link information reporting

Abstract

When the link of the non-AP MLD becomes an NSTR or EMLSR link and the non-AP MLD performs P2P communication or experiences OBSS interference on one of the constrained links, the non-AP MLD sends a coexistence link report regarding a P2P session or OBSS to the AP MLD. A channel usage request frame may be used. The AP MLD may take the action of reducing scheduling of non-AP MLDs involved in the P2P session that interfere with P2P communications, or avoiding scheduling of non-AP MLDs on links experiencing OBSS interference. When a P2P session is ongoing on a first constrained link, the AP MLD may refrain from scheduling downlink communications to a non-AP MLD on another constrained link. When the P2P session ends, or when the non-AP MLD becomes inactive for the P2P session, the AP MLD may also take action to relieve such limitation.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to wireless communications, and more specifically to Peer-to-Peer (P2P) communications. BACKGROUND

[0002] With the development of delay-sensitive applications such as online gaming, real-time video streaming, virtual reality, remote control of drones or robots, etc., better throughput, low latency, and robustness requirements and issues need to be considered. IEEE 802.11 Working Group is currently considering such questionable issues as the main purpose of issuing the next major 802.11 version (called 802.11be or EHT for “Extremely High Throughput”).

[0003] Low Latency Reliable Service (LLRS) has been defined as a target of such main purpose. LLRS is a service provided to higher layer traffic flows that prioritizes and delivers MSDUs (Data Units) within a worst-case latency budget with a given reliability / Packet Delivery Ratio (PDR) and low jitter.

[0004] IEEE P802.11be / D3.2 version (May 2023, below “D3.2 standard”) introduces Multi-Link (ML) Operation (MLO). MLO improves data throughput by allowing communication between stations over multiple concurrent and non-contiguous communication links.

[0005] Multi-Link Operation enables a non-AP (Access Point) MLD (ML Device) to register with an AP MLD, i.e., discover, authenticate, associate, and setup multiple links with the AP MLD. Each link enables channel access and frame exchange between the non-AP MLD and the AP MLD based on supported capabilities exchanged during association.

[0006] An MLD is a logical entity that has more than one affiliated station (AP or non-AP) and has a single MAC Service Access Point (SAP) for Logical Link Control (LLC) including one Medium Access Control (MAC) data service. Thus, an AP MLD consists of multiple affiliated APs, while a non-AP MLD consists of multiple affiliated non-AP stations. The affiliated stations in both AP MLD and non-AP MLD can communicate with the affiliated stations of another MLD on each of the setup multiple communication links using 802.11 mechanisms.

[0007] In MLD operation, simultaneous transmit and receive (STR) operation can be allowed. That is, an MLD can transmit on one link while receiving on another link. A non-AP MLD can be either STR or non-STR (NSTR). A NSTR non-AP MLD cannot receive on one of the links in a NSTR link pair concurrently with transmission on the other link.

[0008] Similarly, with the introduction of MLO, and the spatial multiplexing capability of MLDs, an MLD can operate according to various enhanced multi-link operation modes (EML OM), namely the mutually exclusive EMLSR (enhanced multi-link single radio) mode and EMLMR (enhanced multi-link multi radio) mode. In the EMLSR mode, while a non-AP MLD can simultaneously listen to a set of enabled links (so-called EMLSR links), it only receives and / or transmits data frames on one EMLSR link at a time. Again, a non-AP MLD in EMLSR mode cannot receive on one of the EMLSR links concurrently with transmission on the other link.

[0009] Thus, a NSTR link pair or an EMLSR link is a constrained link for a non-AP MLD. This can cause problems when one of the links experiences other communications, such as P2P communications from the non-AP MLD or interference from another BSS (called an overlapping BSS or OBSS).

[0010] Similar situations exist for P2P concurrent devices, one MAC entity operating within an infrastructure BSS and another second MAC entity dedicated to P2P communications.

[0011] To meet the low latency requirements in EHT and increase the efficiency of UL MU operation, existing mechanisms are reused and improved within the D3.2 standard, while other new mechanisms are added.

[0012] Exemplary mechanisms include the target wake-up time (TWT) mechanism, the trigger TXOP sharing (TXS) mechanism, the tunneled direct link setup (TDLS), the software AP (or soft AP).

[0013] TDLS and soft AP allow the establishment of a P2P session, thus allowing P2P (or direct link (DiL)) transmission between two peer MLDs concurrently with the existing AP-based infrastructure.

[0014] However, the coexistence between the infrastructure (AP) and P2P communications (through TDLS or non-infrastructure BSS, such as soft AP or Wi-Fi Direct Group Owner, etc.) or OBSS poses many problems for them to operate efficiently together.

[0015] For example, in MLO, a non-AP MLD can use one of the (permanently or non-permanently) constrained links for P2P communication (or this link can experience interference with OBSS) and use one of the constrained links for communication with its associated AP. However, due to NSTR or EMLSR constraints, the non-AP MLD cannot freely operate, which makes coexistence between infrastructure and P2P communication difficult, and especially makes it difficult for the AP to schedule 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 that is currently operating on another constrained link that is currently used for P2P communication and thus cannot receive and decode data from the AP MLD.

[0016] Moreover, the various mechanisms described above can cause problems. In the example of the TWT mechanism, a rTWT (restricted TWT) can be negotiated between an initiator affiliated non-AP station and an affiliated AP station. Since the rTWT does not involve another peer non-AP station of the P2P session, this other peer non-AP station can not be awake at the service period (SP) of the rTWT and thus will not be available for TXS-based P2P communication within the rTWT SP. The TXS mechanism is known to facilitate P2P communication within a TXOP obtained by the AP by sending a trigger frame (called MU-RTS TXS) specifying a duration of a portion of this TXOP allocated to the associated non-AP stations.

[0017] In other words, the D3.2 standard is currently unsatisfactory in terms of P2P or DiL (direct link) transmission and infrastructure coexistence. SUMMARY

[0018] The broad object of the present invention is to overcome some of the aforementioned problems, in particular to improve the coexistence of P2P transmission with infrastructure.

[0019] In this context, a non-AP MLD experiencing NSTR or EMLSR, or more generally a non-AP device having a constrained link and participating in a P2P session or having an OBSS in its vicinity, can report to the AP MLD or AP device some information about the P2P session or the OBSS in a coexistence or P2P link report for the AP MLD or device to properly schedule communications in its infrastructure network (BSS managed by its affiliated AP).

[0020] For example, a non-AP STA affiliated to a non-AP MLD can use TDLS channel switching to switch from the base channel of an enabled link to another channel (e.g. off-channel) for P2P communication. The AP MLD is now aware of this switch. This link can become an NSTR with another link enabled between the non-AP MLD and the AP MLD, while the AP MLD is not aware of this new NSTR constraint for the non-AP MLD.

[0021] Similarly, the affiliated AP can perform channel switching to change its operating band, resulting in a channel / link interfering with the channel / link of the P2P session, while the AP MLD is not aware of this new NSTR constraint for the non-AP MLD.

[0022] Therefore, the non-AP MLD preferably informs the AP MLD of the P2P communication and the NSTR constraint using a P2P link report. The channel usage element in a frame such as a channel usage request frame appears suitable to convey this information.

[0023] The frame can be sent on any of the two constrained links (NSTR link pair or EMLSR link) and more generally on any of the links enabled with the AP MLD. The channel usage element can include a link ID identifying the P2P link on which the P2P communication occurs, an NSTR bitmap identifying one or more other links constrained by the P2P link.

[0024] An identifier of the other (partner) peer non-AP station or MLD involved in the P2P communication can also be provided in the channel usage element for the AP MLD to adapt its scheduling in its infrastructure network also with respect to the other peer non-AP station or MLD.

[0025] Other information that can help enhance the scheduling can also be provided in the channel usage element, such as timing information on the period of P2P activity (e.g. P2P TWT) or power saving in the P2P session and P2P status of the P2P session (session activity, session termination).

[0026] In practice, other events, such as establishing a P2P session on a constrained link or ending such a P2P session, have an impact on the communication efficiency within the infrastructure network. The AP MLD can take the following actions (P2P rules): reduce the scheduling of non-AP MLDs (involved in the P2P session) that interfere with the P2P communication, or avoid scheduling non-AP MLDs on a link that experiences OBSS interference. For example, when a P2P session is ongoing on a first constrained link, the AP MLD can avoid scheduling downlink communication to a non-AP MLD on another constrained link. When the P2P session ends, or when the non-AP MLD becomes inactive (e.g., enters power save mode) for the P2P session, the AP MLD can also take actions to lift such P2P rules.

[0027] Embodiments thus propose a communication method in a wireless network, comprising, at a non-access point, non-AP, device having a plurality of stations operating on respective links:

[0028] Declaring to an AP device transmission constraints between the links of the non-AP device. The constrained links include, for example, EMSLR links or NSTR link pairs or links of a P2P concurrent device; and

[0029] Sending to the AP device a coexistence or P2P link report related to an activity (e.g., a P2P session) occurring on one of the constrained links.

[0030] The activity is determined on one of the constrained links. This can be implemented, for example, when the non-AP device controls a dependent non-AP station of the non-AP device to participate in a point-to-point, P2P, session with a peer station on one constrained link. Exemplary P2P sessions include a TDLS session established between enrolled non-AP MLDs or a P2P group established as an independent BSS or ad hoc network due to a soft-AP.

[0031] Correspondingly, a communication method in a wireless network is also proposed, comprising, at an access point, AP, device:

[0032] Receiving from a non-AP device a declaration of transmission constraints between the links of the non-AP device and a coexistence or P2P link report related to an activity (e.g., a P2P session of a dependent non-AP station of the non-AP MLD with a peer station) occurring on one of the constrained links.

[0033] As a result of the coexistence or P2P link report, the AP device becomes aware of P2P sessions or OBSS coexisting with its managed infrastructure network (BSS), in particular in relation to the known constrained links at the non-AP devices. This provides the AP device with more information to improve scheduling of non-AP stations on constrained links within its infrastructure network. Coexistence between P2P (or DiL for direct link) communications or OBSS and infrastructure communications can be enhanced.

[0034] The non-AP device can be a non-AP MLD or a standalone non-AP station. Similarly, the non-AP device or the AP device can comprise a soft-AP operating as a group owner of a P2P group. Thus, either of the non-AP device and the AP device can be a P2P concurrent device.

[0035] Optional features are defined below with reference to the method, which can be translated into device features.

[0036] In some embodiments, the method further comprises adapting communications in a basic service set (BSS) managed by the AP device based on the received coexistence or P2P link report. For example, adapting communications in the BSS can comprise adapting communications to the non-AP device. In particular, communications in the BSS can be adapted in response to receiving a coexistence or P2P link report reporting activity on an EMLSR link of the non-AP device.

[0037] In embodiments, the method further comprises adapting scheduling of resources on the constrained link based on the received coexistence or P2P link report.

[0038] Thus, the AP device can avoid any interference between communications scheduled on one of the constrained links within the infrastructure network and P2P communications or OBSS on another of the constrained links. Thus, infrastructure communications are not lost for non-AP devices conducting P2P communications or experiencing interference with OBSS at the same time.

[0039] In some embodiments, adapting the scheduling comprises one or more than one of the following P2P rules:

[0040] - reducing or avoiding downlink communications to the non-AP device on said constrained link,

[0041] - registering the peer station in a TWT agreement negotiated with the non-AP device on one constrained link,

[0042] - aligning the TWT schedule with a P2P inactivity period of the peer station of the P2P session informed in the P2P link report. The absence notification can reflect an indication of power save mode of the affiliated non-AP station involved in the P2P session.

[0043] In a particular embodiment, the method further includes: in response to receiving a P2P link report that reports the termination of a P2P session, de-adapting the scheduling, i.e., the applied P2P rules.

[0044] In some embodiments, the method further includes selecting appropriate transmission parameters for non-AP devices.

[0045] In some embodiments, transmission constraints include non-simultaneous transmit and receive (NSTR) link pairs, or enabled enhanced multi-link single radio (EMLSR) operation on constrained links.

[0046] Specifically, the NSTR link pair can be notified via signaling in the P2P link report.

[0047] In some embodiments, coexistence or P2P link reporting includes a point-to-point link event reporting element or a channel usage element with a point-to-point link indication. These elements may be in accordance with the IEEE 802.11 family of standards.

[0048] For example, a point-to-point link event reporting element or a channel usage element with a point-to-point link indication may include one or more of the following fields:

[0049] - The Link ID field includes an identifier of the link from which the P2P session took place.

[0050] - Peer STA address field, which includes the identifier of the peer station.

[0051] - NSTR fields (such as NSTR indicator bitmaps, etc.) report non-AP device non-simultaneous transmission and reception (NSTR) link pairs, and

[0052] - A timing information field that specifies the time period for P2P communication in the P2P session or the power-saving period for the affiliated non-AP station.

[0053] - The P2P session identifier field includes an identifier for the P2P session, and

[0054] - P2P session state field, which includes the current state of the P2P session.

[0055] In some embodiments, a channel usage element with a point-to-point link indication includes a point-to-point link event reporting element having one or more of the fields.

[0056] In some embodiments, the coexistence or P2P link report includes one or more of the following fields in the coexistence element:

[0057] - The Link ID field includes an identifier of the link from which the P2P session took place.

[0058] - Peer STA address field, which includes the identifier of the peer station.

[0059] - Coexistence indicator bitmap field, which indicates one or more link pairs experiencing transmission constraints.

[0060] - The OBSS list indicates a field that indicates one or more overlapping basic service sets that interfere with the constrained link.

[0061] - A coexistence scheduling element that indicates the time period during which the constrained link experiences transmission constraints, and

[0062] - Coexistence status field, which indicates the current state of the transmission constraint.

[0063] The coexistence status field can be set to a first value (e.g., 1) to indicate that a non-AP device has coexistence activity on one or more of its own EMLSR links, or otherwise set to a second value (e.g., 0) to indicate that a non-AP device does not have coexistence activity on one or more of its own EMLSR links.

[0064] In some embodiments, coexistence or P2P link reports are included in WNM action frames with a WNM (Wireless Network Management) action field value, which is set to 1 to signal an event report action frame, or set to 21 to signal a channel use request action frame, or set to a reserved value between 28 and 255 to signal a coexistence report action frame.

[0065] In some embodiments, the non-AP device comprises or is a P2P concurrent device carrying a first station associated with the AP device and a second station collocated with the first station, the second station acting as a P2P device operating in a P2P group. The declaration transmission constraint can then comprise sending, by the first station, to the AP device, a capability for a P2P concurrent operation mode, and the sending of the coexistence or P2P link report can comprise sending, by the first station, to the AP device, timing information obtained by the collocated P2P device about a P2P session (session in which the P2P device participates) defining a period of P2P communication in the P2P session. This allows the P2P concurrent device to alert the AP device of the timing information of the P2P communication period. As an example, the P2P concurrent device can obtain the timing information about the P2P session from a group owner of the P2P group and then report it to the AP device to which its WLAN STA is associated. In an alternative example, the P2P concurrent device can obtain the timing information from the AP device to which it is associated (negotiated P2P TWT) and then report it to the AP or soft-AP operating as a group owner of the P2P group. In both examples, the addressed AP device or soft-AP is then able to control the infrastructure communication (for the AP device) or the P2P communication (for the group owner) in a way that improves the coexistence between the infrastructure and P2P communications.

[0066] In particular embodiments, the sending of the obtained timing information comprises sending a channel usage request frame comprising a target wake time (TWT) element representing the timing information. By signaling the timing information of the P2P communication period for the P2P concurrent device, the TWT element thus indicates the absence of the WLAN device of the same P2P concurrent device.

[0067] In other particular embodiments, in case the P2P device does not operate as a group owner of a P2P group, the obtaining step comprises receiving, by the collocated P2P device, from the P2P group owner, a target wake time (TWT) element indicating a P2P communication period or an absence notification element indicating an absence period of P2P communication, and the sending step to the AP device comprises sending a channel usage request frame comprising a second target wake time (TWT) element comprising the timing information derived from the received TWT element or absence notification element. Thus, the P2P concurrent device operates any translation of the timing information provided in the received TWT element or absence notification element to the timing information for the AP device. In particular, the period dedicated to P2P communication is signaled.

[0068] In other particular embodiments, the first station operates as a P2P device in a second P2P group, and the AP device comprises a soft-AP operating as a group owner of the second P2P group. In these embodiments, the P2P concurrent device hosts two collocated stations operating as P2P devices in two separate P2P groups.

[0069] In other particular embodiments, the P2P concurrent device is a non- access point (non-AP) multi-link device (MLD) having a first dependent non-AP STA operating as a WLAN device in an infrastructure basic service set and a second dependent non-AP STA operating as a P2P device.

[0070] In some embodiments, the coexistence or P2P link report is sent in response to one of the following trigger events:

[0071] - creation of a P2P session, such as establishment or joining of a TDLS session or a P2P group,

[0072] - reception of a P2P link report request frame from the AP device,

[0073] - termination of a P2P session, such as teardown of a TDLS session or transmission of a disassociation frame for disassociation from a P2P group,

[0074] - enabling or disabling of transmission constraints between links, such as enabling or disabling of enhanced multi-link single radio (EMLSR) operation for a link, or performing a channel switch modifying the STR or NSTR relationship between two links,

[0075] - switching the channel of the link where the P2P session occurs to an off-channel that becomes NSTR with another enabled link of the AP device,

[0076] - switching the operating channel of the link of the AP device that becomes NSTR with the link where the P2P session occurs,

[0077] - detecting interference from an overlapping basic service set (OBSS) that disturbs the link of the non-AP device,

[0078] - obtaining timing information about a P2P session, the timing information defining a period of P2P communication in the P2P session or a power saving period of the dependent non-AP station.

[0079] In this context, particular embodiments related to EMLSR can provide for sending a coexistence or P2P link report when enhanced multi-link single radio (EMLSR) operation is enabled for a link. Enabling EMLSR operation for a link can comprise sending an EML operation mode notification frame to the AP device.

[0080] In embodiments, the coexistence or P2P link report includes a coexistence status field set to a first value (e.g., 1) to indicate that the non-AP device has coexistence activity on one or more of the links, and set to a second value (e.g., 0) to indicate that the non-AP device has no coexistence activity on one or more of the links.

[0081] Other specific embodiments provide that the declaration of transmission constraints between the links includes activating an enhanced multi-link single radio (EMLSR) mode on the links. In other words, advertising the link constraints when the EMLSR mode is activated. In this regard, activating the EMLSR mode can include sending an EML operation mode announcement frame to the AP device.

[0082] In specific embodiments, the coexistence or P2P link report includes a declaration of transmission constraints between the links. In other words, the same frame can be used to provide both the declaration of transmission constraints and the report on coexistence or P2P activity.

[0083] In particular embodiments, the method further includes receiving information from the AP device to enable the coexistence or P2P link report, wherein the coexistence or P2P link report is sent only when the coexistence or P2P link report is enabled.

[0084] Accordingly, the method further includes, at the AP MLD, sending information to the non-AP MLD to enable the coexistence or P2P link report to drive the non-AP device to send the coexistence or P2P link report only when the coexistence or P2P link report is enabled.

[0085] Thus, at each triggering event, the AP MLD alerts the non-AP MLD when a link report needs to be sent.

[0086] In some embodiments, the information to enable the coexistence or P2P link report includes at least one of:

[0087] a point-to-point link event report element in the frame (e.g., in an event report request frame),

[0088] a channel usage element with point-to-point link indication in the frame (e.g., in a channel usage request frame or a probe response frame),

[0089] a P2P related capability declared by the AP device in the frame (e.g., TDLS prohibited capability field set to 0 means TDLS is allowed, enabled point-to-point TWT support, etc.; e.g., in a beacon or probe response frame).

[0090] In some embodiments, the peer station is a non-AP MLD.

[0091] In other embodiments, the coexistence or P2P link report is sent by an affiliated non-AP station of a non-AP device that is involved in a P2P session over one constrained link. Thus, the report is sent over the link in which the P2P communication is instantiated. Note that in the case of channel departure, the non-AP station returns to the base channel of the link to send the report.

[0092] Embodiments of the invention also provide a frame sent by a non-access point device, non-AP device, for reporting on a P2P session with a peer station in which the non-AP device is involved, the frame comprising a point-to-point link event report element or a channel usage element with a point-to-point link indication, the point-to-point link event report element or the channel usage element with a point-to-point link indication comprising one or more than one of the following fields:

[0093] - a Link ID field comprising an identifier of the link over which the P2P session occurs,

[0094] - a Peer STA Address field comprising an identifier of the peer station,

[0095] - an NSTR field (e.g. NSTR bitmap) comprising non-simultaneous transmit and receive (NSTR) link pairs of the non-AP device, and

[0096] - a timing information field specifying a period of P2P communication in the P2P session or a power save period of the affiliated non-AP station,

[0097] - a P2P session identifier field comprising an identifier of the P2P session, and

[0098] - a P2P session status field comprising a current status of the P2P session.

[0099] Embodiments of the present disclosure allow establishing a TDLS session between stations that do not share the same AP device. This is made possible by the forwarding function of TDLS action frames between different AP devices. In this regard, 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:

[0100] receiving, from a first (peer) non-AP station associated with the first AP, a TDLS action frame destined for a second (peer) non-AP station associated with a second AP, the second AP being instantiated in a second communication device physically separate from the first communication device, and

[0101] forwarding the received TDLS action frame to the second AP over a communication link established between the first communication device and the second communication device.

[0102] The frame itself can specify 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.

[0103] Correspondingly, a communication method in a wireless network is also proposed, wherein the method comprises, at a second Access Point (AP) instantiated in a second communication device:

[0104] receiving a TDLS Action frame from a first AP instantiated in a first communication device physically separate from the second communication device, the TDLS Action frame being initiated by a first non-AP station associated with the first AP and being destined to a second non-AP station associated with the second AP, and

[0105] transmitting the received TDLS Action frame to the second non-AP station on an operating channel of the second AP.

[0106] This method allows to overcome the known limitation of TDLS (the two TDLS peer STAs must be associated with the same BSS (thus with an AP), or with a co-located AP MLD, because TDLS frames with different MLD MAC addresses of their own AP MLD are discarded) through a forwarding mechanism between two non-collocated APs (not carried in the same physical device as for co-located AP MLDs).

[0107] As a result, the discard processing for filtering received frames is modified at the TDLS peer stations. In this respect, a communication method in a wireless network is also proposed, wherein the method comprises, at a second non-Access Point (non-AP) station associated with a second AP instantiated in a second communication device:

[0108] receiving a TDLS Action frame from the second AP initiated by a first non-AP station, wherein the TDLS Action frame identifies an AP in a communication device physically separate from the second communication device. The identification field can comprise a (physical) AP MAC address that does not match the (physical) MAC address of the second AP,

[0109] responding to the received TDLS Action frame with a TDLS Response frame addressed to the first non-AP station, in case the TDLS Action frame is destined to the second non-AP station.

[0110] The regular criteria on the identity (e.g. MAC address) of the AP are no longer considered to handle (to discard when involving another infrastructure BSS) TDLS action frames (and thus responses to them). In some embodiments, the TDLS action frame (such as a TDLS Discovery Request frame) includes a TDLS Multi-Link element with a MLD MAC address in the AP MLD MAC address field that does not match the MLD MAC address of the AP MLD implementing the second AP as a dependent AP. This can correspond to a scenario where the two AP MLDs instantiating the first and second APs are different AP MLDs within an ESS.

[0111] In other embodiments related to a non-collocated AP MLD (i.e. logical AP MLDs each having a dependent AP instantiated in physically separate devices), the TDLS action frame includes a TDLS Multi-Link element with a MLD MAC address in the AP MLD MAC address field that matches the logical MLD MAC address of the AP MLD implementing the second AP as a dependent AP, and with an identifier in the physical device identifier field that does not match the 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.

[0112] This filtering method can apply to any TDLS action frame and its corresponding response. TDLS action frames related to an ESS scenario or a non-collocated AP MLD scenario are no longer discarded by the station.

[0113] In embodiments, the first and second APs belong to the same ESS. In the above variant, they belong to a logical AP MLD with two or more dependent APs instantiated in physically separate communication devices. More generally, the two APs are instantiated by physically separate devices.

[0114] The above frame exchange (TDLS action frame and possible response) can belong to a more complex procedure where multiple exchanges (frames) are made in both directions.

[0115] In embodiments, the forwarding is made on the same channel as the channel on which the TDLS action frame is received. In a variant, the forwarding is made on the operating channel of the second AP. A corresponding table can help the first AP determine the (second) AP to which the second non-AP station is associated. In another variant, the forwarding is made through a backhaul link connecting multiple APs including the first and second APs. In particular, the TDLS action frame can be forwarded to a controller of the backhaul link which in turn forwards the frame to the second AP.

[0116] Relatedly, the present application also provides a wireless communication device comprising at least one microprocessor configured for performing the steps of any of the above methods. The wireless communication device can be any of a non-AP MLD and an AP MLD.

[0117] Another aspect of the present application 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 of the methods as defined above.

[0118] At least part of the method according to the present application can be computer implemented. Thus, the present application can 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 can all generally be referred to herein as a “circuit”, “module” or “system”. Furthermore, the present application can take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

[0119] Since the present application can be implemented in software, the present application can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible, non-transitory carrier medium can include 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, etc. A transient carrier medium can include a signal such as an electrical signal, an electronic signal, an optical signal, a magnetic signal or an electromagnetic signal (e.g. microwave or RF signal) etc. BRIEF DESCRIPTION OF DRAWINGS

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

[0121] Figure 1 A typical wireless communication system in which embodiments of the present application can be implemented is illustrated;

[0122] Figure 1a , Figure 1b and Figure 1c Different examples of a typical 802.11 network environment between MLDs are illustrated, in which point-to-point communication occurs concurrently with communication (in time or frequency) utilizing an AP MLD;

[0123] Figure 1a1 A possible scenario in which a P2P traffic is handled by an initiator peer non-AP STA (a dependent non-AP STA) is illustrated using frame exchange in a timeline; Figure 1a

[0124] Figure 1b1 ​The exchange of frames in a timeline illustrates the possible scenario of forming a P2P group by two peer stations that belong to or do not belong to Figure 1b

[0125] Figure 1d An example of a typical 802.11 network environment between MLDs in different BSSs that occur concurrent communications and produce coexistence issues is illustrated;

[0126] Figure 2 The event reporting procedure according to the 802.11 standard is illustrated using the exchange of frames in a timeline;

[0127] Figure 3a The format of the event request frame according to the 802.11 standard is illustrated;

[0128] Figure 3b The possible values of the event type field of the Figure 3a

[0129] The format of the event report frame according to the 802.11 standard is illustrated; Figure 3c

[0130] An exemplary table of event types according to embodiments different from the table of Figure 3d Figure 3b

[0131] Figure 4a The format of the point-to-point link event request field included in the point-to-point link event request element according to the 802.11 standard is illustrated;

[0132] Figure 4b The format of the point-to-point link event report element included in the point-to-point link event report element according to the 802.11 standard is illustrated;

[0133] Figure 4c The possible values of the peer state field of the Figure 4b

[0134] An extended format of the point-to-point link event report element according to embodiments of the present invention is illustrated; Figure 4d

[0135] The format of the coexistence element according to embodiments of the present invention is illustrated; Figure 4e

[0136] The format of the channel usage element according to the 802.11 standard is illustrated; Figure 5a

[0137] The format of the channel usage request frame according to the 802.11 standard is illustrated; Figure 5b

[0138] The format of the channel usage request frame according to the 802.11 standard is illustrated;​​​Figure 5c An example of the format of a channel usage response frame according to the 802.11 standard is illustrated;

[0139] Figure 5d An example of an extended format of a channel usage request frame according to embodiments of the application is illustrated;

[0140] Figure 5e Another example of an extended format of a channel usage request frame according to embodiments of the application is illustrated;

[0141] Figure 6a And Figure 6b Flow diagrams are used to illustrate exemplary steps at an AP MLD (or AP) and an associated non-AP MLD (or station) to report P2P activity according to some embodiments of the application;

[0142] Figure 7a Scenarios with coexistence or P2P link reporting according to embodiments of the application are illustrated using frame exchanges in timelines; Figure 1a

[0143] Scenarios with coexistence or P2P link reporting according to embodiments of the application are illustrated using frame exchanges in timelines; Figure 7b Figure 1b Scenarios with coexistence or P2P link reporting according to embodiments of the application are illustrated using frame exchanges in timelines;

[0144] Figure 7c Figure 1c Scenarios with coexistence or P2P link reporting according to embodiments of the application are illustrated using frame exchanges in timelines;

[0145] Figure 7d Coexistence or P2P link reports sent in response to an explicit request from an AP according to embodiments of the application are illustrated;

[0146] Figure 7e Coexistence or P2P link reports sent during association with an AP MLD according to embodiments of the application are illustrated;

[0147] Figure 7f Coexistence reports sent in response to an explicit coexistence request from an AP according to embodiments of the application are illustrated;

[0148] Figure 7g Coexistence reports sent to a soft AP acting as a group owner according to embodiments of the application are illustrated;

[0149] Figure 8a A format of an Absence Notification element according to the Wi-Fi Alliance specification is illustrated;

[0150] Figure 8b A format of a TWT element according to the 802.11 standard is illustrated; ​​

[0151] Figure 8c The format of a wake-up schedule element according to the 802.11 standard is exemplified;

[0152] Figure 9a An exemplified representation of a communication device according to at least one embodiment of the present application is exemplified;

[0153] Figure 9b The architecture of a communication device according to Figure 9a is exemplarily illustrated;

[0154] Figure 10a The format of a coexistence request frame according to an embodiment of the present application is exemplified;

[0155] Figure 10b The format of a coexistence report frame according to an embodiment of the present application is exemplified; and

[0156] Figure 11 The format of a coexistence report frame according to an embodiment of the present application is exemplified; and DETAILED DESCRIPTION

[0157] The techniques described herein can be used for various broadband wireless communication systems, including communication systems that are based on orthogonal multiplexing schemes. Examples of such communication systems include Spatial Division Multiple Access (SDMA), Time Division Multiple Access (TDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, and Single-Carrier Frequency Division Multiple Access (SC-FDMA) systems. An SDMA system can utilize sufficiently different directions to simultaneously transmit data belonging to multiple user terminals, that is, wireless devices or stations. A TDMA system can allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units, each of which can be assigned to different user terminals. 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. The sub-carriers can also be called tones, bins, etc. With OFDM, each sub-carrier can be independently modulated with data. An SC-FDMA system can utilize Interlaced 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 sub-carriers.

[0158] The teachings herein can 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 can comprise an access point (so-called AP) or not comprise an access point (so-called non-AP station or STA).

[0159] Although the examples are described in the context of WiFi (RTM) networks, the invention can be used in any type of wireless network, such as mobile phone cellular networks implementing very similar mechanisms.

[0160] An AP can comprise, be implemented as, or known as, a NodeB, a Radio Network Controller (RNC), an eNode B (eNB), a 5G Next Generation Base Station (gNB), a Base Station Controller (BSC), a Base Transceiver Station (BTS), a Base Station (BS), a Transceiver Function (TF), a Radio Router, a Radio Transceiver, a Basic Service Set (BSS), an Extended Service Set (ESS), a Radio Base Station (RBS), or some other terminology.

[0161] A non-AP station can 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, a user equipment (UE), a user station, or some other terminology. In some implementations, a STA can 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 can 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 can be a wireless node. Such wireless node can 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.

[0162] An AP manages a set of stations that together organize their access to the wireless medium for communication purposes. The stations, including the AP, form a service set, hereinafter referred to as a basic service set BSS (although other terminology can be used). The same physical station acting as an access point can manage two or more BSSs (and thus corresponding WLANs): each BSS is thus uniquely identified by a specific basic service set identifier (BSSID) and managed by a separate virtual AP implemented in the physical AP.

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

[0164] The current discussion in Task Group 802.11be introduces Multi-Link Operation (MLO) when it comes to MAC layer operations, as shown in draft IEEE P802.11be / D3.2, May 2023. MLO allows a multi-link device to establish or set up multiple links and operate them simultaneously.

[0165] A Multi-Link Device (MLD) is a logical entity and has more than one affiliated (AP or non-AP) Station (STA) and has a single Medium Access Control (MAC) Service Access Point (SAP) for Logical Link Control (LLC) that includes one MAC Data Service. In addition, the MLD also includes a single address associated with an interface that can be used to communicate on a Distributed System Medium (DSM).

[0166] Stations forming the same MLD can be partially or fully collocated within the same device or geographically dispersed.

[0167] An Access Point Multi-Link Device (or AP MLD) corresponds to an MLD where each Station (STA) affiliated to the MLD is an AP, and is therefore referred to as “affiliated AP” in the following.

[0168] A non-Access Point Multi-Link Device (or non-AP MLD) corresponds to an MLD where each Station (STA) affiliated to the MLD is a non-AP STA, referred to as “affiliated non-AP Station”.

[0169] When referring to an AP MLD or a non-AP MLD in the following, the generic term “Station MLD” can be used.

[0170] Depending on the literature, “Multi-Link Device”, “ML Device” (MLD), “Multi-Link Logical Entity”, “ML Logical Entity” (MLE), “Multi-Link Set” and “ML Set” are synonyms designating the same type of ML Device.

[0171] Then, multiple affiliated non-AP STAs of a non-AP MLD can set up communication links with multiple affiliated APs of an AP MLD, thereby forming a multi-link channel. This is done for example through a regular association procedure: ML discovery including passive scanning (ML Beacon) or active scanning (ML Probe Request and corresponding response), followed by ML authentication, and finally ML setup, where in the ML setup the non-AP MLD is associated with the AP MLD (and thus obtains an Association Identifier (AID)) and sets up the ML links for the affiliated non-AP STAs of the non-AP MLD with the APs affiliated to the AP MLD.

[0172] The links established towards an MLD (or“enabled links”) are theoretically independent, meaning that the channel access procedures (to the communication medium) and the communications are independently conducted on the individual links. Thus, different links can have different data rates (e.g., due to different bandwidths, number of antennas, etc.), and can be used to communicate different types of information (each information on a specific link).

[0173] Thus, a communication link or“link” corresponds to a given channel (e.g., 20MHz and 40MHz, etc.) in a given frequency band (e.g., 2.4GHz, 5GHz, 6GHz) between an AP attached to an AP MLD and a non-AP STA attached to a non-AP MLD.

[0174] The attached AP and non-AP STA operate on their respective channels according to one or more than one of the IEEE 802.11 standards (a / b / g / n / ac / ad / af / ah / aj / ay / ax / be) or other wireless communication standards.

[0175] Thanks to the multi-link aggregation, the traffic associated with a single MLD can be theoretically transmitted across multiple parallel communication links, thus increasing the network capacity and maximizing the utilization of the available resources.

[0176] Although not an MLD, a P2P concurrent device is composed of two separate MAC entities: a first MAC entity operating as a WLAN STA (thus being associated with an AP), and a second MAC entity operating as a P2P device (thus being involved in P2P operations).

[0177] Figure 1 An example wireless communication system is illustrated, in which a number of communication station devices 101-107, 110 exchange data frames on a radio transmission channel 100 of a wireless local area network (WLAN) under the management of a central station, i.e. an access point device (AP) 110. Direct communication between STAs can also be implemented without using an access point (referred to as ad-hoc mode). The radio transmission channel 100 is defined by an operating frequency band, which is constituted by a single channel, a plurality of channels forming a composite channel, or a plurality of different channels (links) forming a multi-link operation.

[0178] In the following description, the term“station” or“STA” can be used to describe a non-AP station operating on a given link of 100, which can be a standalone non-AP station or an attached 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 can be a standalone AP station or an attached AP station entity of an AP MLD device.

[0179] An exemplary scenario of direct communication corresponding to today's increasing trend includes the presence of point-to-point (P2P, also called direct link or "DiL") transmissions between non-AP stations (e.g. STAs 102 and 104 as illustrated). Technologies supporting P2P transmissions are e.g. WiFi-Miracast (RTM) or wireless display scenarios, or Tunneled Direct Link Setup (TDLS), or "software access point" (soft-AP). Note that even though P2P streams are usually not numerous, the amount of data per stream can be large (typically low-compression video from 1080p60 up to 8K UHD resolution).

[0180] The various STAs 101-107 register with the AP 110 during an association procedure. During the association procedure, the AP 110 allocates a specific association identifier (AID) to the requesting STA. The AID is a 16-bit value that uniquely identifies the STA, for example. When the AP and the non-AP STA are a dependent AP of an AP MLD and a dependent non-AP of a non-AP MLD, respectively, they establish an ML association in which a unique AID is allocated to the entire non-AP MLD: all dependent non-AP STAs are identified by the same AID value on their respective operating links.

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

[0182] Previously recognized by the IEEE 802.11z standard in 2008, TDLS enables devices (called TDLS peers) to link directly to each other while connected to a regular AP. To setup and maintain the direct link, the two TDLS peers are associated with the same infrastructure BSS (in short, the same AP). The TDLS mechanism provides the encapsulation of setup frames exchanged between the two TDLS peers in data frames. This allows the setup frames to be transmitted (or "tunneled") transparently through the AP. As illustrated below, for example, reference is made to Figure 1a1TDLS setup frames. Moreover, since setup frames are transmitted transparently through the AP, the AP does not need to be aware of TDLS or have the same capabilities as the TDLS peer STAs involved in the TDLS-based point-to-point communication. Then, once the direct link is setup, the TDLS peer STAs can directly communicate with each other 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 directly communicate 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 on the same communication link (i.e., the same frequency channel).

[0183] As an alternative to P2P transmission through TDLS, the "software access point" (soft AP) is a way to support Wi-Fi Direct. Indeed, in Wi-Fi Direct similar to soft AP, one of the P2P stations takes the lead of the P2P group to conduct direct communication by providing some AP functionality (such as discovery and registration services, etc.) to the other P2P stations. Soft AP denotes a software-enabled AP, and means software that enables a device that has not been specifically manufactured as a router in a wireless AP to operate as a soft AP. The use of "software access point" (soft AP) is a new trend that, in addition to not requiring the use of a central access point provided as infrastructure of a WLAN, allows devices to communicate directly with each other using a method similar to a regular WLAN.

[0184] To reduce the contention with the infrastructure (i.e., with traffic involving the AP), a switch between the channel used by the AP (called "base channel") and an associated off-channel has been proposed. This mechanism is called "TDLS channel switch".

[0185] IEEE P802.11-REVme / D3.0 version (April 2023) defines an off-channel. An off-channel is a channel used by a TDLS peer STA that does not overlap with the channel(s) used by the AP to which the TDLS peer STA is associated. In other words, an off-channel is a channel that is not part of the operating channel(s) of the AP and that can be used for P2P communication. A TDLS device can negotiate to move (i.e., switch) from a base channel (i.e., a channel shared with the AP and used to setup a TDLS direct link) to such an off-channel (a channel not shared with the AP). The two TDLS devices advertise that they support at least partially the same channel(s) including the off-channel in TDLS setup frames (typically a request and a response) beforehand. 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 active service period with the AP.

[0186] When operating via off-channel, the TDLS device remains in power save mode in the base channel and is no longer able to communicate with the AP. Thus, the TDLS device must periodically, and thus repeatedly, return to the base channel to perform some actions such as receiving beacons, looking at the TIM for any buffered packets, and communicating with other devices in the network, etc.

[0187] In addition to the traditional off-channel management, the IEEE P802.11-REVme / D3.0 version (April 2023) recently adopted an improvement of the channel usage procedure by adding a new usage mode (value set to 2 in the channel usage element, see Figure 5a ) that allows a non-AP STA to request assistance from its associated AP to setup a non-infrastructure BSS on an off-channel that does not overlap with the operating channel of any AP belonging to the ESS of its associated AP. In addition, the recent modification of the standard allows a non-AP STA to negotiate with its associated AP the establishment of a point-to-point TWT agreement through the channel usage procedure (request / response) in this case including a TWT element. The point-to-point TWT so negotiated can be used for off-channel TDLS (usage mode set to 1) or non-infrastructure BSS (typically soft-AP) (usage mode set to 2).

[0188] The Target Wake Time (TWT) mechanism initially defined in the IEEE 802.11ah and 802.11ax standards has been adapted to be included in the 802.11be standard. The adaptation is referred to as Restricted Target Wake Time (rTWT) which schedules dedicated (and protected) Service Periods (SPs) for stations to transmit their (one or more) delay-sensitive traffic on the BSS of these stations. The rTWT agreement is merely a broadcast TWT agreement negotiated between an AP and the associated non-AP stations of the BSS of a given link. A non-AP station establishes membership in the broadcast TWT (or rTWT) schedule with the AP. Using the rTWT information (typically a Broadcast TWT ID (bTWT ID)) about the negotiated rTWT SPs, 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).

[0189] The D3.2 standard has adapted point-to-point functionalities (such as TDLS or Wi-Fi Direct, etc.) with the support of software access points to enhance P2P communication. For example, Tunnel Direct Link Setup (TDLS) has been adapted to coexist with MLDs by signaling the adjustment of MAC addresses in setup frames when establishing a TDLS session on one of the multiple setup links. As a result, a direct link is established between two wireless STAs (TDLS peer STAs) consisting of a single communication link (e.g., a 20 MHz channel on any of the 2.4, 5, and 6 GHz bands), where each wireless STA is affiliated with an MLD. In addition, the soft AP in the D3.2 standard allows a non-AP MLD to transition in time to assume AP functionality, which means that all its affiliated stations assume AP behavior as soft APs on their respective channels.

[0190] However, due to the multi-link nature of the communication, the P2P capabilities of the non-AP MLD face some communication limitations at the non-AP MLD.

[0191] The non-AP MLD can be non-STR (NSTR (non-simultaneous transmission and reception)), which means that the MLD cannot transmit on one link while receiving on another link (and vice versa). These links are referred to as a “NSTR link pair”. It is a pair of links corresponding to stations affiliated with the MLD for which the receiver requirements according to the Extremely High Throughput (EHT) PHY specification are not met on one link while a station affiliated with the MLD is transmitting on the other link. Each link in such a pair is a member of the NSTR link pair.

[0192] In addition, the non-AP MLD can operate according to an enhanced multi-link operation mode (EML OM) as introduced in the D3.2 standard (i.e., the mutually exclusive EMLSR (enhanced multi-link single radio) mode and EMLMR (enhanced multi-link multi radio) mode). In the operation mode, the activation and deactivation of the EML operation mode are initiated by the non-AP MLD, which sends a specific EHT action frame called “EML OM notification”.

[0193] The EMLMR mode, once activated, allows the non-AP MLD to simultaneously listen to the set of enabled links (typically a so-called EMLMR link consisting of two enabled links) to receive the initial frames transmitted by the AP MLD to initiate the frame exchange, and then aggregate some physical resources of the different radios of the non-AP MLD used on the different links (so-called EMLMR links) to transmit or receive data on one EMLMR link (typically the one on which the initial frames were received) at a time up to a predefined number of supported Rx / Tx spatial streams. This number can be greater than the number of supported Rx / Tx spatial streams of the individual radios.

[0194] The EMLSR mode, once activated, allows the non-AP MLD to simultaneously listen to the set of enabled links (typically a so-called EMLSR link consisting of two enabled links) to receive the initial control frames (e.g. MU-RTS trigger frame, BSRP trigger frame) from the AP MLD to initiate the frame exchange, and then perform the data frame exchange with the AP MLD on one EMLSR link (typically the one on which the initial control frames were received) at a time.

[0195] In the context of Wi-Fi Direct, a P2P group consists of P2P devices, one of which acts as a soft-AP (called P2P group owner) while another acts as a P2P client. A P2P concurrent device is a P2P device with one MAC entity operating as a WLAN STA and a second MAC entity operating as a P2P device. A P2P concurrent device can be a single-radio device or a multi-radio device. Thereby, a P2P concurrent device is subject to similar aforementioned constraints, in such a way that the WLAN STA and the P2P device are concurrent and the two entities of the P2P concurrent device can be similarly constrained links of an MLD.

[0196] When P2P communication of a non-AP MLD (e.g. a TDLS non-AP MLD with NSTR or EMLSR restrictions or a soft / mobile AP MLD) coexists with an infrastructure network with its own communication, such constraints on the links (NSTR link pair or EMLSR link or links of a P2P concurrent device) cause problems. It would be appropriate if the AP or AP MLD could take these constraints into account in the communication schedule within its infrastructure network to prevent concurrent transmission and reception on the constrained links of the non-AP MLD and / or P2P concurrent device (i.e. schedule downlink and uplink during overlapping time periods).

[0197] Furthermore, the D3.2 standard specifies that the TWT mechanism can be used at the dependent station level (i.e. by individual dependent non-AP stations of a non-AP MLD). Improved transmission scheduling within the infrastructure network can take into account the TWT particularities.

[0198] Figure 1a 、 Figure 1b and Figure 1c Different examples of a typical 802.11 network environment between MLDs are illustrated, in which point-to-point communication occurs concurrently (in time or frequency) with communication utilizing an AP MLD. In the examples of the following figures, stations with the same color share the same operating channel.

[0199] Figure 1a An example is illustrated in which two non-AP MLDs 102 and 104 are associated with an AP MLD 110. The two non-AP MLDs communicate directly with each other through a point-to-point link 173 established according to a TDLS or WiFi Direct procedure.

[0200] The AP MLD 110 has multiple affiliated APs, exemplified by two affiliated APs 111 and 112 (also labeled AP1, AP2, respectively) in the example of Figure 1a Each affiliated AP behaves as an 802.11 AP on an operating channel within one of its frequency bands. Known 802.11 frequency bands include the 2.4 GHz band, the 5 GHz band, and the 6 GHz band. Of course, other frequency bands can be used instead of or in addition to these three.

[0201] 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) in which it is registered. In the example of Figure 1a In the example of

[0202] For example, the AP 111 is set to operate on channel 38 corresponding to a 40 MHz channel of operation in the 5 GHz band, and the AP 112 is also set to operate on channel 151 corresponding to another 40 MHz channel of operation in the 5 GHz band. In another example, the affiliated APs can operate on different frequency bands.

[0203] Each of the affiliated APs provides a link to the affiliated non-AP STA of the non-AP MLD (102 or 104) towards the AP MLD 110. Thus, the link of each non-AP MLD can be identified with the identifier of the respective affiliated AP only. In this context, the affiliated APs 111 and 112 can each 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. The AP MLD 110 can assign the link ID to its affiliated APs by incrementing the ID from 0 (for the first affiliated AP). Of course, other wording can be used in variants, such as “AP ID” or the like.

[0204] For multi-link communication, each non-AP MLD 102, 104 must discover, authenticate, associate and setup multiple links with the AP MLD 110, where each link is established between an affiliated AP of the AP MLD 110 and an affiliated non-AP STA of the non-AP MLD. Such setup communication links, referred to as “enabled links”, each enable separate channel access and frame exchange between the non-AP MLD and the AP MLD based on supported capabilities exchanged during association.

[0205] During the ML setup procedure, the non-AP MLDs declare part or all of their capabilities. For example, they can declare their Tunnel Direct Link Setup (TDLS) capability, which enables stations of the non-AP MLDs (referred to as TDLS peer STAs) to communicate directly with each other while connected to a regular AP. To this end, appropriate fields are provided in management frames. Indeed, in all management frames, a non-AP MLD acting as a TDLS initiator STA or a TDLS responder STA (dot11TunneledDirectLinkSetupImplemented is true) sets the TDLS support bit (bit 37) in the extended capabilities element to 1.

[0206] Similar to TDLS support, a non-AP MLD or an AP MLD can also declare: whether channel usage is activated (dot11ChannelUsageActivated is true) allowing 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 event reporting is activated (dot11EventsActivated is true) allowing its affiliated STAs to use event request / report messaging by setting the event bit (bit 7) in the extended capabilities element to 1. In addition, TIM broadcast capabilities (bit 18), TDLS peer PSM (power save mode) support capabilities (bit 29), TDLS channel switch capabilities (bit 30), TDLS disallow capabilities (bit 38), TDLS channel switch disallow capabilities (bit 39), FILS capabilities (bit 72), TWT requester support capabilities (bit 77), TWT responder support capabilities (bit 78), and / or point-to-point TWT support (bit 100) can also be signaled as enabled in the extended capabilities element.

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

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

[0209] Reference is now made to Figure 1a1 to illustrate the single-link TDLS direct link mechanism in the context of MLDs, Figure 1a1 The possible scenarios of the initiator peer non-AP STA (affiliated non-AP STA) handling P2P traffic are exemplified using the frame exchanges in the timeline.

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

[0211] In this sequence, once STA A2 and STA B2 are associated with the AP (association not shown), they can exchange data over their operating link through the AP.

[0212] To reduce the amount of traffic delivered in the network and prevent congestion at AP 112, they can set up a TDLS session (i.e. a direct link between them) to exchange data directly (P2P communication), while still remaining associated with the AP.

[0213] In the sequence shown, a TDLS session or “TDLS direct link” is established between STA A2 and STA B2 (either of these can be the initiator of the TDLS direct link setup). This setup can include an (optional) TDLS discovery procedure and a TDLS setup procedure.

[0214] The TDLS discovery and setup procedure between STA A2 and STA B2 involves frames (called TDLS action frames) that are typically transmitted and received via the intermediate AP 112. The TDLS procedure is characterized by encapsulating the signaling frames (TDLS action frames) in 802.11 data frames, which allows them to be transmitted transparently through the AP.

[0215] When attempting to discover a TDLS station in the same BSS, a series of frame exchanges is used. STA A2 (which is the initiator in the scenario presented) sends a TDLS discovery request frame 221 to the individual destination station (here, STA B2), which is tunneled through AP 112 (relayed by the black dot).

[0216] The 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 AP 112 relaying).

[0217] From that point, STA A2 and STA B2 know each other, which means they know that the other party is operating on a communication link setup with AP 112. They can then establish a TDLS direct link.

[0218] When trying to establish a TDLS direct link on a single link with a discovered TDLS station, a series of TDLS Action frame exchanges are used to setup the single link TDLS direct link.

[0219] The TDLS initiator STA A2 first sends a TDLS Setup Request frame 223 tunneled through the AP 112 (relay illustrated by the black dot) to the target TDLS Responder STA B2. This request frame conveys the "Link Identifier" element and the "TDLS Multi-Link" element in the available IEs defined in Table 9-497 of IEEE 802.11-REVme / D1.3 (June 2022) which includes information about the capabilities of the TDLS initiator STA Al (such as power save, etc.) and its AID.

[0220] The TDLS Responder STA B2 responds with a TDLS Setup Response frame 224 also tunneled through the AP 112. This response frame conveys the "Link Identifier" element and the "TDLS Multi-Link" element and information about the capabilities of the TDLS Responder STA B2 (such as power save, etc.), its AID plus a status code to accept or reject the setup request.

[0221] If the setup request is accepted, the TDLS initiator STA A2 sends an acknowledgement (TDLS Setup Confirmation frame 225) still tunneled through the AP 112.

[0222] This ends the TDLS setup handshake. At this point, the two non-AP MLDs know each other's identity and their MLDMAC addresses on one hand and the AIDs allocated by the AP MLD on the other hand.

[0223] When the TDLS is established, the stations can then start communicating directly on the link 173 (direct link): P2P traffic can then be exchanged directly between STA A2 and STA B2 using the established TDLS session. The TDLS peer STAs A2 and B2 are then configured to accept data frames received directly from the other peer station. The frame exchange takes place on the same link, that is, on the same frequency channel, so that this P2P traffic becomes concurrent with other traffic of the AP 2 112.

[0224] To avoid traffic contention with the AP, TDLS peers supporting TDLS channel switching can decide to perform a TDLS channel switch to a supported channel 230. During the TDLS setup process, TDLS peers inform each other of their supported channels; that is, the TDLS peers include the supported channel element and the supported operation class element in all TDLS setup request and TDLS setup response frames with a TDLS channel switching subfield equal to 1. More advantageously, TDLS peers can move from the base channel of the considered link to an off-channel, i.e., a channel that does not overlap with the (one or more) channels used by the access point (AP) associated with the TDLS peer. Recall that the so-called channel usage element (refer to below) transmitted by the AP in the probe response or channel usage response frame... Figure 5a (Description) to provide off-channels that can be used for TDLS.

[0225] TDLS STA initiator 122 sends a TDLS channel handover request frame 231 on the TDLS direct link. This frame includes the target channel, i.e., the destination channel (off-channel) for the intended channel handover. The target channel is specified by the TDLS STA initiator from the set of operation classes supported by the two TDLS peer STAs. Upon receiving the TDLS channel handover request frame 231, the target partner STA B2 142 responds with a TDLS channel handover response frame 232 to accept or reject the channel handover. If the status code indicated in the response frame is set to REQUEST_DECLINED, both stations continue operating 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 the handover time indicated in the TDLS channel handover frame. The first transmission on the target channel does not begin before the handover time expires. Finally, after the handover time has elapsed, the initiator STA A2 can begin transmitting P2P data frames on the target channel.

[0226] When operating via the target channel (off-channel), TDLS peer STAs are in a power-saving mode with the AP and are no longer able to communicate with the AP. Therefore, they must periodically switch back to the base channel associated with the same link to receive beacon frames, view the TIM (Traffic Indication Map) for any buffered packets, and communicate with other stations in the infrastructure network (BSS) managed by the AP.

[0227] Details about the TDLS process are provided in IEEE 802.11z and have been upgraded to be established on one of the possible links provided in the D3.2 standard.

[0228] When the pair of links (151, 152) of the non-AP MLD 102 is or becomes NSTR (in Figure 1a problems arise, that is, when the non-AP MLD transmits on link 152 or 173 while the non-AP MLD operates link 152 and 173 on the same channel, the non-AP MLD cannot receive on link 151. The NSTR constraint can arise due to TDLS channel switching because the off-channel can interfere with the other link (here 151). Thus, when the non-AP MLD 102 communicates directly with the non-AP MLD 104 in point-to-point, it is blind on link 151.

[0229] Similar problems occur when links 151 and 152 belong to an EMLSR set, that is, they cannot be used for simultaneous transmissions because the corresponding MLD has a single full radio.

[0230] If the AP MLD becomes aware of such constraints between links including the link on which the P2P session occurs, the benefits of efficient communication in the infrastructure can be obtained.

[0231] As an example, the AP MLD can avoid transmitting downlink data on such constrained links to the non-AP MLD involved in a P2P session on the associated constrained link. Similarly, if either non-AP MLD negotiates a TWT agreement on such constrained links to obtain a service period to transmit P2P traffic, the peer can not be aware of the TWT SP and miss the communication. The AP MLD can intervene to facilitate the peer's registration for the TWT agreement.

[0232] There are many of these limitations during the lifetime of a TDLS session. If the AP MLD is aware of these limitations in a timely manner, their impact on the infrastructure communication should be reduced.

[0233] 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 directly or through the AP to the TDLS peer STA to tear down the TDLS direct link.

[0234] In addition, TDLS peers can organize their TDLS sessions as needed. For example, they can negotiate together a P2P active period and a P2P inactive period. They can negotiate a power save mode (PSM) and agree on a periodic wake-up schedule defining such P2P active period and P2P inactive period. To enter the TDLS peer PSM, one of the TDLS peer STAs (the TDLS peer PSM initiator) sends a TDLS peer PSM request frame 241 (including the proposed periodic wake-up schedule) to the TDLS peer STA (the TDLS peer PSM responder). To this end, a wake-up schedule element is used, which is shown in Figure 8c Fig. 20 as reference numeral 820. The wake-up schedule element includes seven fields:

[0235] - The element ID field 821 is set to a value (equal to 102) indicating that the information element is a wake-up schedule element.

[0236] - The length field 822 is set to various values depending on the length of the wake-up schedule element 820.

[0237] - The offset 823 and interval 824 fields are set to define in microseconds when the awake window starts. The interval field is non-zero and the offset field is smaller than the interval field.

[0238] - The awake window slot field 825 is set to the duration of the awake window in backoff slots (such as defined by EDCA).

[0239] - The maximum awake window duration field 826 is set to the maximum duration of the awake window in microseconds.

[0240] - The idle count field 827 is set to the number of consecutive awake windows during which no individually addressed frames are received from the TDLS peer STA before the TDLS peer STA deletes the wake-up schedule.

[0241] When the TDLS peer PSM responder accepts the proposed wake-up 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. When the status code is equal to TDLS_REJECTED_ALTERNATIVE_PROVIDED, an alternative schedule can be included in the TDLS peer PSM response frame. The TDLS peer PSM initiator can use the alternative schedule to generate a new TDLS peer PSM request frame 241.

[0242] After a successful transmission or reception of a TDLS Peer PSM Response frame indicating status code SUCCESS, the TDLS Peer PSM Initiator and the TDLS Peer PSM Responder have established a periodic wake-up schedule between them.

[0243] In this case, the NSTR or EMLSR constraints described above only exist while the TDLS Peer stations are awake. Thus, the knowledge of the P2P active period and the P2P inactive period (and thus of the PSM awake window) by the AP MLD can be very helpful for the AP MLD to properly schedule infrastructure communications that reduce interference with P2P communications.

[0244] Figure 1b Example Figure 1a A variant of the above, in which only one non-AP MLD 102 is associated with the AP MLD 110. The P2P communication in this example is established after a WiFi Direct procedure, since the second MLD device 104 is not associated with the AP MLD 110. In the example of the figure, the MLD 104 acts as a soft-AP or NSTR mobile-AP, or P2P group owner, such as defined in the standard D3.2.

[0245] The process of forming a P2P group (or not) is now described. Wi-Fi Direct connection is mainly done through three processes including device discovery, service discovery and group establishment. Figure 1b1 These processes are illustrated in the figure, which uses a frame exchange in a timeline to illustrate possible scenarios of forming a P2P group by two peer stations belonging or not to a non-AP MLD.

[0246] The first process is the device discovery process 250, which is needed when Wi-Fi P2P devices or stations, e.g. the first and second P2P stations (122, 141), identify each other to configure a connection to establish a Wi-Fi P2P group. At this stage, the stations alternate between a listening state and a search state. The first P2P station searches for a nearby Wi-Fi P2P station by repeatedly performing a channel scan of IEEE 802.11 channels by listening to so-called "social channels" (defined as channels 1, 6 and 11 in the 2.4 GHz band) and searching these channels for a predetermined period of time. The basic operation of the device discovery procedure, which is done during the Wi-Fi P2P group establishment, is achieved by exchanging Probe Request and Probe Response frames of the IEEE 802.11 MAC protocol. These exchanges enable the P2P stations to discover each other on the nearby environment.

[0247] A second process is service discovery 260, which takes place after the device discovery process, to provide a function of exchanging information about services that can be supported by each P2P station. That is, each P2P station can identify supportable service protocols and services, etc. by exchanging request frames and response frames. Thus, P2P stations exchange inquiries to discover each other's available service set, and based on this information, decide whether to proceed with group formation.

[0248] A third process is group generation or establishment. Group owner (GO) negotiation process is conducted by a three-way exchange including GO negotiation request frame 261, GO negotiation response frame 262, and GO negotiation confirmation frame 263. These frames allow two stations to agree which station will act as a P2P GO, while the other station will act as a P2P client of the GO, and agree on which channel the group will operate (the channel can be, for example, in the 2.4 GHz or 5 GHz band) and share their P2P attributes. These information (P2P attributes) can be carried in a P2P information element. For example, P2P capability attribute contains a set of parameters that can be used to establish a P2P connection.

[0249] In the example of the figure, since the non-AP MLD supports connections to both the infrastructure network and the Wi-Fi Direct group at the same time, it can 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, for example, if the WLAN AP is able to manage P2P devices, the WLAN STA interface of the P2P concurrent device can include the P2P interface attribute in the P2P IE in the (re)association request frame transmitted to the WLAN AP (AP MLD 110 or one of its affiliated APs 111 and 112). In other words, the P2P concurrent device must declare its constraint to the AP.

[0250] Security provisioning (not shown) starts after discovery has taken place, and if needed, the respective roles have been negotiated at the time of forming the group.

[0251] Once a P2P group is established, new P2P stations can discover and join the P2P group using active or passive scanning mechanisms as used in regular Wi-Fi networks. As a regular AP, the P2P GO advertises itself through beacons, and must support power save services for its associated clients. The P2P GO also needs to run a Dynamic Host Configuration Protocol (DHCP) server to provide IP addresses to P2P clients (not represented in the figure).

[0252] Once a successful Wi-Fi direct connection is established between the stations, they can then begin communicating directly on link 173 (direct link). Frame switching occurs on the same frequency channel, making this P2P traffic concurrent with other traffic on AP2 112.

[0253] As described above, in Figure 1b In the scenario variation, STA A2 joins the (already established) P2P group owned by group owner 141.

[0254] Similar to Figure 1a The link pair (151, 152) of non-AP MLD 102 can be or become an NSTR (NSTR relationship is shown with dotted lines in the diagram) or an EMLSR link. This poses the same problems as described above, given the risk of interference between P2P communication and infrastructure communication. Furthermore, STA A2 can negotiate the TWT protocol for P2P traffic. Power saving mode (PSM) can be organized between the two peers, as well as channel handover to off-channel locations that the AP MLD may not be aware of.

[0255] For TDLS sessions, P2P stations belonging to a P2P group can negotiate a power-saving mode to remain awake only during certain time periods. WiFi Direct specifies that the group owner can inform it of one or more periods of absence (when in power-saving mode) by including an absence notification attribute or element in its beacon frame 270 or probe response frame (not shown in the figure), or by using an absence notification action frame (not shown in the figure). The main information of this element is... Figure 8a The element is shown by reference numeral 800 in the attached figure. Element 800 includes four fields:

[0256] - The count field 801 indicates the number of absence intervals. This field can be set to a value from 1 to 255. 255 means continuous scheduling; 0 is reserved and not used.

[0257] - The duration field 802 indicates the maximum duration, in microseconds, that a P2P group owner can remain absent after the absence notification interval begins.

[0258] - The interval field 803 is used to indicate the length of the absence notification interval, which is in microseconds.

[0259] - The start time field 804 is used to indicate the start time of the schedule as expressed by the lower 4 bytes of the TSF timer.

[0260] The P2P group owner can also send absence notification (NoA) elements based on the presence request / response mechanism initiated by the P2P client (not shown in the diagram). In this case, the NSTR or EMLSR constraint exists only when the P2P site is active.

[0261] To disassociate from the group, a P2P client (STA A2 in the example) can send a disassociation frame 264 to its group owner (STA B1 in the example). Similarly, the group owner can disconnect the P2P client or end the group session. Figure 1b

[0262] In view of the above constraints and the existence of TWT or NoA to organize P2P communications, the AP MLD can be interested in knowing such information about P2P sessions to properly schedule infrastructure communications that reduce interference with P2P communications.

[0263] Figure 1c Illustration Figure 1a and Figure 1b Another variant of the example in which the two non-AP MLDs are associated with different AP MLDs, respectively, non-AP MLD 102 is associated with AP MLD 110 and non-AP MLD 104 is associated with AP MLD 190. The two AP MLDs can be independent or bound by an ESS or a non-collocated AP MLD. In the latter case (ESS or non-collocated AP MLD), the two AP MLDs can be controlled by entity 180 (or controller) which can be in charge of managing security (authentication), frequency sharing, BSS transition and can act as a relay between AP MLD 110 and 190.

[0264] In the figure, AP MLD 110 has attached APs (AP1 111 and AP2 112) while AP MLD 190 has attached APs (AP2 191 and AP2 192).

[0265] ​In addition to their respective association with the AP MLDs 110 and 190, the non-AP MLD 102 has established a point-to-point link (e.g., a TDLS session) through its affiliated STA A2 and the non-AP MLD 104 through its affiliated STA B1. This point-to-point link is operating on the same link / channel as AP 191, but is considered off-channel with respect to the AP MLD 110. As such, when the STA A2 122 communicates with the STA B1 141 through the point-to-point link 173, from the perspective of the AP 112, the STA A2 122 is in power save mode, and on the other hand, when the STA A2 122 communicates with its associated AP 112 on the operating channel of the AP 112, from the perspective of the STA B1 141, the P2P STA A2 122 is offline. The diagonal stripes of the STA A2 122 box represent the dual operation on the operating channel of the AP 112 when the station communicates with it or on the operating channel of the AP 191 when the station communicates with the STA B1 141 in point-to-point fashion.

[0266] Similarly to Figure 1a or Figure 1b In particular when the STA A2 operates on the off-channel (from the perspective of the AP MLD 110) used for P2P communication (i.e., on the operating channel of the AP 191), the link pair (151, 152) of the non-AP MLD 102 can be or become an NSTR. The AP MLD 110 can not be aware of the use of this off-channel.

[0267] In addition, the link pair (161, 162) of the non-AP MLD 104 can be or become an NSTR (the NSTR relationship is illustrated with dashed lines in the box 104 in the figure) or an EMLSR link. In case of risk of interference between P2P communication and infrastructure communication, the same problems as described above arise. In addition, the stations can negotiate a TWT agreement for P2P traffic. Power save mode (PSM) can be organized between the two peer stations.

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

[0269] Figure 1d Another variant of the previous figure is illustrated, in which the two non-AP MLDs are associated with different AP MLDs, respectively, the non-AP MLD 102 is associated with the AP MLD 110 and the non-AP MLD 104 is associated with the AP MLD 190. The two AP MLDs are not visible to each other and the non-AP MLDs are close enough to be concurrent when they operate on the same frequency.

[0270] In the figure, the AP MLD 110 has affiliated APs (AP1 111 and AP2 112), while the AP MLD 190 has affiliated APs (AP1 191 and AP2 192).

[0271] In the figure, similarly to Figure 1a , the non-AP MLDs 102, 104 have multiple affiliated non-AP STAs, each behaving as an 802.11 non-AP STA in the BSS it is registered to (managed by the affiliated AP 111 or 112 and AP 191 or 192, respectively).

[0272] For example, the AP 111 is set to operate on channel 38 corresponding to a 40MHz channel of operation in the 5GHz band, and the AP 112 is also set to operate on channel 151 corresponding to another 40MHz channel of operation in the 5GHz band. For the second AP MLD 190, the AP 191 is also set to operate on channel 38 (concurrently with the AP 111), and the AP 192 is set to operate on channel 102 corresponding to a third 40MHz channel of operation in the 5GHz band. In another example, the affiliated APs operate on different frequency bands.

[0273] The two AP MLD BSSs do not overlap, but since the two non-AP MLDs are closely located, they can interfere with each other on the shared frequency (e.g., channel 38). Therefore, the stations STA Al 121 and STA Bl 141 (affiliated to the non-AP MLD A 102 and the non-AP MLD B 104, respectively) compete with each other to access the medium. Moreover, since they are close, when one of the stations is transmitting, it interferes with the other station. Indeed, the transmission power reaching the AP is such that it drowns the signal reception of the other station. That is, the two stations affiliated to different non-AP MLDs can be considered as belonging to an NSTR station pair (relationship shown by the dashed line).

[0274] In addition, a P2P link 173 can be established between STA Al 121 and STA Bl 141 using the previously described mechanisms. Therefore, the above-mentioned limitations can be cumulated to the ones described in the previous figures regarding the P2P communications that can occur through the P2P link 173.

[0275] Again, the AP MLD can be interested in knowing such information about P2P sessions or OBSS or interference or disturbance to properly schedule the infrastructure communications that reduce the interference with the P2P communications or the infrastructure communications themselves.

[0276] The present disclosure proposes embodiments to inform an AP MLD of P2P operation of one of its associated non-AP MLDS or of OBSS affecting one of its links. Such a mechanism to inform provides benefits for the entire network communication when a non-AP MLD experiences constraints between a “P2P” or “OBSS” link and another enabled link with an AP MLD. Thus, a non-AP MLD can declare to an AP MLD transmission constraints between the enabled link with the AP MLD. The constrained links include, for example, EMSLR links or NSTR link pairs.

[0277] For ease of illustration, reference is now made to P2P communication or session on one of the constrained links, rather than the presence of OBSS. However, the mechanisms described below also apply to both constrained links when one of them experiences interference with an OBSS.

[0278] 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 can send a P2P link report (and more generally, a coexistence link report) to the AP MLD about the P2P session occurring on one of the constrained links.

[0279] In response, the AP MLD can take appropriate measures to adjust infrastructure communication for the P2P information provided in the P2P link report. This can include, for example, registering another peer station into an existing TWT dedicated to P2P traffic, or refraining from transmitting downlink frames to the peer station during P2P activity, or lifting any such restrictions when P2P activity stops (e.g., due to termination of PSM or P2P session).

[0280] Exemplary reports include using an event report element or a channel usage element.

[0281] The event report procedure according to the 802.11 standard is shown in Figure 2 Section 4.3.19.8 in IEEE Std 802.11™ (2020).

[0282] The event report procedure is used to diagnose the status of a network in real time. The event report procedure in a WLAN defines various events such as transition events, robust security network association (RSNA) events, point-to-point link events, and system log events as event request / report elements. The event request / report elements other than system log events define various types of sub-elements.

[0283] The STA log recording the reported events is not cleared due to BSS transition. However, if the STA moves to a different ESS or IBSS, the STA deletes all event log entries.

[0284] The STA supporting event reporting transmits an event request or event report frame to a STA within the same infrastructure BSS or the same IBSS.

[0285] More specifically, for point-to-point link event reporting (or P2P link event reporting), a point-to-point event occurs when a point-to-point link is initiated or terminated. This can be the case of establishing or tearing down a TDLS session or joining or creating a P2P group. In addition, a P2P event can occur when the P2P link changes significantly (e.g., modification of the channel used).

[0286] As shown, the station transmitting the event request frame is referred to as the requesting STA, and the station transmitting the event report frame is referred to as the reporting STA or the requested STA. In an ESS embodiment (infrastructure BSS), the requesting STA is typically an access point (AP), and the reporting STA is a non-AP STA. Alternatively, in a wireless network management procedure in an IBSS (an independent BSS is a kind of ad hoc mode or peer-to-peer network), both the requesting STA and the reporting STA can be non-AP STAs.

[0287] 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 about one or more event report elements in an event report frame 291.

[0288] As shown, the event request frame 290 can include one or more event request elements. Figure 3a

[0289] Figure 3a An example of the format of the event request frame according to the 802.11 standard is illustrated.

[0290] The event request frame 310 includes a category field 300, an action field 301, a dialog token field 302, an event request element field 303 containing one or more event request elements 320, and a destination URI element 304.

[0291] The category field 300 is set to a value indicating that the corresponding frame belongs to the wireless network management category (value 10 according to Table 9-79 in IEEE P802.11-REVme / D3.0, April 2023).

[0292] ​Since several action frame formats are defined for wireless network management (WNM) purposes, the WNM action field 301 in the field immediately following the category field distinguishes these formats. The WNM action field 301 is set to a value indicating that the frame is an event request frame (according to Table 9-510 in IEEE P802.11-REVme / D3.0 of April 2023, the WNM action field value is equal to 0).

[0293] The conversation token field 302 is used to identify frame exchanges between stations and is set to a value selected by the requesting STA to match the event request frame 290 with the event report frame 291.

[0294] The event request element field 303 contains one or more event request elements 320.

[0295] The destination URI element 304 is less important to the present invention. The AP includes a URI in the destination URI element that a reporting non-AP STA can use to send an event report when losing or interrupting a connection with the BSS.

[0296] The event request element 320 contains a request for the receiving STA to perform a specified event action, where:

[0297] The element ID field 321 is set to a value indicating that the information element is an event request element (equal to 78).

[0298] The length field 322 is set to various values depending on the length of the event request element 320.

[0299] The event token field 323 is a non-zero number that is unique in the event request element sent to each destination MAC address that has not received a corresponding event report element.

[0300] The event type field 330 is set to a value indicating the type of event requested when a STA transmits an event request frame to another STA. The event type field 330 is a number identifying the type of event request. The event type can include, for example, transition events, RSNA events, point-to-point link events, BSS color conflict detection, and system log events. The values of the event type field are defined according to Figure 3b Table 9-231 in IEEE P802.11-REVme / D3.0 of April 2023. Point-to-point link events correspond to a value of 2.

[0301] - The event response limit field 324 is set to indicate the maximum number of logged events to be reported 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 the event response limit number of most recent events. If there are no available logged events of the type specified in the event request frame, the reporting STA sends an event report frame with no event report elements. When the event request field is not present in the event request element, the reporting STA sends all available event report elements of the requested event type. The event response limit field is set to 0 to indicate that there is no limit set on the number of event reports to be included in the event report elements.

[0302] - The event request field 325 contains the event request corresponding to the event type (as described in 9.4.2.66.2 (Transition Event Request) through 9.4.2.66.8 (Using BSS Color in Event Report) of IEEE P802.11-REVme / D3.0, April 2023). The point-to-point link event request is described in 9.4.2.66.4.

[0303] The requested STA or reporting STA processes (299) the received event request frame, generates an event report frame 291, and sends the event report frame 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.

[0304] Figure 3c The format of the event report frame 291 is illustrated in accordance with the 802.11 standard.

[0305] The category field 350, the WNM action field 351, and the dialog token field 352 are similar to the category field 300, the WNM action field 301, and the dialog token field 302 described above. If the event report frame 291 is a spontaneous transmission, i.e., for reasons other than in response to the event request frame 290, the dialog token field 352 is set to 0.

[0306] The event report element field 353 contains one or more than one of the event report elements 360.

[0307] A given event report element 360 is used by the reporting STA to report an event:

[0308] - The element ID field 361 is set to a value (equal to 79) indicating that the information element is an event report element.

[0309] - The length field 362 is set to various values depending on the length of the event report element 360.

[0310] - 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), the event token 363 is set to 0.

[0311] - Event Type field 364 is a number that identifies the type of event report element 320. The value of the event type field 364 is the same as the value used for the event type field 330, so they correspond to Figure 3b the values of

[0312] - Event Report Status field 365 is set to a value that indicates the response of the STA to the event request. The figure shows various values that can be used to indicate success of the request, failure of the request, and rejection of the request, among others.

[0313] - Event TSF 366, UTC Offset 367, Event Time Error 368, and Event Report fields are not always present (depending on whether the status was successful and the event type). The event TSF field 366 is the TSF value at which the STA logged the event. The UTC Offset field 367 is the UTC value corresponding to the UTC time when the TSF timer was equal to 0. The Event Time Error field 368 is the standard deviation of the UTC, which corresponds to the logged TSF value for the event. If 367 and 368 are not known, the fields are 0.

[0314] - Event Report field 369 contains the specification of a single event report.

[0315] 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, the reporting STA returns a value of "success" in the event report element (in the event report status field 365). If the reporting STA does not have logged events of the requested type, the reporting STA returns a value of success in the event report status field 365 without including events in the event report field 369. If the reporting STA is unable to handle the request at this time, the reporting STA returns a value of "request failed" in the event report status field 365 of the event report element 360.

[0316] Attention is now drawn to the point-to-point link event request element (i.e., when the event type field 330 is set to a value of 2) and the point-to-point link event report element (i.e., when the event type field 340 is set to a value of 2).

[0317] Figure 4aThe format of the point-to-point link event request field included in the point-to-point link event request element 320 is illustrated. This field corresponds to the event request field 325 of the event request action frame 290 with the event type field 330 set to the value 2.

[0318] A requesting STA can include zero or more than zero point-to-point link event request subelements 400 in the point-to-point link event request field 325.

[0319] Subelements 400 are defined to have a common generic format consisting of a subelement ID field specific to 1 octet element, a length field of 1 octet, and a variable length subelement specific data field. Individual subelements are 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.

[0320] According to Table 9-234 in IEEE P802.11-REVme / D3.0 from April 2023, subelements are defined for point-to-point link event types by different subelement IDs, which include:

[0321] - A peer address ID subelement 400-a when the subelement ID is set to the value 0. This subelement identifies the peer STA, BSS, or IBSS of the point-to-point link to be reported. Exclusion of this subelement from the event request field 325 indicates a request for point-to-point link events for any peer STA, any BSS, and any IBSS. The peer STA / BSSID address field contains the MAC address of the peer STA or the BSSID for point-to-point links in IBSS. If the indicated address matches the address 1 field of the MAC header content, then the address is the peer STA address of a TDLS peer STA or IBSS STA. If the indicated address matches the address 3 field of the MAC header content, then the address is the BSSID for a TDLS direct link or for an IBSS.

[0322] - A channel number(s) subelement when the subelement ID is set to the value 1. This subelement identifies the channel of the point-to-point link to be reported. Exclusion of this subelement from the event request element 325 indicates a request for point-to-point link events for any channel. The format of the channel number subelement is illustrated in 400-b. The operating class field indicates the channel set of the link to be used for the point-to-point link event report. (The operating class is defined in Appendix E of 802.11REVme D3.0). The channel number field indicates the channel number of the requested point-to-point link event. Channel number 0 in all channel number subelements indicates a request for any point-to-point link event reporting any supported channel in the specified filter operating class.

[0323] Figure 4bThe format of the point-to-point link event report element included in the example point-to-point link event report element 360. This field corresponds to the event report field 369 of the event report action frame 291 with the event type field 364 set to a value of 2. A point-to-point link is defined as a direct link within a QoS BSS, TDLS, or STA-to-STA communication in an IBSS.

[0324] The point-to-point event report subelement 450 is used by the reporting STA to report the event. This subelement is defined in Figure 9-468 of IEEE P802.11-REVme / D3.0, April 2023.

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

[0326] The Operating Class field 452 indicates the channel set of the point-to-point link. The valid values of the operating class are shown in Appendix E of 802.11 REVme D3.0.

[0327] The Channel Number field 453 indicates the point-to-point channel number of the point-to-point link. The channel number is defined within the operating class as shown in Appendix E of 802.11 REVme D3.0.

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

[0329] The Connection Time field 455 contains the connection time in seconds. If the Peer State field is 0, this field indicates the duration of the direct link. If the Peer State field is 1, this field indicates the time difference from the time the direct link was established to the time the event report was generated by the reporting STA. If the Peer State field is 2, this field indicates the duration of the IBSS membership. If the Peer State is 3, this field indicates the time difference from the time the STA joined the IBSS to the time the event report was generated by the reporting STA.

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

[0331] As noted above, an alternative to the event report element to report to the AP MLD can include the use of a channel usage element.

[0332] The AP uses the channel usage procedure to recommend channels to non-AP STAs for BSSs that are not infrastructure BSSs or off-channel TDLS direct links. The non-AP STAs can use the channel usage information as part of the channel selection process for BSSs that are not infrastructure BSSs or off-channel TDLS direct links. Thus, the channel usage information provided by the AP to the non-AP STAs is a suggestion of how the STAs can coexist with the infrastructure network. In addition, the non-AP STAs can negotiate a point-to-point TWT agreement by including a TWT element in the channel usage request frame (see Figure 5b description below) and the AP can in turn accept the establishment of the TWT agreement by including a TWT element in the channel usage response frame (see Figure 5c description below). Furthermore, a non-AP STA that has selected a channel for point-to-point communications can transmit a channel usage request frame to inform the AP of its unavailability during the point-to-point TWT agreement, where the usage mode field of the channel usage element of the channel usage request frame is set to 3 (point-to-point link indication) and does not have a channel entry field.

[0333] Reference is made to Figure 5a The data payload of the channel usage element is shown under reference sign 500. The channel usage element consists of four fields: the element ID field 510, the length field 520, the usage mode field 530, and the channel entry field 540.

[0334] Four different values are defined in IEEE P802.11-REVme / D3.0 version (April 2023) for the usage mode field 530, namely, a value 0 for non-infrastructure IEEE 802.11 networks, a value 1 for off-channel TDLS direct links, a value 2 for non-infrastructure IEEE 802.11 networks where none of the APs belonging to the same ESS operate on the channel identified by the channel entry field, and finally a value 3 for point-to-point link indication. Values 4 to 255 are reserved.

[0335] The channel entry field 540 includes zero or more than zero operation class 541 and channel 542 fields. The operation class field 541 indicates an operation class value. The operation class is interpreted in the context of the zone specified in the beacon frame. The channel field 542 indicates a channel number, which is interpreted in the context of the indicated operation class. The operation class and channel number are defined in Annex E in IEEE P802.11-REVme / D3.0 version. The operation class and channel fields can be grouped together to identify a non-contiguous channel as described in 9.4.2.6 9.3 (Position Indication Channel subelement).

[0336] The non-AP STA sends a channel usage request frame to the AP to request the specified channel usage information. Reference is made to Figure 5b A channel usage request frame 580 is described. The frame includes a category field 581, a WNM field 582, a conversation token field 583, a channel usage element field 584, a supported operation class element field 585, and optionally a TWT element field 586 and a super interval element 587, as follows:

[0337] - The category field 581 is similar to the category field 300 described above (value 10).

[0338] - The WNM field 582 defines the type of frame, i.e. channel usage request frame (WNM action field value equal to 21 according to Table 9-510 in IEEE P802.11-REVme / D3.0 of April 2023).

[0339] - The conversation token field 583 is a non-zero value selected by the non-AP STA sending the channel usage request frame to identify the request / response transaction.

[0340] - The channel usage element field 584 includes one or more than one channel usage element to identify the requested usage pattern.

[0341] - The supported operation class element field 585 contains the supported operation class element to indicate the supported operation classes for the requested network type consistent with the zone element advertised by the AP.

[0342] - The TWT element field 586 includes zero or more than zero TWT elements, each containing only one individual TWT parameter set. When included in the channel usage request frame, the TWT element field contains only one TWT element, unless used to establish a point-to-point TWT agreement with a range of TWT parameter values. In this case, there are additional TWT elements.

[0343] - A timeout element field 587 exists when the TWT element field contains at least one TWT element; if it exists, a TIE is also included. Otherwise, a timeout element field does not exist in this frame.

[0344] The AP responds to a channel usage request frame or spontaneously sends a channel usage response frame. (Reference) Figure 5c The channel usage response frame 590 describes the following: Category field 591, WNM field 592, Channel Usage Element field 593, Region 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 Element field 598, and Optional Timeout Interval Element 599. The following further describes only the fields that differ from the channel usage request frame 580:

[0345] - The region string field 594 is the value contained in the dot11CountryString property.

[0346] - The power constraint element field 595 includes zero or one power constraint element.

[0347] - EDCA parameter set element field 596 includes zero or one EDCA parameter set element.

[0348] - The Transmission Power Envelope Element field 597 is defined in 9.4.2.160 (Transmission Power Envelope Element in 802.11REVme D3.0).

[0349] This invention provides enhanced reporting for AP MLD, specifically regarding the multi-link nature of MLD.

[0350] Figure 6a and Figure 6b The flowchart illustrates exemplary steps for reporting P2P activity at an AP MLD (or AP) and an associated non-AP MLD (or station) according to some embodiments of the present invention.

[0351] The left side of the diagram represents the steps involved in P2P activities at non-AP stations affiliated with non-AP MLDs, while the right side represents the steps at affiliated AP stations corresponding to non-AP stations.

[0352] A secondary non-AP station can be a station involved in a P2P session that reports information about the P2P session (e.g., establishment, termination, timing information, TWT). In variations, a secondary non-AP station can be a different station, i.e., another secondary non-AP station besides the one experiencing the P2P session. For example (see below). Figure 7cThe indicated), the affiliated non-AP station can be an affiliated non-AP station that performs channel switching that creates an NSTR constraint with the P2P link (the link over which the P2P session occurs).

[0353] At step 600, the AP can transmit a P2P link report enrollment indication that enables P2P link reporting. This indication can be transmitted in a P2P link report enrollment frame.

[0354] In some embodiments, the frame is a point-to-point link event request action frame 290, meaning that it includes a point-to-point link event request element 320. In this case, the indication can be that the event type field 330 is set to a value of 2, optionally with at least one point-to-point link event request sub-element 400.

[0355] In other embodiments, the frame is a channel usage request frame 580, meaning that it includes a channel usage element 500 with a point-to-point indication. In this case, the indication can be that the usage mode field 530 is set to a value of 3 (i.e., point-to-point link indication).

[0356] In other embodiments, the frame is a probe response frame, meaning that the P2P link report enrollment indication is transmitted during the association procedure of the affiliated non-AP station. The indication can be provided in the channel usage element included in the frame with the usage mode field 530 set to a value of 3.

[0357] In other embodiments, the P2P link report enrollment indication can also be inferred from one or more specific capabilities declared by the AP in a beacon frame or probe response frame. The indication can include P2P related capabilities declared by the AP MLD in the frame. Exemplary capabilities include a TDLS prohibited capability field when set to 0 (meaning that TDLS is allowed) or a point-to-point TWT support capability when enabled.

[0358] More generally, any P2P bit in a beacon or probe response frame can be used to indicate P2P link report enrollment that enables P2P link reporting.

[0359] At step 610, the affiliated non-AP station receives the P2P link report enrollment indication transmitted by the AP at step 600. The non-AP MLD now knows that the AP MLD requires P2P link reporting to optimize its scheduling within the infrastructure network.

[0360] As mentioned above, scheduling seeks such adaptation when there are constrained links. In this regard, at step 620, the non-AP MLD (any of whose affiliated non-AP stations) declares to the AP MLD transmission constraints between the links of the non-AP MLD. This can include EMLSR constraints. Step 620 can thus be triggered upon activation of the EMLSR mode. In a variant, a report on NSTR links can be provided (e.g. including a NSTR bitmap). Step 620 can thus be triggered upon channel switch, as the target channel creates interference with another channel, so they are NSTR links.

[0361] The AP MLD thus receives at step 630 the link constraint declaration. As will be apparent from below, this drives which link or links the AP MLD has to adapt its scheduling within the infrastructure network on.

[0362] The link constraint declaration can be made prior to the P2P link report registration indication (steps 620 and 630 thus precede steps 610 and 600, respectively). Moreover, steps 600 and 610 can be omitted when the affiliated non-AP stations systematically report link constraints (regardless of the AP’s capabilities).

[0363] In other variants explained below, in particular regarding the proposed format of the P2P link report (see NSTR indication bitmap 459 as an example), the link constraint declaration can be included in the P2P link report sent by the non-AP MLD.

[0364] Next, at step 640, the non-AP MLD engages in a P2P session on one link (denoted as “P2P link”) of (any of its affiliated stations) and a triggering event occurs at the affiliated non-AP station to send such P2P link report to its associated AP.

[0365] Various triggering events can be envisaged.

[0366] In some embodiments, the triggering event comprises receiving a P2P link report request frame from the AP, such as a point-to-point link event request action frame or a channel usage request frame 580 with the point-to-point indication already sent at step 600. In this case, step 640 directly follows step 610: the P2P link report is sent as an immediate response to the request frame.

[0367] In other embodiments, the triggering event comprises creating a P2P session, such as establishing or joining a TDLS session or a P2P group, etc. In this case, the P2P link report is sent by the affiliated non-AP station involved in the P2P session.

[0368] In other embodiments, the trigger event includes terminating a P2P session, such as tearing down a TDLS session or sending a disassociation frame to disassociate from a P2P group, etc. In this case, the P2P link report is sent by the dependent non-AP station involved in the P2P session.

[0369] In other embodiments, the trigger event includes obtaining timing information about the P2P session, which defines a period of P2P communication in the P2P session or a power saving period of the dependent non-AP station. This can include obtaining a new awake window slot or an absence notification of the P2P session or group.

[0370] In other embodiments, the trigger event includes modifying (i.e., enabling or disabling) transmission constraints between links comprising the P2P link (e.g., enabling or disabling enhanced multi-link single radio (EMLSR) operation for the link), or making a channel switch that modifies the STR or NSTR relationship between two links. For example, the dependent non-AP station can switch the channel of the link where the P2P session occurs to an off-channel that becomes NSTR with another enabled link to the AP MLD. In a variation, the AP MLD can switch the operating channel of one of its enabled links with the non-AP MLD that becomes NSTR with the P2P link where the P2P session occurs.

[0371] In other embodiments, the trigger event includes detecting interference from an OBSS of a disturbing link of the non-AP MLD.

[0372] As a result of detecting the trigger event at step 640, the dependent non-AP station prepares and sends a P2P link report about the P2P session occurring on one constrained P2P link to its associated AP at step 650.

[0373] Various information can be included in the P2P link report, including all or some (at least one) of the following:

[0374] - a Link ID field that includes an identifier of the P2P link where the P2P session occurs,

[0375] - a Peer STA Address field that includes an identifier of the other peer station involved in the P2P session,

[0376] - an NSTR field (such as an NSTR indication bitmap, etc.) that reports non-simultaneous transmission and reception (NSTR) link pairs of the non-AP MLD, and

[0377] - a Timing Information field that specifies a period of P2P communication in the P2P session or a power saving period (e.g., an awake window slot or an absence notification) of the dependent non-AP station,

[0378] - a P2P session identifier field including an identifier of the P2P session, and

[0379] - a P2P session status field including a current status of the P2P session (e.g. active or terminated).

[0380] The P2P link report can be included in a point-to-point link event report frame 291, in which case the point-to-point link event report element 450 carries the above information, or in a channel usage request frame 580, in which case the channel usage element 500 with the point-to-point indication carries the above information. Of course, any other frame can be used that conveys the appropriate element to provide coexistence information (regarding the P2P session or the OBSS).

[0381] Then, at step 660, the AP receives the P2P link report including the P2P link characteristics. This information can be used by its AP MLD to properly schedule communications in its infrastructure network. To this end, at step 670, the AP determines the appropriate P2P rules depending on the situation.

[0382] The first P2P rule can seek to reduce or avoid downlink communications to the non-AP MLD on the constrained link while the P2P session is running, or at least while it is not known that the corresponding affiliated non-AP station is not in power save mode but is active. This means for example that the AP MLD avoids scheduling simultaneous communications on the EMLSR link set or the NSTR link pair (when one of these links is dedicated to P2P communications).

[0383] The second P2P rule can seek to register the other peer station in the TWT agreement negotiated with the non-AP station for one of the constrained links. Indeed, the affiliated non-AP station engaged in P2P communications can have negotiated a TWT for P2P communications to its associated AP. By knowing the identity of the other peer station (as reported in the P2P link report), the AP is able to register the other peer station to ensure that it is awake when the service period of the TWT for P2P communications is about to start.

[0384] The third P2P rule can seek to schedule the TWT to align with the periods of P2P inactivity or absence of the peer stations of the P2P session as notified in the P2P link report (e.g. inferred from the reported awake window slots or absence notification). Indeed, the affiliated non-AP station (or even the other peer station) can have negotiated a regular TWT (not P2P) with its associated AP. Knowing these and the periods of P2P inactivity, the AP can try to schedule the TWT during the periods of P2P inactivity to increase the chances that the non-AP station is available to efficiently use the communication resources allocated to the AP in the infrastructure network.

[0385] Once one or more P2P rules have been selected, these P2P rules are applied at step 680 to adapt or adjust the scheduling of the AP MLD's infrastructure communications.

[0386] Note that in case the P2P link report reports the termination of a P2P session, the adaptation of the scheduling can be undone.

[0387] Figure 7a Example of frame exchange using a timeline Figure 1a Scenario in which two non-AP MLDs are associated with an AP MLD and the non-AP MLDs are going to establish a point-to-point link to communicate directly with each other. As in Figure 1a1 The same reference signs correspond to the same stages / steps / frames / entities.

[0388] In order to mitigate the coexistence between P2P communications and its own infrastructure communications (within a BSS or ESS), the affiliated AP can send a P2P link report registration frame 710 to ask its associated non-AP stations to report their P2P sessions. Any frame or indication as described above with reference to step 600 can be used.

[0389] As shown 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).

[0390] The AP 112 therefore relays the TDLS discovery request frame 221, the TDLS setup request frame 223, the TDLS setup response frame 224 and the TDLS setup confirmation frame 225 between STA A2 and STA B2.

[0391] At the end of the TDLS setup process, e.g. upon transmitting or receiving the TDLS setup confirmation frame 225, the non-AP MLDs involved in the TDLS setup can inform their associated AP about the establishment of the point-to-point link through a P2P link report 715. Alternatively, this message can be transmitted by only one of the peer stations, e.g. the TDLS initiator STA.

[0392] As mentioned above, the P2P link report 715 can be a point-to-point link event report frame 291 including a point-to-point link event report element 450.

[0393] The point-to-point link event report element can be as described above with reference to Figure 4b In a variant, the element is augmented with additional information, as shown in Figure 4d ​

[0394] In both cases, the element comprises the operating channel in which the P2P session takes place (field 453), the peer status (field 456) to indicate whether the connection is active (the peer status is set to the value 1 for direct link or to the value 3 for IBSS membership) or terminated (the peer status is set to the value 0 for direct link or to the value 2 for IBSS membership), etc.

[0395] The extended format comprises four optional fields, which means that all or part of them can be included:

[0396] - The link ID field 457 indicates the link on which the P2P communication takes place. This information is complementary to the fields 452 and 453 indicating the operating channel. This information can allow the transmission of the P2P link report 715 on another link than the P2P link on which the P2P session takes place. In the case of off-channel P2P session, the link ID indicates which of the non-AP MLD's affiliated stations is used for off-channel P2P communication, in which case the link ID is considered as a station identifier. If the report is transmitted on the link on which the P2P session takes place, and if there is no NSTR field 459, this field 457 can be absent.

[0397] - The other peer STA address field 458 carries the identifier of the other peer station involved in the P2P communication. In the case of TDLS, this identifier can be the AID or the MAC address of the other TDLS peer station. In the case of WiFi Direct, this identifier can be the group owner's MAC address. This information allows the AP to be informed of the other station involved in the P2P communication. Thus, as already described above, if a broadcast or point-to-point TWT such as defined by the field 451 (or reporting STA) is established between the AP and the non-AP STA, the AP can inform or register the other peer STA in the TWT agreement. This information is also a way to link the two P2P stations and adopt similar behaviors, especially in the case where the report is sent by only one of the two or more stations. If the other peer station is not associated with this AP or is associated with another AP of the ESS, this field 458 can be absent. If the field 458 carries the MAC address of the group owner serving the reporting STA, the AP can use this information to perform inter-BSS coexistence procedures.

[0398] - The NSTR indication bitmap 459 indicates the NSTR link pairs. If the link pair corresponding to the link ID equal to <i, j> is an NSTR link pair, then the bits Bj (j ≠ i) in the NSTR indication bitmap subfield included in the current element of the link ID subfield 457 equal to i are set to 1; otherwise, the bits Bj are set to 0. The bit Bi in the NSTR indication bitmap subfield included in the current element of the link ID subfield value equal to i is reserved. Thus, the bitmap defines all the NSTR pairs involving the link 'i' defined in the subfield 457. The NSTR information is particularly useful when P2P transmissions occur on off-channel. Indeed, the AP is not aware of the NSTR restrictions of the non-AP MLD on other channels than the channel on which the AP MLD is operating as an AP. The bitmap can not exist if the station has no NSTR restrictions.

[0399] - The wake-up schedule element 460, already described, indicates the periods during which the station is awake from the point of view of the P2P communication. 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. The concurrent communication includes: a communication with the reporting station, or (in case the non-AP MLD is subject to NSTR or EMLSR restrictions) a communication with other station(s) of the same non-AP MLD to which the reporting station is affiliated (e.g. stations indicated by the NSTR indication bitmap), or a communication with a peer station of the reporting station indicated by another Peer STA Address field.

[0400] As it is obvious from the description, the wake-up schedule element 460 provides timing information specifying the period of P2P communication in the P2P session or the power saving period of the affiliated non-AP station.

[0401] In addition to the wake-up schedule element 460, other elements can be used to provide timing information. For example, the TWT element (shown in the Figure 8b element can inform the AP about all kind of TWTs (individual TWT, broadcast TWT, restricted TWT, OBS S TWT...). This element informs the AP about the schedule of the communication between the two peers and when concurrent communication will occur.

[0402] Similarly, the ( Figure 8aThe absence notification shown can be used to provide information about when a P2P station will not be involved in P2P communication, including scheduling of power-saving periods with the group owner. Therefore, regardless of any restrictions (such as EMLSR or NSTR), the AP can schedule infrastructure communication for these stations (both the reporting station and the other peer) during that period without the risk of interference with P2P communication.

[0403] In another variation, the TWT element or wake-up element can be used to carry timing information from the group owner. For this purpose, the reporting station may be able to convert timing requests supplied by the group owner (e.g., from absence notifications) into timing information carried in the wake-up or TWT element.

[0404] In a similar way, such as Figure 7g As shown, non-AP MLD P2P clients ( Figure 1b In a STA (A2 122) or P2P concurrent device, the group owner can be informed of the P2P TWT timing negotiated with the associated AP (associated with another subordinate non-AP STA or WLAN STA). Typically, P2P clients can do so via, as referenced... Figure 5b and Figure 5c The described usage pattern, where the channel is set to 3, uses a request / response mechanism to negotiate P2P TWT scheduling, and then notifies the group owner via a P2P presence process. In practice, P2P clients requiring the presence of the P2P group owner can submit a P2P presence request to the P2P group owner (including, for example...). Figure 8a The absence notification described herein can influence the power management timing of the P2P group owner. A P2P presence request may include bits to indicate to the group owner that the timing information carried in the absence notification was issued from the P2P TWT negotiated with the infrastructure AP. In this case, the group owner can follow this timing information to improve coexistence.

[0405] In a variant, if STA A2 122 is the group owner rather than a P2P client, then STA A2 can inform its P2P clients of the TWT timing negotiated with its associated AP.

[0406] As described above, in a variation of the point-to-point link event report frame, the P2P link report 715 may be a channel usage request frame 580 that includes a channel usage element 500 with a point-to-point indication.

[0407] The channel uses response frame 580 as shown above. Figure 5b As described.

[0408] In deformation, as shown in... Figure 5d or Figure 5e The additional information shown expands the frame.Figure 5d In a variant, the frame is augmented with all or part of the link ID field 457, another peer STA address field 458, the NSTR indication bitmap field 459, the wake-up schedule field 460 (or its variants) described above, plus all or part of the optional peer state field 456 also described above.

[0409] In a variant, the channel usage request frame 580 is augmented with the point-to- point link event report element 450 as described above. Figure 5e In a variant, the channel usage request frame 580 is augmented with the point-to- point link event report element 450 as described above. Figure 4b In a variant, the channel usage request frame 580 is augmented with the point-to- point link event report element 450 as described above. Figure 4d In a variant, the channel usage request frame 580 is augmented with the point-to- point link event report element 450 as described above.

[0410] Regardless of the frame considered (point-to-point link event report frame 291 or in the channel usage request frame 580), the frame can also contain a session ID that is used in subsequent P2P link reports (if any) to identify these new messages as updates of the session identified by this session ID. The session ID can also be carried in the session token field 583 or 352. In the TDLS case, the session ID can be the link identifier exchange during TDLS setup and is described in clause 9.4.2.60 in the standard D3.2.

[0411] In another different variant of the additional fields for the point-to-point link event report element or the channel usage request frame 580, the P2P link report message 715 can carry a coexistence element 490 as described with reference to Figure 4e

[0412] - the link ID field 457 as already described above to indicate the link on which the P2P communication is operating. This field can not be present if the report is transmitted on the P2P operating link and if the coexistence indication bitmap field 462 is not present.

[0413] - the other peer STA address field 458 as already described above. This information can 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 can indicate the BSS associated with the other peer (or other information allowing to identify the other AP / BSS). This can allow the AP receiving the report to set an OBSS TWT, or more generally, a service period to facilitate inter-BSS communication and thus OBSS coexistence.

[0414] ​- Coexistence indication bitmap field 462 is used to indicate link pairs with coexistence constraints (e.g., EMLSR, NSTR, or impacted by OBSS). The NSTR indication bitmap described above is one possible implementation of the bitmap 462. If the link pair corresponding to the link ID equal to <i, j> is inter-frame constrained (NSTR, EMLSR, or impacted by OBSS), each bit Bj (j ≠ i) in the coexistence indication bitmap field 462 included in the current element with link ID subfield value equal to i is set to 1; otherwise, bit Bj is set to 0. The 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 P2P transmissions occur on off-channel. Indeed, the AP is not aware of the link constraints of non-AP MLDs on other channels than the one operated by the AP MLD to which the AP belongs. This information is also useful if the non-AP MLD is subject to interference from other BSSs, e.g., if the station is located at the BSS border. If the station has no coexistence constraints, this bitmap can not exist.

[0415] - OBSS list indication field 463 is used to indicate one or more OBSSs that disturb the reporting station. This list can contain several BSSIDs and / or AP IDs that identify the OBSSs. This information helps the AP MLD receiving the report to set up MAP coordination, e.g., inter-BSS TWT. In addition, the reporting station can add a collocated interference report element (as described in IEEE P802.11-REVme / D3.0 version (April 2023) in section 9.4.2.83) for each entry in the list to report some characteristics of the collocated interference as shown in Figure 11

[0416] - Report period field indicates whether the report is periodical and, if so, the period. Interference level field indicates the maximum level of the collocated interference power. Interference level accuracy / interference indicator field includes an expected accuracy field to indicate the expected accuracy of the interference estimate and includes an interference indicator field to indicate the interference source type. Interference interval field indicates the interval between two consecutive interference periods. Interference burst length field indicates the duration of each interference period. Interference start time / duty cycle field indicates the start of the interference burst based on the TSF timer. When interference interval or interference burst. Interference center frequency field indicates the center frequency of the interference. Interference bandwidth field indicates the bandwidth of the interference signal.

[0417] ​- If the reporting station fails to identify the OBSS causing the interference, the reporting station can set the AP ID to a specific value for unknown identity. However, in order to identify the OBSS and report against this specific OBSS, the reporting station can pre-emptively send a beacon request to obtain beacon reports from surrounding stations. One or more beacon reports can provide all or part of the information to feed the OBSS list indication.

[0418] - The coexistence schedule element 464 is used to indicate the period of time when the reporting station can be subject to coexistence issues, e.g., when the station is awake from the perspective of P2P communication. The information carried by this element helps the AP to not schedule concurrent communication with P2P communication when the P2P station is awake. In addition, if the coexistence issue is related to an OBSS, the scheduling information can help the AP MLD to setup an OBSS TWT where the OBSS is indicated in the OBSS list indication 463 and aligns in time with the information carried by the coexistence schedule element. The coexistence schedule element can be in the format described in reference Figure 8a 、 Figure 8b and Figure 8c , i.e., reusing the fields of these figures.

[0419] - The coexistence status field 465 is used to indicate whether a coexistence issue is ongoing and the cause of the coexistence issue: NSTR, EMLSR, and OBSS, etc.

[0420] When carrying the coexistence element 490, the P2P link report frame 715 can be more generally considered as a coexistence link report. If several links of the non-AP MLD are subject to limitations, or the non-AP MLD can send a report for each affected link, the link report can include several coexistence elements 490.

[0421] In some embodiments, the coexistence element 490 can be used in the point-to-point link event report frame 291 or in the channel usage request frame 580 (instead of the additional fields shown in Figure 4d 、 Figure 5d and Figure 5e ).

[0422] The coexistence link report can use a dedicated value in the table of Figure 3b describing the different available event types 364 of the event report frame 291. This dedicated value can be one of the reserved values from 6 to 220. For example, the value 6 as shown in Figure 3d can correspond to the coexistence type.

[0423] In a similar way, the channel usage element 500 can use a new value in the usage mode field 530 when carrying the coexistence element. This dedicated value can be one of the reserved values from 4 to 255. For example, the value 4 as shown in Figure 5a can correspond to the coexistence indication.

[0424] In another embodiment, the coexistence element 490 can be carried in the collocated interference report element shown in Figure 11 to enrich its report with additional information, as described below.

[0425] 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 link 152) and a NSTR (or coexistence) indication bitmap with the 0th bit set to 1 and the remaining bits set to 0. This configuration means that links 0 and 1 (151 and 152, respectively) belong to a NSTR link pair.

[0426] The initiator peer non-AP station STA A2 can then negotiate power save (state 240) of the tunnel direct link setup schedule with the partner peer non-AP station STA B2.

[0427] Thus, a TDLS peer PSM request frame 241 and a TDLS PSM response frame 242 are exchanged between STA A2 and STA B2.

[0428] When the TDLS stations agree on the scheduled power save, one of the peer STAs (e.g., the TDLS peer PSM initiator) sends a new P2P link report to the AP including a wake-up schedule element (or any other timing information element). As a result, the AP can adapt its schedule with respect to the TDLS stations according to the timing information included in the wake-up schedule element and then unbind (e.g., EMLSR, NSTR) during the power save period of the P2P stations.

[0429] In particular, when the association between the P2P peer stations has been previously completed (i.e., the session ID previously assigned for the P2P session is reused), or when the message includes another peer STA address, only one of the P2P peer stations can send the P2P link report.

[0430] In a similar way as the P2P link report is sent in response to a new awake window time slot or absence notification, the P2P link report can be sent after a new TWT agreement is established.

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

[0432] When a TDLS peer wants to end the TDLS session, it sends a TDLS teardown 229 to its partner peer. The transmission / reception of this TDLS teardown message 229 thus completes the TDLS session. The transmission of a new P2P link report can also be triggered to inform the AP that the TDLS session just ended. In response, the AP can lift all the constraints associated with the now ended P2P session.

[0433] Any of the types of frames already described above (e.g., the point-to-point link event report frame 291 and the channel usage request frame 580) can be used. The peer state field 456 can be set to indicate that the connection is terminated (the peer state is set to value 0 for direct link or to value 2 for IBSS membership).

[0434] Figure 7b Example of frame exchange in a timeline Figure 1b The scenario in which a non-AP MLD is associated with an AP MLD and the non-AP MLD is going to join a point-to-point group to communicate directly with the group owner or other clients of the P2P group. As in Figure 1b1 and Figure 7a The same reference numerals correspond to the same stages / steps / frames / entities as in

[0435] As shown in Figure 7a , the AP can send a P2P link report registration frame 710.

[0436] As in Figure 1b1 , the station STA A2 negotiates (stage 250) with the partner peer station STA B1 the creation of a P2P group or the joining of an existing group managed by the group owner STA B1.

[0437] When the STA A2 finally joins the P2P group, the non-AP MLD informs its associated AP about the establishment of the point-to-point link / group via the P2P link report message 715 through its affiliated STA A2. Any of the types of frames already described above (e.g., the point-to-point link event report frame 291 and the channel usage request frame 580) can be used. The peer state field 456 can be set to indicate that the connection is active (the peer state is set to value 1 for direct link or to value 3 for IBSS membership).

[0438] 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 link 152) and a NSTR (or coexistence) indication bitmap with the 0th bit set to 1 and the remaining bits set to 0. This configuration means that links 0 and 1 (151 and 152, respectively) belong to a NSTR link pair.

[0439] Next, the group owner STA B1 can transmit a beacon frame 270 including an absence notification (timing information) element to the group clients including the peer non-AP station STA A2.

[0440] Upon receiving the (new or updated) absence notification, the STA A2 sends a P2P link report to the AP including the absence notification element as timing information.

[0441] In a similar manner, the P2P link report can be sent after establishing a new TWT agreement or after receiving an absence notification related to a P2P presence procedure.

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

[0443] When a P2P station wants to disconnect from the P2P group, it performs a disassociation procedure 264 (or a deauthentication procedure not shown) with its group owner, such as defined in IEEE 802.11 sections 11.3.5.6 or 11.3.4.4. In the same manner, the group owner can disconnect a client.

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

[0445] Any type of frame already described above can be used (e.g., the point-to-point link event report frame 291 and the channel usage request frame 580). The peer state field 456 can be set to indicate that the connection is terminated (the peer state is set to value 0 for direct link or to value 2 for IBSS membership).

[0446] Figure 7c Using frame exchange instances in timelines Figure 1c The scenario of FIG. 13, in which the two non-AP MLDs are associated with different AP MLDs and the non-AP MLDs are going to establish or join a point-to-point group to communicate directly with the group owner or other clients of the P2P group. The same reference numerals as in Figure 1a1 and Figure 7a correspond to the same stages / steps / frames / entities.

[0447] This figure describes the TDLS setup between TDLS stations associated with different APs within the ESS or belonging to a non-collocated AP MLD. The non-collocated AP MLD can be seen as an AP MLD with non-collocated dependent APs. In other words, the logical AP MLD has at least two dependent APs instantiated on physically separated devices.

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

[0449] The frames can be forwarded to all APs belonging to the ESS or to the non-collocated AP MLD either on the channel on which they are initially received (from the stations) or through a dedicated backhaul link used to connect the APs between them.

[0450] In a variant of the forwarding to all APs, the AP MLD can have a correspondence table indicating to which APs the respective stations are associated (for the ESS case) or physically connected (for the non-collocated AP MLD case, the stations attached to the non-AP MLD are physically connected to one specific AP of the non-collocated AP MLD while remaining associated to the logical non-collocated AP MLD). In this case, the frames to be forwarded are only sent to the APs (or AP MLDs) to which the target peer stations are associated or to which the target peer stations are physically connected. However, due to the nature of the multi-link operation, the frames directed to the non-AP MLD can be relayed on a different link than the one on which the frame is received from the peer station, said different link reaching the AP MLD to which the target peer non-AP MLD is associated or to which the target peer non-AP MLD is physically connected.

[0451] In another variant, the frames are forwarded to the controller 180 and the controller in turn sends the frames to the APs or AP MLDs to which the target peer stations are associated or to which the target peer stations are physically connected. This last variant assumes that the controller has a table indicating to which APs or AP MLDs the respective stations are linked.

[0452] In any case, and contrary to the conventional TDLS mechanism, the dependent AP 12 receiving the TDLS action frame from the associated STA A2 determines that the TDLS action frame is destined to a STA B1 associated with an AP 21 instantiated in another physical device than AP 12, and then forwards the received TDLS action frame to AP 21 over the communication link established between them (the two APs). In turn, AP 21 receiving such TDLS action frame transmits the received TDLS action frame to the associated STA B1 station on the operating channel of AP 21.

[0453] As shown, AP 112 relays TDLS discovery request frame 221, TDLS setup request frame 223, TDLS setup response frame 224, and TDLS setup confirmation frame 225 between STA A2 and AP 192. And AP 192 in turn relays TDLS discovery request frame 221, TDLS setup request frame 223, TDLS setup response frame 224, and TDLS setup confirmation frame 225 between AP 192 and STA Bl. In some embodiments, the relayed frames can also be passed through controller 180 as described above.

[0454] In this timeline, the various TDLS peer STAs send P2P link reports 715 to their associated APs due to their association with different APs.

[0455] In variations, the P2P link report from one of the TDLS peer STAs can be forwarded by its associated AP to the controller, and the controller can forward the report to the ESS or other APs of the non-collocated AP MLD.

[0456] TDLS peer STA A2 122 can then send P2P data traffic 226 to TDLS peer STA Bl 141.

[0457] In addition, the timeline illustrates another use case in which the non-AP MLD initially has no NSTR constraints between its two affiliated stations operating on the AP link or between stations STA Al and STA A2 when the latter operates on an off-channel for P2P communications. However, AP1 111 can decide to change its operating channel through a channel switch procedure 720, thus making link 1 of STA Al (the new channel of AP1 111) and link 2 of STA A2 become NSTR (when STA A2 operates on an off-channel for P2P communications). The AP MLD 110 can not be aware of this new constraint because the NSTR constraint links to the off-channel for P2P. The channel switch in this case can trigger the sending of a P2P link report 715 by STA Al to inform its AP of the newly formed NSTR link pair.

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

[0459] Figure 7d P2P link reports sent in response to an explicit request from the AP in the context of a TDLS session are illustrated. As shown, a point-to-point link event request / reporting procedure can be used. The P2P link report can also be sent in a channel usage request during the usual channel usage request / response procedure.

[0460] Figure 7e An example of a P2P link report sent in a probe request frame including a channel usage element during an association procedure with an AP MLD occurring after P2P group creation is illustrated. As shown in this figure, a probe request / response procedure can be used.

[0461] Figure 7f An example of sending a coexistence report in response to an explicit request from an AP is illustrated. In other words, a station that supports coexistence reporting (which can indicate / share this capability during association) can request a coexistence report from other stations.

[0462] In the example of Figure 7f , STA Al 121 (affiliated to non-AP MLD A 102) is associated with AP1 111 (affiliated to AP MLD 110) and STA Bl 141 (affiliated to non-AP MLD B 104) is associated with AP2 191 (affiliated to AP MLD 190). Different stations support coexistence reporting and have indicated such supported capability during association with their respective AP. The two non-AP MLDs are going to establish a point-to-point link to communicate directly with each other.

[0463] After association, AP1 111 can send a coexistence request frame 750 to its associated stations. Reference is made to Figure 10a The format of the coexistence request frame is further described. The frame includes a category field 581, a WNM field 582, a conversation token field 583, a coexistence request information element field 1010, as follows:

[0464] - The category field 581 is similar to the category field 300 described above (value of 10).

[0465] - The WNM field 582 defines the type of frame. Any of the reserved values from Table 9-510 in IEEE P802.11-REVme / D3.0 (April 2023) can be used to signal the frame as a coexistence request frame. For example, the WNM action field is equal to 28.

[0466] - The conversation token field 583 is a non-zero value selected by the STA sending the coexistence request frame to identify the request / response transaction.

[0467] - The coexistence request information element field 1010 includes one or more subfields, each subfield as follows:

[0468] o The OBSS subfield 1011 is used to request OBSS information (if present) to the receiving stations.

[0469] This subfield can be 1 bit long to request all information, or several bits long to specify which information the requesting station wants to get (e.g. coexistence bitmap, OBSS list, schedule...).

[0470] o The P2P link subfield 1012 is used to request P2P link information (if any) to the receiving station.

[0471] This subfield can be 1 bit long to request all information, or several bits long to specify which information the requesting station wants to get (another peer STA address, wake-up schedule...).

[0472] o The periodicity subfield 1013 is used to indicate the periodicity of the report. The periodicity can be set for example to “single”, meaning that only one report is expected in response to the request, or to a value in TU, meaning that a report is expected at each such time period, or to “event-based”, meaning that a report is expected when a condition changes (e.g. new P2P link, end of P2P link, new OBSS or interference...).

[0473] Back to Figure 7f Upon reception of the coexistence request frame 750, the station A1 121 responds with a coexistence report frame 751 including the information required by the requesting station through the field 1010 and its subfields. Reference is made to Figure 10b The coexistence report frame is described. This frame includes a category field 581, a WNM field 582, a conversation token field 583, a coexistence report element field 1021, as follows:

[0474] - The category field 581 is similar to the category field 300 described above (value 10).

[0475] - The WNM field 582 defines the type of the frame. Any reserved value according to table 9-510 in IEEE P802.11-REVme / D3.0 (April 2023) can be used to signal the frame as a coexistence report frame. For example, the WNM action field is equal to 29.

[0476] - The conversation token field 583 is a non-zero value selected by the STA sending the coexistence request frame to identify the request / response transaction.

[0477] - The coexistence report element field 1021 can include the different elements / fields shown in Figure 4d , Figure 4e , Figure 5d and Figure 5e . This element carries the information requested by the coexistence request information 1010.

[0478] In some variants, when the station Al 121 receives the coexistence request frame 750, the station can send a beacon request frame 760 to its peer (in the example of the figure, station Bl 141) to obtain information about its peer's BSS, then fill in the coexistence report 751 accordingly. In response to the beacon request received from the station STA Al 121, the station ST A Bl 141 sends a beacon report. The station Al 121 can also ask for information about the TWTs in its own BSS that can involve the peer station. This information can be used for example to fill in the coexistence schedule field 464 to avoid concurrent communications of both stations (STA Al 121 and ST A Bl 141) in their own BSS.

[0479] Back to the coexistence report, when the AP1 111 receives the information, it can create rules for the reporting station to improve the coexistence between the infrastructure communications 780 and the P2P communications 226 and / or the communications within OBSS 770.

[0480] Figure 9a The communication device 900 of the radio network NETW configured to implement at least one embodiment of the application is schematically illustrated (non-AP MLD (embedding multiple non-AP stations 101-107) or AP MLD (embedding multiple APs 110)). The communication device 900 can preferably be a device such as a microcomputer, a workstation or a light portable device. The communication device 900 comprises a communication bus 913, preferably connected with:

[0481] a central processing unit 901, such as a processor, denoted CPU;

[0482] a memory 903 for storing executable code of the method or method steps according to an embodiment of the application, as well as registers adapted to record variables and parameters required to implement the method; and

[0483] 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 a transmission and reception antenna 904.

[0484] Preferably, the communication bus provides communication and interoperability between the various elements included in or connected to the communication device 900. The representation of the bus is not limiting and in particular the central processing unit is operable to direct communication to any element of the communication device 900, directly or with the aid of another element of the communication device 900.

[0485] The executable code can be stored in a memory, which can be a read-only hard disk or a removable digital medium (such as a disk). According to an optional variant, the executable code of the program can be received via the interface 902 by means of a communication network, to be stored in the memory of the communication device 900 before being executed.

[0486] In an embodiment, the device is a programmable device using software to implement embodiments of the application. However, alternatively, embodiments of the application can be implemented in hardware, in whole or in part, for example, in the form of an application-specific integrated circuit or ASIC.

[0487] Figure 9b is a block diagram schematically illustrating the architecture of a communication device 900 adapted to implement, at least in part, embodiments of the application. As shown, the device 900 comprises a physical (PHY) layer block 923, a MAC layer block 922 and an application layer block 921.

[0488] The PHY layer block 923, here a plurality of 802.11 standardized PHY layer modules, has the task of formatting, modulating on any 20 MHz channel or composite channel, or demodulating from any 20 MHz channel or composite channel, and thus transmitting or receiving frames, such as 802.11 frames, on the radio medium NETW, such as medium access trigger frames for reserving transmission slots, 20 MHz width-based MAC data and management frames for interacting with legacy 802.11 stations, and MAC data frames of OFDMA type with a width less than 20 MHz legacy (typically 2 or 5 MHz) to / from this radio medium.

[0489] The MAC layer block or controller 922 preferably comprises an MLE MAC 802.11 layer 924 implementing the conventional 802.11 MAC operations, and an additional block 925 for implementing, at least in part, embodiments of the application. The MAC layer block 922 can optionally be implemented in software, which is loaded into the RAM 903 and executed by the CPU 901. The MLE MAC 802.11 layer 924 can implement the upper MAC stack as well as a series of low MAC modules.

[0490] Preferably, the additional block 925, called P2P management module, implements part of the embodiments of the application (at the peer non-AP MLD) for low-latency services for P2P flows over multi-link communications. This block performs the operations of the application depending on the role of the communication device 900, TWT schedule AP or peer station. Figure 6a- Figure 7g

[0491] According to embodiments of the application, the MAC 802.11 layer 924 and the P2P management 925 interact with each other to accurately establish and process communications over OFDMA RUs between a plurality of non-AP MLD stations.​

[0492] In Figure 9b The upper portion of the application layer block 921 runs an application for generating and receiving a packet (e.g., a packet such as a video stream). The application layer block 921 represents all stack layers above the MAC layer standardized according to ISO.

[0493] Although the present application has been described above with reference to specific embodiments, the present application is not limited to the specific embodiments and modifications falling within the scope of the present application will be apparent to those skilled in the art.

[0494] Many further modifications and variations to the illustrative embodiments described above will be apparent on reference to the foregoing description to those skilled in the art. All such modifications and variations are believed to fall within the scope of the present application, which is defined by the appended claims. In particular, different features from different embodiments can be interchanged and the scope of the application should not be limited to the described features.

[0495] 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 these can not be advantageously used in combination.

Claims

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

2. The method of claim 1, further comprising: The activity on the one constrained link is determined 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 on the one constrained link, wherein the coexistence or P2P link report is reported in relation to the P2P session.

3. The method of claim 2, wherein, The non-AP device comprises a P2P concurrent device carrying a first station associated with the AP device and a second station collocated with the first station, the second station acting as a P2P device operating in a P2P group, wherein declaring the transmission constraints comprises sending, by the first station, to the AP device, a capability for a P2P concurrent operating mode, and sending the coexistence or P2P link report comprises sending, by the first station, to the AP device, timing information obtained by the collocated P2P device in relation to a P2P session, the timing information defining a period of P2P communication in the P2P session.

4. The method of claim 3, wherein, Sending the obtained timing information comprises sending a channel usage request frame comprising a target wake time, TWT, element representing 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 comprises receiving, by the collocated P2P device, from the P2P group owner, a target wake time, TWT, element indicating a P2P communication period or an absence notification element indicating an absence period of P2P communication, and the sending step to the AP device comprises sending a channel usage request frame comprising a second target wake time, second TWT, element comprising the timing information derived from the received TWT element or absence notification element.

6. The method of claim 3, wherein, The first station acts as a P2P device operating in a second P2P group and the AP device comprises a soft-AP operating as a 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, MLD, device having a first affiliated non-AP STA operating as a WLAN device in an infrastructure basic service set and a second affiliated non-AP STA operating as a P2P device.

8. The method of claim 1, wherein, The coexistence or P2P link report is sent in response to one of the following trigger events: - creating a P2P session, such as establishing or joining a TDLS session or a P2P group, - receiving a coexistence or P2P link report request frame from the AP device, - 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 transmission constraints between links, such as enabling or disabling enhanced multi-link single radio operation, 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 where a P2P session occurs to a different channel that becomes NSTR with another enabled link of the AP device, - switching the operating channel of a link of the AP device that becomes NSTR with a link where a P2P session occurs, - detecting interference from an overlapping basic service set, OBSS, disturbing a link of the non-AP device, - obtaining timing information about a P2P session, the timing information defining a period of P2P communication in the P2P session or a power saving period of an affiliated non-AP station.

9. The method of claim 1, wherein, The coexistence or P2P link report is transmitted in case enhanced multi-link single radio operation, EMLSR operation, is enabled for the links.

10. The method of claim 9, wherein, Enabling EMLSR operation for the links comprises transmitting an EML operation mode notification frame to the AP device.

11. The method of claim 9, wherein, The coexistence or P2P link report comprises a coexistence status field set to a first value to indicate that the non-AP device has coexistence activity on one or more of the links, or set to a second value to indicate that the non-AP device has no coexistence activity on one or more of the links.

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

13. The method of claim 12, wherein, Activating the EMLSR mode comprises transmitting an EML operation mode notification frame to the AP device.

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

15. The method of claim 1, further comprising: Receiving, from the AP device, information for enabling a coexistence or P2P link report, wherein the coexistence or P2P link report is transmitted only in case the coexistence or P2P link report is enabled.

16. A communication method in a wireless network, comprising, at an access point device, 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 occurring on one of the constrained links.

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

18. The method of claim 16, further comprising: Transmitting, to the non-AP device, information for enabling a coexistence or P2P link report to drive the non-AP device to transmit the coexistence or P2P link report only in case the coexistence or P2P link report is enabled.

19. The method of claim 16, further comprising: Adapting communications 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 communications in the BSS comprises adapting communications to the non-AP device.

21. The method of claim 19, wherein, Adapting communications in the BSS in response to receiving the coexistence or P2P link report reporting about an activity on an EMLSR link of the non-AP device.

22. The method of claim 16, further comprising: Adapt the scheduling of resources on the constrained link based on the received coexistence or P2P link report.

23. The method of claims 17 and 22, wherein, The adaptation of the scheduling comprises one or more than one of the following P2P rules: - reducing or avoiding downlink communication to the non-AP device on the constrained link, - registering the peer station in a TWT agreement negotiated with the non-AP device on one constrained link, - aligning the TWT schedule with the P2P inactivity period of the peer station of the P2P session informed in the P2P link report.

24. The method of claim 23, further comprising: De-adapt the scheduling in response to receiving a P2P link report reporting the termination of the P2P session.

25. The method of any of claims 16-24, further comprising: Selecting appropriate transmission parameters for the non-AP device.

26. The method of claim 1 or 16, wherein, The transmission constraints comprise non-simultaneous transmit and receive link pairs, NSTR link pairs, or enabled enhanced multi-link single radio operation, EMLSR operation, on the constrained link.

27. The method of claim 26, wherein, The NSTR link pairs are signaled in the P2P link report.

28. The method of claim 1 or 16, wherein, The coexistence or P2P link report comprises a point-to-point link event report element or a channel usage element with a point-to-point link indication.

29. The method of claim 28, wherein, The point-to-point link event report element or the channel usage element with a point-to-point link indication comprises one or more than one of the following fields: - a link ID field comprising an identifier of the link on which the P2P session occurs, - a peer STA address field comprising an identifier of the peer station, - an NSTR field reporting non-simultaneous transmit and receive link pairs, NSTR link pairs, of the non-AP device, and - a timing information field specifying a period of P2P communication in the P2P session or a power save period of the affiliated non-AP station, - a P2P session identifier field comprising an identifier of the P2P session, and - a P2P session status field comprising a current status of the P2P session.

30. The method of claim 28, wherein, The channel usage element with a point-to-point link indication comprises the point-to-point link event report element with one or more than one of the fields.

31. The method of claim 1 or 16, wherein, The coexistence or P2P link report comprises one or more than one of the following fields: - a link ID field comprising an identifier of the link on which the P2P session occurs, - a peer STA address field comprising an identifier of the peer station, - a coexistence indication bitmap field indicating one or more than one link pair experiencing transmission constraints, - an OBSS list indication field indicating one or more than one overlapping basic service set interfering with the constrained link, - a coexistence schedule element indicating a period of time during which 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 that the non-AP device has coexistence activity on one or more than one of its EMLSR links, and is set to a second value to indicate that the non-AP device has no coexistence activity on one or more than one of its EMLSR links.

33. The method of claim 1 or 12, wherein, The coexistence or P2P link report is included in a WNM Action frame with 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 for enabling the coexistence or P2P link report includes at least one of: a point-to-point link event report element in the frame, a channel usage element with a point-to-point link indication in the frame, a P2P related capability declared by the AP device in the 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 a dependent non-AP station of the non-AP device, the dependent non-AP station participating in a P2P session on one constrained link.

39. A frame sent by a non-access point device, non-AP device, the frame for reporting about a P2P session of a peer station that the non-AP device participates in, the frame including a point-to-point link event report element or a channel usage element with a point-to-point link indication, the point-to-point link event report element or the channel usage element with a point-to-point link indication including one or more than one of the following fields: - a Link ID field including an identifier of a link on which the P2P session occurs, - a Peer STA Address field including an identifier of the peer station, - an NSTR field including a non-simultaneous transmit and receive link pair, 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 save period of a dependent 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 communication method in a wireless network, comprising, at a first access point, first AP, instantiated in a first communication device: receiving, from a first non-AP station associated with the first AP, a TDLS action frame addressed to a second non-AP station associated with a second AP, the second AP instantiated in a second communication device physically separate 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 devices.

41. A communication method in a wireless network, comprising, at a second access point, second AP, instantiated in a second communication device: receiving, from a first access point, first AP, instantiated in a first communication device physically separate from the second communication device, a TDLS action frame initiated by a first non-AP station associated with the first AP and addressed to a second non-AP station associated with the second AP, and forwarding the received TDLS action frame to the second non-AP station over a communication link established between the first and second communication devices. transmitting the received TDLS action frame to the second non-AP station on an operating channel of the second AP.

42. A method of communication in a wireless network, comprising, at a second non- access point station, 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 separate from the second communication device, and responding to the received TDLS action frame with a TDLS response frame addressed to the first non-AP station, in case the TDLS action frame is destined to the second non-AP station.

43. The method of claim 40, 41, or 42, wherein, the TDLS action frame comprises a TDLS multi-link element having a MLD MAC address in an AP MLD MAC address field that does not match a MLD MAC address of an AP MLD that implements the second AP as a dependent AP.

44. The method of claim 40, 41, or 42, wherein, the TDLS action frame comprises a TDLS multi-link element having a MLD MAC address in an AP MLD MAC address field that matches a logical MLD MAC address of an AP MLD that implements the second AP as a dependent AP, and having an identifier in a physical device identifier field that does not match 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 a same ESS, or to a logical AP MLD having two or more dependent APs instantiated in physically separate communication devices.

46. The method of claim 40, wherein, the forwarding is on a same channel on which the TDLS action frame is received, or on an operating channel of the second AP determined by the first AP based on a corresponding table matching the second non-AP station to the second AP, or 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 to perform the steps of the method of claim 1, 16, 40, 41, or 42.

48. A non-transitory computer readable medium storing a program that, 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.

Images