An improved r-TWT-based communication method for P2P streams

Abstract

To perform P2P transmission within a bounded target wake time service period (rTWT service period), the initiator peer station establishes a membership of an rTWT schedule with an AP of the BSS, establishes a Tunneled Direct Link Setup (TDLS) session with the partner peer station, and efficiently informs the partner peer station about the rTWT schedule using a TDLS action frame carrying rTWT information such as a broadcast TWT identifier for the rTWT schedule. The TDLS action frame may be a modified or new type of TDLS Peer Traffic Indication frame or a modified TDLS Setup Request action frame used for TDLS session establishment. Thanks to this notification, the partner peer station can wake up to directly exchange peer-to-peer data with the initiator peer station at the appropriate time of the rTWT service period specified in the beacon frame from the AP.

Description

[Technical Field]

[0001] The present invention relates generally to wireless communications, and more particularly to peer-to-peer (P2P) communications. [Background technology]

[0002] With the development of latency-sensitive applications such as online gaming, real-time video streaming, virtual reality, and remote control of drones and robots, the requirements and issues of better throughput, lower latency, and robustness must be considered. These issues are currently being considered by the IEEE 802.11 Working Group as the primary objective of issuing the next major 802.11 release, known as 802.11be or EHT (Extremely High Throughput).

[0003] Low-Latency Reliable Service (LLRS) is defined as the target of this primary objective: LLRS is a service provided to higher layer traffic streams that prioritizes delivery of MSDUs (Data Units) within a worst-case delay budget with a given reliability / packet delivery ratio (PDR) and low jitter.

[0004] The IEEE P802.11be / D1.5 version (March 2022, hereinafter referred to as the "D1.5 standard") introduces multi-link (ML) operation (MLO), which improves data throughput by enabling communication between stations over multiple simultaneous and discontinuous communication links.

[0005] Multilink operation allows a non-AP (Access Point) MLD (MLD) to register with an AP MLD, i.e., discover, authenticate, associate, and establish multiple links with the AP MLD. Each link allows channel access and frame exchange between the non-AP MLD and the AP MLD based on the supported capabilities exchanged during association.

[0006] An MLD is a logical entity with multiple affiliated stations (APs or non-APs) and a single Medium Access Control (MAC) Service Access Point (SAP) for a Logical Link Control (LLC), containing one MAC data service. Thus, an AP MLD consists of multiple affiliated APs, and a non-AP MLD consists of multiple affiliated non-AP stations. Affiliated stations in both AP MLDs and non-AP MLDs can communicate with affiliated stations in other MLDs via each of the configured multiple communication links using 802.11 mechanisms.

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

[0008] The Stream Classification Service (SCS) mechanism, originally defined in the IEEE 802.11aa standard, has been adapted for inclusion in the D1.5 standard. Now, the SCS mechanism for multilink allows a non-AP MLD to define and advertise (delay-sensitive) traffic streams, identified by an SCS Identifier (SCSID), to the AP MLD. The adaptation of the SCS mechanism allows defining the QoS requirements of SCS streams through the so-called QoS Characteristics element, and in particular classifying the SCS stream as belonging to a TID class in the corresponding uplink (UL) or downlink (DL) direction.

[0009] The target wake time (TWT) mechanism originally defined in the IEEE 802.11ah and 802.11ax standards has been adapted for inclusion in the D1.5 standard. This adaptation, known as restricted target wake time (rTWT), schedules dedicated (and protected) service periods (SPs) for stations to transmit delay-sensitive traffic (e.g., SCS streams) over a BSS. The rTWT agreement is nothing more than a broadcast TWT agreement negotiated between the AP and associated non-AP stations in the BSS. Non-AP stations establish membership in the broadcast TWT (or rTWT) schedule with the AP. Schedules can be defined for several TIDs (i.e., QoS characteristics identified through the SCS mechanism). The rTWT service period SP of the rTWT schedule, during which the protected exchange of SCS traffic streams may occur, is advertised in a broadcasted management frame (e.g., a beacon) using the rTWT information (typically the broadcast TWT ID (bTWT ID)) related to the negotiated rTWT SP.

[0010] The triggered TXOP sharing (TXS) mechanism allows an AP to allocate a portion of the time in an acquired TXOP to only one associated non-802.11be station, after which it transmits one or more non-TB PPDUs. This appears as a single-user (SU) trigger. The specific trigger frame, called MU-RTS TXS, specifies the time allocated to non-AP stations in the TXOP acquired by the AP. The TXS mechanism facilitates P2P (peer-to-peer or Direct Link (DiL)) communication within the TXOP acquired by the AP.

[0011] These various mechanisms operate with difficulty, especially with respect to latency-sensitive P2P traffic.

[0012] On the other hand, the AP-centric aspect of the 802.11 MU transmission scheme, associated with the SCS and rTWT mechanisms, is not suited to bandwidth-hungry communication services (e.g., video-based services such as gaming, virtual reality, and streaming applications) since all communication passes through the AP, thereby doubling the airtime for transmission and the number of medium accesses (and therefore medium access time).

[0013] On the other hand, since the SCS and rTWT mechanisms are negotiated between the initiator non-AP station and the AP, other peer non-AP stations that are partners in P2P (or DiL) communication with the initiator peer non-AP station are excluded, and it is highly unlikely that the partner peer non-AP station is awake and therefore available for TXS-based P2P communication within the rTWT SP of the negotiated rTWT schedule.

[0014] In other words, the D1.5 standard is currently not satisfactory for P2P or DiL transmissions, and transmissions over conventionally specified rTWTs can be improved. Summary of the Invention

[0015] A broad object of the present invention is to overcome some of the above-mentioned concerns.

[0016] The inventors seek to improve this situation by taking advantage of the promising rTWT mechanism to facilitate P2P communication. In this context, the inventors explored a mechanism to properly inform a partner peer non-AP station about the rTWT schedule negotiated between the initiator peer non-AP station and the AP of the BSS (considering a standardized mechanism), so that the partner peer will wake up for the next rTWT SP in the rTWT schedule and thus be available for P2P communication when the initiator peer is allocated a portion of its service period.

[0017] In this context, a method of peer-to-peer communication in a wireless network, comprising: establishing a restricted target wake time (rTWT) schedule with an AP of the BSS; notifying partner non-AP stations of the BSS about the rTWT schedule, the notifying including transmitting a TDLS action frame to the partner non-AP stations including rTWT information about the rTWT schedule; exchanging peer-to-peer data directly with the partner peer non-AP stations during one or more rTWT service periods (SPs) of the rTWT schedule; A method is provided that includes:

[0018] A method for peer-to-peer communication in a wireless network from a partner's perspective, comprising: receiving a notification from an initiator's peer non-AP station of the BSS regarding a restricted target wake time (rTWT) schedule for which the initiator's peer non-AP station is establishing membership with the AP of the BSS, the notification including a TDLS action frame containing rTWT information regarding the rTWT schedule; exchanging peer-to-peer data directly with peer non-AP stations of the initiator during one or more rTWT service periods (SPs) of the rTWT schedule; A method is provided that includes:

[0019] Tunneled Direct Link Setup (TDLS) allows two non-AP stations to set up a P2P session by exchanging signaling frames via the AP, but in a manner that is transparent to the AP (because they are carried in data frames). The use of TDLS action frames to inform another TDLS peer of the rTWT schedule negotiated with the AP for P2P transmission is highly advantageous because it relies on existing frames but is transparent to the AP. Therefore, the TDLS mechanism can be included in the exchanged frames without requiring additional frames to be sent. Furthermore, the TDLS mechanism, like the SCS and rTWT mechanisms, is advantageous in that it operates within a BSS managed by the AP. Therefore, a TDLS initiator station sends a TDLS action frame containing rTWT information about the rTWT schedule to its TDLS responder station.

[0020] Optional features of the invention are defined below with reference to methods, but these can be substituted with apparatus features.

[0021] In some embodiments, the rTWT information includes a broadcast TWT identifier (bTWT ID) that identifies the rTWT schedule.

[0022] For example, the rTWT information consists of only the bTWT ID. This approach reduces overhead while providing simplicity for signaling rTWT SPs.

[0023] In another example, the rTWT information includes or consists of a Broadcast TWT Info subfield containing the bTWT ID. This approach advantageously signals to partner peers about the time window (lifetime) during which scheduled rTWT SPs are provided. Indeed, the D1.5 standard specifies that the Broadcast TWT Info subfield contains a Broadcast TWT Persistence indication for that purpose.

[0024] In yet another example, the rTWT information includes or consists of a Restricted TWT Parameter Set subfield that includes the bTWT ID. Partner peers are provided with complete information about the rTWT SP.

[0025] Additionally, in certain embodiments, the Restricted TWT Parameter Set subfield includes a Restricted TWT P2P TID Bitmap subfield that specifies which traffic identifiers (TIDs) or TIDs are permitted as delay-sensitive traffic streams for peer-to-peer exchange within the rTWT schedule. This subfield can be added to the (already standardized) UL and DL TID Bitmap subfields that specify which TIDs are identified as delay-sensitive traffic streams in the uplink and downlink directions, respectively. This indication helps the AP maintain control over the P2P traffic that is permitted to be exchanged during the service period of the rTWT schedule, while simultaneously informing partner peers of such restrictions.

[0026] In a more specific embodiment, the TDLS action frame includes both the Restricted TWT Parameter Set subfield and a TPU Buffer Status subfield containing information about buffered traffic at the initiator's peer non-AP station at the time the TDLS action frame was transmitted, and only buffered traffic corresponding to the TID or TIDs identified in the Restricted TWT P2P TID Bitmap subfield is reported in the TPU Buffer Status field, thereby achieving better fairness in buffer reporting.

[0027] In some embodiments, the TDLS action frame comprises a TDLS category action frame (meaning a TDLS action frame) with a TDLS Action field of TDLS Peer Traffic Indication or TDLS Peer Power Save Mode Request or Response, which is advantageous in that it avoids defining a new type of TDLS action frame because it relies on existing formats (TDLS Action field is 4 or 8).

[0028] In another embodiment, the TDLS action frame includes a TDLS category action frame with a TDLS Action field set to any value between 11 and 255 to define a TDLS Peer rTWT Indication. These values ​​are reserved in the D1.5 standard. These values ​​allow the definition of a new type of TDLS action frame for rTWT signaling in a P2P (TDLS) session.

[0029] In still other embodiments, the TDLS action frame comprises a TDLS Setup Request action frame (TDLS Action subfield is 0) for establishing a Tunneled Direct Link Setup (TDLS) session between two peer non-AP stations. These embodiments are advantageous in that they signal the rTWT schedule during the setup of the TDLS session, thereby avoiding the overhead of an additional frame.

[0030] In a particular embodiment, the method further includes exchanging TDLS Setup Response and TDLS Setup Confirm action frames between the two peer non-AP stations (these frames typically complete the setup of a TDLS session), where the TDLS Setup Response and Confirm action frames include the rTWT information. Thus, the rTWT information is repeated during multiple frames for setting up a TDLS session to fully confirm and verify the rTWT scenario between the peers.

[0031] In some embodiments, the method further includes, at the initiator peer non-AP station, negotiating a Tunneled Direct Link Setup (TDLS) session with the partner peer non-AP station before establishing membership in the rTWT schedule, and the TDLS action frame is transmitted within the TDLS session.

[0032] From a partner's perspective, the method further includes negotiating a Tunneled Direct Link Setup (TDLS) session at the partner's peer non-AP station with the initiator's peer non-AP station, wherein the TDLS action frame is received within the TDLS session once established (after the setup has been performed).

[0033] In this scenario, rTWT can be negotiated for P2P communication even when a P2P (TDLS) session is established, which provides flexibility in managing the network.

[0034] In some embodiments, the initiator's peer non-AP station or the partner's peer non-AP station (typically both) belong to a non-AP multi-link device (MLD), and thus the management of P2P communication described above may be performed on each link or multiple links of the non-AP MLD.

[0035] Relatedly, the present invention also provides a wireless communication device having at least one microprocessor configured to perform the steps of any of the above methods, which may be either non-AP MLD or AP MLD.

[0036] Another aspect of the invention relates to a non-transitory computer readable medium storing a program which, when executed by a microprocessor or computer system in a wireless device, causes the wireless device to perform any of the methods as defined above.

[0037] At least part of the methods according to the present invention may be computer-implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be referred to herein generally as a "circuit," "module," or "system." Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.

[0038] Because the present invention may be implemented in software, it may be embodied as computer-readable code for provision to a programmable device on any suitable carrier medium. Tangible, non-transitory carrier media may include storage media such as floppy disks, CD-ROMs, hard disk drives, magnetic tape devices, or solid-state memory devices. Transitory carrier media may include signals such as electrical, electronic, optical, acoustic, magnetic, or electromagnetic signals, e.g., microwave or RF signals. [Brief explanation of the drawings]

[0039] Embodiments of the present invention will now be described, by way of example only, with reference to the following drawings: [Figure 1] 1 illustrates an exemplary wireless communication system in which embodiments of the present invention may be implemented. [Figure 2] 1 illustrates possible scenarios for an initiator's peer non-AP STA to handle P2P traffic using a timeline frame exchange. [Figure 3] A diagram showing the data payload in the format of a Tunneled Direct Link Setup (TDLS) action frame of a data frame. [Figure 4] FIG. 10 is a diagram showing a Stream Classification Service (SCS) descriptor included in an SCS frame. [Figure 5] 1 shows the format of the TWT (Target Wake Time) element adapted to be used in r-TWT according to the D1.5 standard. [Figure 6] 1 illustrates, by way of a flow chart, exemplary steps in a peer non-AP MLD (or station) according to some embodiments of the present invention. [Figure 7] FIG. 10 illustrates a modified Restricted TWT Traffic Info subfield within the Restricted TWT element according to an embodiment of the present invention. [Figure 8]3 illustrates the scenario of FIG. 2 with frame exchanges in a timeline when an initiator peer notifies a partner peer of an rTWT schedule for a P2P low-latency traffic stream according to an embodiment of the present invention. [Figure 9] 7 illustrates, by way of a flow chart, exemplary steps in a peer non-AP MLD (or station) according to an alternative embodiment of FIG. 6. [Figure 10] 9 illustrates an alternative scenario to FIG. 8 in which the establishment of membership in the rTWT schedule precedes the establishment of the P2P session using a timeline frame exchange. [Figure 11a] 1 is a schematic diagram of a communication device in accordance with at least one embodiment of the present invention. [Figure 11b] FIG. 11b shows a schematic diagram of the architecture of the communication device of FIG. 11a; [Figure 12a] 12a, 12b, 12c, 12d, 12e, and 12f illustrate exemplary modifications of the table including information in the TDLS Setup Request Action field, the TDLS Setup Response Action field, the TDLS Setup Confirm Action field, the TDLS Peer Traffic Indication Action field, the TDLS Peer PSM Request Action field, and the TDLS Peer PSM Response Action field, respectively. [Figure 12b]12a, 12b, 12c, 12d, 12e, and 12f illustrate exemplary modifications of the table including information in the TDLS Setup Request Action field, the TDLS Setup Response Action field, the TDLS Setup Confirm Action field, the TDLS Peer Traffic Indication Action field, the TDLS Peer PSM Request Action field, and the TDLS Peer PSM Response Action field, respectively. [Figure 12c] 12a, 12b, 12c, 12d, 12e, and 12f illustrate exemplary modifications of the table including information in the TDLS Setup Request Action field, the TDLS Setup Response Action field, the TDLS Setup Confirm Action field, the TDLS Peer Traffic Indication Action field, the TDLS Peer PSM Request Action field, and the TDLS Peer PSM Response Action field, respectively. [Figure 12d] 12a, 12b, 12c, 12d, 12e, and 12f illustrate exemplary modifications of the table including information in the TDLS Setup Request Action field, the TDLS Setup Response Action field, the TDLS Setup Confirm Action field, the TDLS Peer Traffic Indication Action field, the TDLS Peer PSM Request Action field, and the TDLS Peer PSM Response Action field, respectively. [Figure 12e]12a, 12b, 12c, 12d, 12e, and 12f illustrate exemplary modifications of the table including information in the TDLS Setup Request Action field, the TDLS Setup Response Action field, the TDLS Setup Confirm Action field, the TDLS Peer Traffic Indication Action field, the TDLS Peer PSM Request Action field, and the TDLS Peer PSM Response Action field, respectively. [Figure 12f] 12a, 12b, 12c, 12d, 12e, and 12f illustrate exemplary modifications of the table including information in the TDLS Setup Request Action field, the TDLS Setup Response Action field, the TDLS Setup Confirm Action field, the TDLS Peer Traffic Indication Action field, the TDLS Peer PSM Request Action field, and the TDLS Peer PSM Response Action field, respectively. DETAILED DESCRIPTION OF THE INVENTION

[0040] The techniques described herein may be used for various broadband wireless communication systems, including communication systems based on orthogonal multiplexing. Such communication systems include, for example, spatial division multiple access (SDMA) systems, time division multiple access (TDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, and single-carrier frequency division multiple access (SC-FDMA) systems. SDMA systems may utilize sufficiently different directions to transmit data belonging to multiple user terminals, i.e., wireless devices or wireless stations, in parallel. TDMA systems may allow multiple user terminals to share the same frequency channel by dividing the transmission signal into different time slots or resource units and assigning each time slot to a different user terminal. OFDMA systems utilize orthogonal frequency division multiplexing (OFDM), a modulation technique that divides the overall system bandwidth into multiple orthogonal subcarriers or resource units. These subcarriers may be referred to as tones, bins, etc. In OFDM, each subcarrier is independently modulated with data. An SC-FDMA system may utilize Interleaved FDMA (IFDMA), which transmits on subcarriers distributed across the system bandwidth, Localized FDMA (LFDMA), which transmits on blocks of adjacent subcarriers, or Enhanced FDMA (EFDMA), which transmits on multiple blocks of adjacent subcarriers.

[0041] The teachings herein may be incorporated into (e.g., implemented within or performed by) various apparatuses (e.g., stations). In some aspects, a wireless device or station implemented in accordance with the teachings herein may or may not include an access point (so-called AP) (so-called non-AP station or STA).

[0042] Although the present example is described in the context of a Wi-Fi network, the invention may be used in any type of wireless network, such as, for example, a mobile phone cellular network, which implements a very similar scheme.

[0043] An AP may include, be implemented as, or be known as a Node B, Radio Network Controller ("RNC"), Evolved Node B (eNB), 5G Next Generation Base STA (gNB), Base STA Controller ("BSC"), Base Transceiver Station ("BTS"), Base Station ("BS"), Transceiver Function ("TF"), wireless router, wireless transceiver, Basic Service Set ("BSS"), Extended Service Set ("ESS"), or other term.

[0044] A non-AP station may include, be implemented as, or be known as a subscriber station, subscriber unit, mobile station (MS), remote station, remote terminal, user terminal (UT), user agent, user device, user equipment (UE), user station, or other terminology. In some implementations, a STA may include a mobile phone, a cordless phone, a session initiation protocol ("SIP") phone, a wireless local loop ("WLL") station, a personal digital assistant ("PDA"), a handheld device with wireless connectivity capabilities, or other suitable processing device connected to a wireless modem. Accordingly, one or more aspects taught herein may be incorporated into a phone (e.g., a mobile phone or smartphone), 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 satellite radio), a global positioning system (GPS) device, or any other suitable device configured to communicate via a wireless or wired medium. In some aspects, a non-AP station may be a wireless node. Such wireless nodes may, for example, provide connectivity to a network (eg, a wide area network such as the Internet or a cellular network) via a wired or wireless communication link.

[0045] An AP manages a set of stations that organize access to the wireless medium for communication. The stations (including the AP) form a service set, hereafter called a Basic Service Set (BSS) (other terms may be used). The same physical station acting as an access point may manage more than one BSS (and therefore corresponding WLAN): each BSS is therefore uniquely identified by a specific Basic Service Set Identification (BSSID) and is managed by a separate virtual AP implemented in the physical AP.

[0046] The 802.11 family of standards defines a variety of medium access control (MAC) mechanisms for driving access to the wireless medium.

[0047] Current discussions in Task Group 802.11be, as outlined in the March 2022 draft IEEE P802.11be / D1.5, introduce multilink operation (MLO) for MAC layer operation, allowing a multilink device to establish or configure multiple links and operate them simultaneously.

[0048] A Multilink Device (MLD) is a logical entity that has multiple attached (AP or non-AP) stations (STAs) and a single Medium Access Control (MAC) Service Access Point (SAP) for a Logical Link Control (LLC) containing one MAC data service. Additionally, the MLD has a single address associated with the interface that can be used to communicate over the Distribution System Medium (DSM).

[0049] The stations forming the same MLD may be partly or entirely located in the same facility, or may be geographically dispersed.

[0050] An Access Point Multilink Device (AP MLD) corresponds to an MLD in which each station (STA) belonging to the MLD is an AP, and is hereafter referred to as an "affiliated AP."

[0051] A non-access point multilink device (non-AP MLD) corresponds to an MLD in which each station (STA) belonging to the MLD is a non-AP station, and is called an "affiliated non-AP station."

[0052] Hereinafter, when referring to either an AP MLD or a non-AP MLD, the general term "station MLD" may be used.

[0053] In some literature, "multilink device", "ML device" (MLD), "multilink logical entity", "ML logical entity" (MLE), "multilink set", and "ML set" are synonyms for the same type of ML device.

[0054] Multiple affiliated non-AP STAs in a non-AP MLD can establish communication links with multiple affiliated APs in an AP MLD, forming a multilink channel. This is done, for example, through a conventional association procedure: ML discovery, which includes passive scanning (ML beacons) or active scanning (ML probe requests and corresponding responses), followed by ML authentication, and finally, ML setup, in which the non-AP MLD associates with the AP MLD (thus obtaining an association ID (AID)) and establishes ML links for the multiple APs and their associated non-AP STAs in the AP MLD.

[0055] Links (or "enabled links") established for MLD are theoretically independent, meaning that channel access procedures (to the communication medium) and communications are performed independently on each link. Thus, different links may have different data rates (e.g., due to different bandwidths, number of antennas, etc.) and may be used to communicate different types of information (over each particular link).

[0056] Thus, a communication link or "link" corresponds to a predetermined channel (e.g., 20 MHz, 40 MHz, etc.) in a predetermined frequency band (e.g., 2.4 GHz, 5 GHz, 6 GHz) between an AP belonging to an AP MLD and a non-AP STA belonging to a non-AP MLD.

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

[0058] Multi-link aggregation theoretically allows traffic associated with one MLD to be carried over multiple parallel communication links, thereby increasing network capacity and making the best use of available resources.

[0059] The terms "traffic" and / or "traffic stream," as used herein, are defined as data flows and / or streams between wireless devices.

[0060] 1 shows a wireless communication system in which multiple communication station devices 101-107, 110 exchange data frames over a wireless transmission channel 100 of a wireless local area network (WLAN) under the control of a central station, i.e., an access point device (AP) 110. Direct communication between STAs can also be performed without the use of an access point (known as ad-hoc mode). The wireless transmission channel 100 is defined by an operating frequency band that can consist of a single channel, multiple channels forming a composite channel, or multiple separate channels (links) forming a multi-link operation.

[0061] In the following description, the terms "station" or "STA" may be used to describe a non-AP station operating on a given link of 100, which may be a standalone non-AP station or an affiliated non-AP station entity of a non-AP MLD device. Similarly, the term "AP" refers to an AP station operating on a given link, which may be a standalone AP station or an affiliated AP station entity of an AP MLD device.

[0062] An exemplary situation of direct communication, which corresponds to a recent increasing trend, includes the existence of peer-to-peer (P2P, also known as direct link or "DiL") transmission between non-AP stations, e.g., STA 102 and STA 104, as shown in the figure. Technologies supporting P2P transmission are, for example, WiFi-Miracast® or wireless display scenarios, or Tunneled Direct Link Setup (TDLS). Note that even if P2P flows are generally not numerous, the amount of data per flow can be enormous (typically low-compression video from 1080p60 to 8K UHD resolution).

[0063] Each STA 101-107 registers with the AP 110 during an association procedure. During the association procedure, the AP 110 assigns a specific Association IDentifier (AID) to the requesting STA. For example, the AID is a 16-bit value that uniquely identifies the STA. When an AP and a non-AP STA are, respectively, an affiliated AP of an ML AP device and an affiliated non-AP of an ML non-AP device, they establish an ML association in which a unique AID is assigned across the non-AP MLD: all affiliated non-AP STAs are identified by the same AID value on each operational link.

[0064] Stations 101-107, 110 may compete head-to-head on a given link using EDCA (Enhanced Distributed Channel Access) contention to be granted a transmission opportunity (TXOP) and subsequently access the wireless medium to transmit a (single-user, SU) data frame. Stations may also use a multi-user (MU) scheme in which a single station, typically the AP 110, is permitted to schedule MU transmissions, i.e., multiple simultaneous transmissions with other stations, within the wireless network. One implementation of such a MU scheme is adopted, for example, in the IEEE Std 802.11ax-2021 standard as the multi-user uplink and downlink OFDMA (MU UL and DL OFDMA) procedure.

[0065] Figure 2 illustrates a possible scenario for an initiator's peer non-AP STA to process P2P traffic using a timeline of frame exchanges.

[0066] This example includes STA2 102 as an initiator of P2P communication and STA4 104 as a partner in P2P communication, both belonging to the same BSS on a given link and associated with AP 110. As mentioned above, STA2 and STA4 may be non-AP stations belonging to their respective non-AP MLDs, and AP 110 may be an AP belonging to an AP MLD.

[0067] In the figure, vertical state bands 201 and 202 indicate the states of STA2 and STA4, respectively, over time, and therefore their activity. The black portions of the bands represent the active (or awake) state of the corresponding station, while the white portions represent the doze (sleep) state. Conventional mechanisms are known for switching from one state to the other. For example, a station in the doze state typically wakes up (switches to the active state) at the beacon time to receive beacon frames.

[0068] In the sequence, once STA2 and STA4 have associated with the AP (association not shown), they can exchange data over the operational link (phase 210).

[0069] For example, during phase 210, a P2P session can be opened (WiFi-Miracast, TDLS, etc.).

[0070] As a legacy P2P mechanism remaining in 802.11, Tunneled direct-link setup (TDLS) is characterized by the use of signaling frames encapsulated in data frames so that the signaling frames are transmitted transparently through the AP. Thus, to use TDLS, an AP does not need to be aware of the direct link, nor does it need to support the same set of capabilities used in a direct link.

[0071] In the sequence shown, a TDLS session or "TDLS direct link" is established between STA2 and STA4 (either of them can be the initiator of the establishment). The establishment can include TDLS discovery (optional) and TDLS setup. At this time, both STA2 and STA4 are in the active state.

[0072] TDLS discovery and setup between STA2 and STA4 typically involves frames being sent and received through an intermediate AP 110. The TDLS procedure is characterized by encapsulating signaling frames into 802.11 data frames, thereby allowing them to be transmitted transparently through the AP.

[0073] When attempting to discover TDLS stations within the same BSS, a series of frame exchanges is used. In the proposed scenario, the initiator STA2 sends a TDLS Discovery Request frame 211 tunneled through the AP 110 to an individual destination station, here STA4. This request frame carries a Link Identifier element containing the BSSID field, the TDLS initiator STA address field, and the TDLS responder STA address field. The BSSID field is set to the BSSID of the BSS of which the initiator STA2 is a member. The TDLS initiator STA address field is set to the MAC address of the TDLS initiator STA, and therefore the MAC address of STA2. The TDLS responder STA address field is set to the MAC address of the TDLS responder STA, and therefore the MAC address of STA4. The destination station STA4 responds directly to STA4 (without relaying through the AP 110) with a TDLS Discovery Response frame 212.

[0074] When attempting to establish a TDLS direct link over a single link with a discovered TDLS station, a series of frame exchanges is used to set up the TDLS link. The initiator STA2 (TDLS initiator) first sends a TDLS Setup Request frame 213 to the target partner STA4 (TDLS responder), tunneled through AP 110 (relay illustrated by a black dot). This frame contains information about the initiator STA2's capabilities and its AID. The target partner STA4 responds with a TDLS Setup Response frame 214, also tunneled through AP 110, containing information about its capabilities, its AID, and a status code either accepting or rejecting the setup request. If the Setup Request is accepted, the initiator STA2 then sends a confirmation, a TDLS Setup Confirm frame 215, via AP 110. This completes the TDLS setup handshake. At this point, the two stations know each other's identity: one by MAC address and the other by AID.

[0075] The stations can then begin communicating directly: P2P traffic 216 can be exchanged directly between STA2 and STA4 (not shown as a black dot at the AP in the figure due to the arrow 216) using the established TDLS session. The TDLS peers are then configured to accept data frames received directly from other peers. The frame exchange is performed over the same link, i.e., the same frequency channel, so that this P2P traffic is simultaneous with other traffic at the AP.

[0076] The discovery procedure may rely on a scanning procedure in a predefined band, with listen and search states, as described in WiFi-Miracast®. This discovery procedure also makes it possible to obtain the identities of peer STAs.

[0077] The details of the TDLS procedure are provided in IEEE802.11z and have been upgraded to be established over one of several possible links as provided in the D1.5 standard.

[0078] Referring to FIG. 3, the data payload of a TDLS frame is shown under reference numeral 300 .

[0079] The data payload 300 has the format of a frame, and therefore has a Category field 301 , an Action field 302 immediately following the Category field 301 , and an Element field 303 .

[0080] The different values ​​of the Category field 301 are defined in the 802.11 standard and correspond to different action frames: a Category field set to 12 defines a TDLS action frame, and a Category field set to 4 defines a Public action frame.

[0081] The TDLS action frame carries the TDLS signaling.

[0082] The 1-byte Action field 302 of a TDLS action frame can take on various values ​​from 0 to 10 (11 to 255 are reserved) corresponding to various signaling, as shown in Table 9-496 of the 802.11 standard (e.g., IEEE P802.11-REVme™ / D1.0, December 2021, provides the latest assignments for these standardized values). For example, a TDLS Setup Request frame 213 can be identified by its Action field 302 set to 0, a TDLS Setup Response frame 214 can be identified by its Action field 302 set to 1, and a TDLS Setup Confirm frame 215 can be identified by its Action field 302 set to 2.

[0083] For illustrative purposes, Table 9-501 of the 802.11 standard, reproduced in Figure 3, shows the elements 303 to be provided in a TDLS Peer Traffic Indication frame (Action field 302 set to 4). Each type of TDLS Action frame has its own set of elements 303 to be provided (as defined in the standard).

[0084] Similarly, the 1-byte Action field 302 of a Public Action frame can take on a range of values ​​from 0 to 45 (46 to 255 are reserved). For example, a TDLS Discovery Response frame 211 can be identified by its Action field 302 set to 14.

[0085] Returning to Figure 2, the initiator STA2 may wish to benefit from the enhanced services offered by AP 110 that are relevant to low-latency traffic from real-time applications with stringent latency requirements. These include the Stream Classification Service (SCS) mechanism and the Restricted Target Wake Time (rTWT) mechanism.

[0086] To meet the low latency requirements in EHT and at the same time improve the operational efficiency of MU UL, it is proposed that the Stream Classification Service (SCS) mechanism originally defined in the IEEE / 802.11aa standard be used as a lightweight mechanism for non-AP stations to notify the AP of their QoS requirements, especially for low latency traffic.

[0087] Low-Latency Reliable Service (LLRS) is a service provided to higher layer traffic streams that prioritizes delivery of MSDUs within a worst-case delay budget with a given reliability / packet delivery ratio (PDR) and low jitter. Traffic that can be subject to LLRS includes delay-sensitive data, i.e., data from applications such as gaming, media streaming, augmented reality, virtual reality, etc.

[0088] Originally, the SCS mechanism allowed for the establishment of traffic streams with higher layer signaling of packet drop eligibility (e.g., allowing some packets within a traffic stream to be tagged as drop eligible), and for the traffic streams to be classified into access categories using the Traffic Classification (TCLAS) process.

[0089] A typical scenario for using SCS is to operate with a local traffic stream, and then the SCS mechanism provides signaling to select some packets (eligible for dropping) within the traffic stream for discarding in case of insufficient channel capacity. In essence, the SCS mechanism aims to distinguish between distinct traffic streams within the same access category or the same TID, covering the need to allow graceful gradation of traffic streams in case of bandwidth shortage.

[0090] The SCS mechanism has been adapted to the ML context: As specified in the D1.5 standard, multilink SCS procedures are currently provided in the context of robust audio-video streaming.

[0091] Similar to IEEE 802.11aa, the multilink SCS procedure provides SCS Request frames and corresponding SCS Response frames to create / add, modify, or delete SCS streams. SCS streams are defined in the SCS Request frame via so-called SCS Descriptors and identified in the SCS Response frame by an SCS Identifier (SCSID).

[0092] Figure 4 shows the SCS descriptors contained in these SCS frames, which include: - SCSID field 420. Each traffic stream is assigned an ID by the affiliated non-AP station requesting classification. This ID, named SCSID 420, is managed at the MLD level and is therefore unique across non-AP MLDs; - The Request Type field 421 takes values ​​to identify the type of SCS request: Add, Delete, Modify; - the optional Intra-Access Category Priority element 422 provides information to the AP MLD about the relative priority of SCS traffic streams within the AC, which corresponds to the optional introduction of two alternative queues proposed by the IEEE 802.11aa standard compared to the four primary queues of EDCA; - The TCLAS element 423 and the TCLAS Processing element 424, if present, describe the criteria for traffic classification that the non-AP MLD requests the AP MLD to apply to identify the data or MSDUs that form the corresponding SCS stream. These elements are mandatory for the downlink direction (traffic from AP MLD to non-AP MLD) but are prohibited in the current standard for the other direction (UL or direct link); - Traffic Specification, called QoS Characteristics element 425. The QoS Characteristics element field 425 contains zero or one QoS characteristics element to describe the traffic characteristics and QoS expectations of the traffic flows belonging to this SCS traffic stream.

[0093] The QoS Characteristics are taken into account by the AP MLD or AP to appropriately schedule non-AP MLDs or non-AP stations for transmitting local SCS streams. As an example, if the Direction subfield of the QoS Characteristics element indicates uplink or direct link, the AP MLD may allow frame transmissions from non-AP MLDs at intervals that fall between the requested minimum and maximum service intervals, and the AP MLD may meet the requested minimum data rate.

[0094] As shown, in the QoS Characteristics element 425, various fields are provided that define various QoS transmission parameters for the local SCS stream.

[0095] The Control Info field 440 in the QoS Characteristics element 425 is defined as follows: The Direction subfield 441 specifies the direction of the data forming the stream: uplink (field set to 0), downlink (1), or direct link (2). The TID subfield 442 contains the target TID value of the MSDUs belonging to the local SCS stream (i.e., as described by the SCS descriptor 400). In practice, this TID can then be used by the AP MLD or the AP for scheduling the SCS stream (e.g., polling for buffer status reports, allocating resources in emitted trigger frames) instead of using the SCSID. The User Priority subfield 443 contains the UP (value 0 to 7) of the data frame described by this element. If a TCLAS element 424 is present in the SCS frame containing this element, the User Priority subfield is set to the value of the user priority specified in the TCLAS element. The LinkID subfield 444 contains the link identifier of the link on which the P2P or direct link transmission is about to take place (and is therefore only taken into account if the Direction subfield 441 specifies a Direct-link).

[0096] Other subfields of the QoS Characteristics element 425, which are not critical to the present invention, represent a set of parameters (e.g., minimum and maximum service interval, minimum data rate, delay bounds) that define the characteristics and QoS expectations of the SCS stream.

[0097] 2, the initiator STA2 creates an SCS stream with the AP 110 using an SCS Request frame 221 that includes the QoS Characteristics element 425 (in the SCS descriptor 400) for its P2P traffic, with the Direction subfield 441 set to Direct link (value 2). At this time, STA2 is in the Active state, while the non-communicating STA4 is in the Doze state. The AP 110 responds with an SCS Response frame 222.

[0098] The SCS mechanism, recently introduced in the EHT standard, maintains a lightweight protocol for a non-AP MLD (or station) to inform an AP MLD (or AP) of its QoS requirements. As already explained, an AP MLD may use any link to carry the SCS stream: any of its affiliated APs can trigger communication of SCS data via the corresponding affiliated STA of the non-AP MLD. In P2P communication, the link used is identified by the LinkID subfield 444.

[0099] SCS streams, especially those used for low latency traffic, are privileged candidates for Restricted Target Wake Time (rTWT), since the creation of an SCS stream (221, 222) can initiate the more general phase (220) associated with setting up an rTWT.

[0100] rTWT is based on the Target Wake Time (TWT) mechanism originally defined in the IEEE / 802.11ah / ax standard, which allows devices to decide when and how often to wake up to transmit and receive data. TWT allows APs to manage activity in the network to minimize medium contention between STAs and reduce the time required for STAs in power save mode to become awake on the link. This mechanism allows STAs in a non-AP STA MLD to doze except during the configured TWT Service Period (SP) interval on this link.

[0101] 802.11be provides TWT with enhanced medium access protection and resource reservation, typically referred to as restricted target wake time (r-TWT or rTWT), within the scope of handling delay-sensitive traffic. An r-TWT agreement is established using the same procedures used to set up a Broadcast TWT agreement (introduced in IEEE Std 802.11ax-2021), except that the TWT setup frame includes a Broadcast TWT element containing a Restricted TWT Parameter Set field, as described below.

[0102] Non-AP stations establish membership in the AP's broadcast TWT schedule, while the AP distributes broadcast TWT parameter sets to non-AP stations. Non-AP stations are called TWT scheduled stations, and the AP is called a TWT scheduling station.

[0103] Negotiation to become a member of an rTWT schedule (or more generally, broadcast TWT) or to terminate membership is performed using an exchange of frames carrying TWT elements as shown below, with the Negotiation Type subfield set to 3 (broadcast TWT): In particular, a non-AP STA MLD may request to become a member of a TWT schedule by sending a TWT Request frame containing the TWT elements for a given rTWT schedule to its associated AP MLD.

[0104] The AP then advertises the scheduled broadcast TWT (or rTWT) using the broadcast TWT element in management frames, typically in beacon frames, FILS discovery frames, and broadcast probe response frames.

[0105] FIG. 5 shows the format of a TWT element 500 adapted for use in an r-TWT according to the D1.5 standard.

[0106] The TWT element 500 is identified by an Element ID 501 and includes a "Control" field 510 and a field 520 for carrying TWT parameter information.

[0107] The "Control" field 510 allows to signal whether the TWT is a Broadcast TWT or an individual TWT agreement through the "Negotiation Type" field 511. The MSB of the Negotiation Type subfield 511 is the Broadcast field, therefore, if the MSB of field 511 is 1, the TWT element 500 is called a Broadcast TWT element.

[0108] The "TWT Parameter Information" field 520 contains a single "Individual TWT Parameter Set" field in the case of an individual TWT (not shown), and in the case of a broadcast TWT (when the Broadcast field in the "Negotiation Type" subfield is 1), it contains one or more "Broadcast TWT Parameter Set" fields having the format 520a shown in the figure.

[0109] The first field in the "Broadcast TWT Parameter Set" field 270a is the Request Type field 530, which contains: - If issued by a TWT scheduled STA, the TWT Request subfield 531 is set to 1. Otherwise, it is set to 0 by the TWT scheduling STA (AP); - a TWT Setup Command subfield 532 indicating the type of TWT command: Request, Suggest, Demand, Reject when issued by a non-AP STA, and Accept, Alternate, Dictate, Reject when issued by a TWT scheduling AP; a Trigger field 533 for indicating whether the TWT SP indicated by the TWT element 500 contains a trigger frame (the Trigger subfield is equal to 1 for trigger enabled in the case of r-TWT). Such a TWT SP is named a trigger-enabled TWT SP, and a non-AP station cannot start data transmission therein without a prior trigger by the AP; The Broadcast TWT Recommendation field 536 is set to 4 to indicate that the TWT described in the Broadcast TWT element 500 is a restricted TWT (r-TWT). In that case, the Broadcast TWT element 500 is also called a restricted TWT element (r-TWT IE), and the Broadcast TWT Parameter Set 520a is also called a Restricted TWT Parameter Set. -The other subfields are less important: The Last Broadcast Parameter Set subfield 534 is set to 0 to indicate that this set is followed by another Broadcast TWT Parameter Set. The Last Broadcast Parameter Set subfield is set to 1 to indicate that this is the last Broadcast TWT Parameter set for the Broadcast TWT element. · The Flow Type subfield 535 indicates whether the TWT is announced (the TWT scheduling AP waits for the TWT scheduled STA to receive a frame to signal its awake state) or not (the Flow Type subfield is equal to 0 for r-TWT due to the "announced" mode, since r-TWT is a trigger-enabled TWT).

[0110] Other fields in the Restricted TWT Parameter Set field 520a are used to define the time parameters of the rTWT schedule, as follows: - Target Wait Time (TWT) field 540 indicates the next time (in microseconds) that stations participating in the rTWT schedule should wake up for the next rTWT SP; The Nominal Minimum TWT Wake Duration field 550 indicates the minimum time a TWT scheduled STA is expected to be awake after the start time of the TWT SP to complete a frame exchange during the TWT Wake Interval. The TWT Wake Interval of an rTWT SP is a value calculated from the TWT Wake Interval Mantissa 560 and the TWT Wake Interval Exponent 537. It is expressed in units defined in the Wake Duration Unit subfield 512 of the Control field 510, e.g., typically 256 μs.

[0111] Other fields in the Restricted TWT Parameter Set field 520a are used to define parameters specific to the broadcast and restricted nature of the rTWT SP: -Broadcast TWT information field 570. It carries the identifier of the rTWT schedule, i.e., the Broadcast TWT ID 573 (bTWT ID) used to identify rTWT SPs belonging to the same rTWT schedule. This non-zero identifier allows the AP to schedule multiple broadcast TWT SPs with different sets of TWT parameters; · It specifies, through the Broadcast TWT Persistence subfield 574, the number of Target Beacon Transmission Times (TBTTs) for which there are Broadcast TWT SPs corresponding to this Restricted (or more generally Broadcast) TWT Parameter set; · It also signals, when set to 1, through the Restricted TWT Schedule Full subfield 572, that the r-TWT scheduling AP is unlikely to accept requests from STAs in the BSS to establish new membership in the corresponding schedule (identified by bTWT ID 573); Finally, the Restricted TWT Traffic Info Present field 571 also signals whether the Restricted TWT Traffic Info field 580 is present (field 571 set to 1). -Restricted TWT Traffic Info field 580 specific to restricting Broadcast TWT to certain traffic. This field is mandatory (thus field 571 is forced to be set to 1) if the Broadcast TWT is related to an SCS LL stream (otherwise Traffic Info is related to a TID). · It includes a Traffic Info Control field 591 that indicates whether the subsequent fields 582 and 583 are provided (i.e., "valid"). The DL TID Bitmap Valid subfield 5811 (respectively, the UL TID Bitmap Valid subfield 5812) indicates whether the Restricted TWT DL TID Bitmap field 582 (respectively, the Restricted TWT UL TID Bitmap field 583) has valid information. The Restricted TWT DL TID Bitmap field 582 (respectively, Restricted TWT UL TID Bitmap field 583) identifies TIDs that are delay-sensitive traffic in the DL (respectively, UL) direction, i.e., TIDs that are allowed in the rTWT defined by the Restricted TWT element 500. The TIDs may define SCS streams. A value of 1 in bit position k of the bitmap indicates that TID k is classified as a delay-sensitive traffic stream for that transmission direction.

[0112] The TWT SP for the rTWT schedule is:<bTWT ID、TWTスケジューリングAPのMACアドレス> Uniquely identified by a tuple.

[0113] In the exemplary sequence of FIG. 2, initiator STA2 requests AP 110 to become an r-TWT scheduled STA by negotiating an r-TWT SP (TWT Request frame 223) for low-latency traffic, to which P2P traffic belongs, with STA4. For example, initiator STA2 may negotiate the wake TBTT, wake interval, and SCS streams to be allowed in rTWT. AP 110 provides a TWT Response frame 224 accepting or rejecting the request. In other words, STA2 requests membership in the rTWT schedule.

[0114] The TWT Request frame 223 carries a TWT element with the Negotiation Type subfield 511 set to 3 and the TWT Setup Command field 532 set to Request TWT, Suggest TWT, or Demand TWT. The Restricted TWT Parameter set 520a indicates the Broadcast TWT ID 573 of the rTWT schedule the STA is requesting to join. The AP may either not provide a new rTWT schedule for the bTWT ID (keep the existing one), provide an alternative set of parameters indicated in the TWT Request frame 223, or create and respond with a new rTWT schedule with the new bTWT ID (TWT Response frame 224).

[0115] Once negotiation and membership are complete, the rTWT-scheduled STA2 in the awake state may enter the doze state and return to the awake state at the rTWT start time after receiving a Beacon frame with a Restricted TWT element indicating the existence of an rTWT schedule, advertising the rTWT SP (e.g., via the beacon frame 230). The beacon frame indicates the rTWT SP to which the TWT scheduling AP intends to send a trigger frame or DL ​​BU to the TWT-scheduled STA.

[0116] As a result, both STA2 and STA4 receive the beacon frame 230, but only STA2, which negotiated (and is a member of) the rTWT schedule, decodes such periods of activity. Only STA2 is awake during the rTWT SP 240.

[0117] Because the TWT scheduling AP may be in doze mode just before the start of an rTWT SP, it is often recommended that the TWT scheduling AP receive an indication that the TWT-scheduled STA is awake (see Flow Type subfield 535) within that rTWT SP. Specific procedures are performed based on a trigger frame sent by the TWT scheduling AP. Therefore, the TWT scheduling AP 110 ensures that a trigger frame 241 (e.g., a PS-Poll trigger frame) is scheduled at the start of an rTWT SP 240, and in response, the TWT-scheduled station (STA2 here) can advertise its awake state (e.g., a PS-Poll frame 242). The TWT scheduling AP 110 can block acknowledge (243) the PS-Poll frame 242 for multiple TWT-scheduled stations.

[0118] Being aware of the awake TWT scheduled stations, the TWT scheduling AP 110 manages the rTWT SP using OFDMA multi-user techniques (e.g., MU UL triggered transmission, MU DL transmission) and, in some cases, provides resource units to all or some of the awake TWT scheduled stations.

[0119] As an example, within such a triggered rTWT SP, a Triggered TXOP Sharing (TXS) mechanism may be used, transmitting an MU RTS TXS trigger frame 244 to allocate a portion of the time within the TXOP (obtained through the trigger frame) to one of the awake TWT scheduled stations, here STA2, for transmitting data.

[0120] The Allocation Duration subfield of the MU-RTS TXS trigger frame 244 indicates the time duration allocated to STA2 within the TXOP acquired by the TWT scheduling AP 110 in the rTWT SP 240. There is only one User Info field, addressed to STA2 (i.e., in this example, the AID12 subfield is set to a value between 1 and 2006, corresponding to the AID of STA2). Specific information within the MU-RTS TXS trigger frame 244 is the TXOP Sharing Mode subfield, which is set to 2 to indicate P2P data may be transmitted. Thus, the rTWT mechanism allows P2P transmissions to occur within rTWT SPs triggered using the TXS mechanism.

[0121] If, in response to the transmitted MU-RTS TXS trigger frame 244, STA2 transmits one or more non-TB PPDUs within the time allocation signaled in the MU-RTS TXS trigger frame, the first PPDU of the exchange transmitted by STA2 is a CTS frame 245.

[0122] During the time allocated by the TWT scheduling AP 110, the TWT scheduled STA2 can transmit a non-TB PPDU 246 to the AP (not shown) or another STA (typically STA4 for P2P traffic) if the TXOP Sharing Mode subfield value is 2.

[0123] Unfortunately, as shown by state band 202, STA4, which is not a member of the rTWT schedule negotiated by its partner peer STA, has no need (by its own knowledge) to stay awake during that period, and is therefore in a doze state and unable to receive P2P data from STA2.

[0124] P2P data is still transferred, but it takes time and the session ends after a timeout (due to lack of acknowledgment).

[0125] Furthermore, since this time resource is scarce (low latency streams), the time used for these lost data is detrimental to other stations participating in the rTWT SP240.

[0126] As a result, P2P traffic at non-AP stations continually requests resource allocation in the rTWT schedule, which is never beneficial to itself (missing peers) and is no longer beneficial to other AP operations.

[0127] The example scenario in Figure 2 shows that the SCS, TDLS, rTWT, and TXS mechanisms can work in combination. These mechanisms allow for clearly identifying delay-sensitive streams (SCS) and reserving the entire channel (TXS) with a dedicated transmission window (rTWT). However, the resulting overall mechanism is still insufficient to properly handle P2P (or DiL) delay-sensitive streams.

[0128] It is desired to efficiently inform a BSS partner peer non-AP station (STA4 in this scenario) of the rTWT schedule in which the initiator peer non-AP station (STA2) established membership with the BSS AP, of course, so that the partner peer STA4 is awake to the upcoming service periods in this rTWT schedule and therefore available for P2P communication with the initiator peer STA2.

[0129] An embodiment of the present invention is based on using an action frame specific to the TDLS mechanism to provide such notification. In other words, a TDLS action frame is sent to the partner peer STA4, and this frame includes rTWT information regarding the rTWT schedule to which the initiator peer STA2 has membership. By including a broadcast TWT identifier (bTWT ID) that identifies the rTWT schedule and therefore its service period (SP), the rTWT information enables the partner peer STA4 to obtain, for example, rTWT timing parameters for the SP from management frames (e.g., beacon frames 230) transmitted by the AP. Thus, the partner peer STA4 can wake up at the appropriate time to receive (or exchange) P2P data 246 with the initiator STA2 within the rTWT SP 240.

[0130] FIG. 6 illustrates, by way of a flow chart, exemplary steps in a peer non-AP MLD (or station) according to some embodiments of the present invention.

[0131] The peer MLD is associated with the AP MLD and therefore belongs to the same BSS before the process begins. The left side of the figure represents the steps for the initiator's peer non-AP station, and the right side represents the steps for the partner's peer non-AP station.

[0132] For purposes of illustration, STA2 may take on the role of the initiator's peer STA, in other words, the role of the TDLS initiator STA, and STA4 may take on the role of the partner's peer STA, in other words, the role of the TDLS responder STA.

[0133] In an embodiment (described below), the TDLS initiator STA also acts as a TWT scheduled STA with the TWT scheduling AP. Alternatively, the TDLS responder STA may act as a scheduled STA that negotiates an rTWT schedule with the TWT scheduling AP.

[0134] In step 610, a P2P session is established between two peer stations at the initiative of one of the peer stations. This step corresponds to phase 210 in Figure 2 above. Correspondingly, the other peer station also establishes a P2P session in step 650.

[0135] Next, in step 620, an rTWT agreement is established, including a request for membership in the rTWT schedule and the negotiation of a corresponding Restricted TWT Parameter Set. This step corresponds to phase 220 in Figure 2 above. As a result, the initiator STA2 obtains an rTWT (broadcast TWT) schedule identified by the bTWT ID.

[0136] Next, in step 630, the initiator peer station (STA2) forwards at least the bTWT ID to the partner peer station, i.e., the TDLS responder station STA4, using a TDLS action frame associated with the established TDLS session (i.e., conveying the TDLS identifier "Link Identifier" that identifies the TDLS session).

[0137] In some embodiments, the TDLS action frame includes a TDLS category action frame (meaning a TDLS action frame) with a TDLS Action field of TDLS Peer Traffic Indication, which corresponds to the existing format of the TDLS Action field 302 set to 4, as shown in Table 9-496 of FIG.

[0138] In this variant, the TDLS action frame includes a TDLS category action frame (meaning a TLDS action frame) with the TDLS Action field of TDLS Peer PSM Request / Response, which corresponds to the existing format of the TDLS Action field 302 set to 7 and 8, respectively, as shown in Table 9-496 in Figure 3. This variant requires that a TDLS session is already established.

[0139] TDLS Peer Power Save Mode (TDLS Peer PSM) is a power saving mechanism that can be used between TDLS peer STAs and is based on a periodic wake-up schedule. A station (TDLS Peer PSM Initiator) attempting to enter TDLS Peer PSM sends a TDLS Peer PSM Request frame containing a proposed periodic wake-up schedule to the TDLS peer STA (TDLS Peer PSM Responder). If the TDLS Peer PSM Responder accepts the proposed wake-up schedule, it responds with a TDLS Peer PSM Response frame indicating the status code SUCCESS.

[0140] In one example, when a partner peer STA4 requests a periodic wake-up schedule with an initiator peer STA2 (i.e., in its TDLS Peer PSM Request), the latter (STA2) may include rTWT information (i.e., a broadcast TWT ID element, bTWT ID) regarding the rTWT schedule in its response to the requested schedule (i.e., in its TDLS Peer PSM Response).

[0141] In another example, the initiator's peer STA2 may include rTWT information (i.e., bTWT ID) regarding the rTWT schedule in the TDLS Peer PSM Request, and the wake-up schedule is established based on the Broadcast TWT ID element (bTWT ID) of the TDLS direct link when the TDLS Peer PSM Response frame indicates the status code SUCCESS. Preferably, the rTWT information indicating the wake-up schedule is present in the response when the status code is set to TDLS_REJECTED_ALTERNATIVE_PROVIDED, and is absent otherwise. Figure 12e shows the addition of such a Broadcast TWT ID element in a TDLS Peer PSM Request action frame.

[0142] In another example (not shown in the figure), either STA may update an existing wake-up schedule by initiating a TDLS Peer PSM Request / Response exchange, in which case the rTWT information (i.e., bTWT ID) related to the rTWT schedule is present in the TDLS Peer PSM Request. Figure 12f shows the addition of a Broadcast TWT ID element in the TDLS Peer PSM Response action frame.

[0143] In yet another variant, a new type of TDLS action frame may be defined, in this case including an action frame of the TDLS category with the TDLS Action field 302 set to any value between 11 and 255, to define the TDLS Peer rTWT Indication. The function of this newly defined frame (TDLS Peer rTWT Indication) is simply to signal the bTWT ID according to the present invention, and more generally, the rTWT schedule.

[0144] These TDLS action frames include, as part of the Elements field 303, a Category field 301 (set to 12) and a TDLS Action field 302, as well as a Dialog token subfield used to match an action response with an action request when multiple action requests exist simultaneously, and a Link identifier (i.e., TDLS session identifier) ​​subfield. As shown in Figure 3, the Elements field 303 of the TDLS Peer Traffic Indication frame further includes an optional PTI Control subfield to identify the latest MPDU sent to the destination TPU (TDLS Peer U-APSD) sleeping STA, and a TPU Buffer Status subfield indicating the status of the AC buffers in the TPU buffer STA (one bit for each of the four ACs indicates whether the station has buffered traffic for this category, i.e., BK, BE, VI, and VO).

[0145] According to an embodiment, the Elements field 303 of the TDLS action frame is supplemented with an additional subfield that carries the advertised Broadcast TWT ID element (bTWT ID).

[0146] In some embodiments, the rTWT information includes only the bTWT ID, thus reducing overhead while providing simplicity for signaling the rTWT SP. This corresponds to adding a 5-bit subfield 573 in the Elements field 303, as shown by reference numeral 303a in Figure 3. Various views of the modified TDLS action field are provided throughout Figures 12a through 12e.

[0147] In a variant, the rTWT information includes more rTWT information, for example, includes or consists of a Broadcast TWT Info subfield containing the bTWT ID. Thus, the partner peer can learn some timing information about the rTWT SPs of the rTWT schedule from the notification. This configuration corresponds to providing a Broadcast TWT Info subfield 570 in the Elements field 303, as shown by reference numeral 303b in Figure 3.

[0148] In another variant, the rTWT information may include more rTWT information, such as a Restricted (Broadcast) TWT Parameter Set subfield (and even a Broadcast TWT Info subfield) containing the bTWT ID. Thus, the partner peer can learn complete information about the rTWT SP of the rTWT schedule, including the negotiated interval, from the notification. This configuration corresponds to providing a Restricted TWT Parameter Set subfield 520a in the Elements field 303, as indicated by reference numeral 303c in FIG. 3. In this variant, some of the information in the Request Type field 530, such as the TWT Request subfield 531 indicating the type of transmitting STA and the TWT Setup Command subfield 532 indicating the type of TWT command, may be less important because these elements are not transmitted in conventional TWT frames. Therefore, they can be omitted. Alternatively, the type of TWT command in the TWT Setup Command subfield 532 may be rejected for other uses, for example, to define additional information underlying another subfield that varies depending on its value. For example: - Within a TWT element 520a containing a TWT Setup Command value 532 of type Request TWT, Suggest TWT, Demand TWT, TWT Grouping, or Dictate TWT, the Broadcast TWT ID subfield 573 indicates the specific Broadcast TWT under negotiation for which the transmitting STA (initiator peer) is providing TWT parameters to its partner peer; Within the TWT element 520a containing a TWT Setup Command value 532 of -Accept TWT, the Broadcast TWT ID subfield 573 indicates the specific broadcast TWT that has been accepted by the AP and for which the sending STA (initiator peer) is providing TWT parameters to its partner peer.

[0149] Preferably, the TWT Request subfield 531 holds the value 1 because the transmitting STA (initiator peer) is not a TWT scheduling STA (not an AP).

[0150] As mentioned above, the Restricted TWT Parameter Set subfield 520a includes bitmaps 582 and 583 for defining the delay-sensitive traffic allowed in the DL and UL directions, respectively, using TIDs. Embodiments of the present invention contemplate providing an additional bitmap in the DiL (i.e., P2P) direction for partner peer stations to know which delay-sensitive traffic is allowed during rTWT.

[0151] In this regard, the Restricted TWT Parameter Set subfield 303c includes a Restricted TWT P2P TID Bitmap subfield that specifies which TID or TIDs are allowed as delay-sensitive traffic streams for peer-to-peer exchange within the rTWT schedule (and therefore the SP), as shown in FIG.

[0152] This figure shows the format of a modified Restricted TWT Traffic Info subfield 780 within the Restricted TWT Parameter Set subfield 520a in accordance with an embodiment of the present invention, which is adapted to restrict the TIDs used for P2P traffic within the rTWT SP of a schedule.

[0153] The Restricted TWT Traffic Info field 780 consists of a Traffic Info Control field 781 that indicates whether the following fields 582, 583, 784 are provided (i.e., "enabled").

[0154] The DL TID Bitmap Valid subfield 5811 and the UL TID Bitmap Valid subfield 5812 maintain the function of indicating whether the Restricted TWT DL TID Bitmap field 582 and the Restricted TWT UL TID Bitmap field 583 respectively contain valid information.

[0155] The P2P TID Bitmap Valid subfield 7814 indicates whether there is valid information in the Restricted TWT P2P TID Bitmap field 784. These fields are preferably used (set as valid) only if the Direction subfield 441 (FIG. 4) of the QoS Characteristics element 425 that describes the traffic flow intended to benefit from the rTWT schedule specifies the Direct-link (2) Direction.

[0156] The Restricted TWT P2P TID Bitmap subfield 784 specifies which TIDs are identified as P2P delay-sensitive traffic streams by the TWT scheduling AP (e.g., under the proposal of a TDLS initiator STA acting as a TWT scheduled STA).

[0157] A value of 1 in bit position k of the bitmap indicates that TID k is classified as a P2P delay-sensitive traffic stream. A value of 0 in bit position k of the bitmap indicates that TID k is not classified as a P2P delay-sensitive traffic stream. Therefore, traffic belonging to a TID with a 0 in the bitmap bit position is not allowed to be transmitted on the rTWT SP of this rTWT schedule. The initiator peer and partner peer of a TDLS session will prioritize the transmission of P2P QoS data frames, which are delay-sensitive traffic.

[0158] If the TPU Buffer Status subfield is present in the TDLS action frame to indicate the traffic buffered at the initiator peer at the time the TDLS action frame was sent (e.g., this is the case for a TDLS Peer Traffic Indication frame), only the buffered traffic corresponding to the TID or TIDs specified in the Restricted TWT P2P TID Bitmap subfield 784 may be reported in the TPU Buffer Status field. In other words, the TPU Buffer Status subfield follows the Restricted TWT P2P TID Bitmap 784. That is, if none of the corresponding TIDs are classified as a P2P delay-sensitive traffic stream in the bitmap 784, the ACs containing the buffered traffic are not reported.

[0159] 6, corresponding to step 630, STA4 receives the bTWT ID in step 660. Thus, STA4 can now identify the rTWT SP of the rTWT schedule advertised in the management frame transmitted by the AP.

[0160] Both peer stations can then conventionally receive a management frame (e.g., beacon frame 230 in FIG. 2) from the AP and awaken at the start of the rTWT SP identified by the bTWT ID. These steps are not shown in the figure for clarity.

[0161] Finally, during a given rTWT SP corresponding to the advertised rTWT schedule, both TDLS peer stations can exchange P2P data (steps 640 and 670). These steps correspond to phase 240 of Figure 2, but now, because both peer stations are in the awake state of the rTWT SP, they are slightly modified as described below with reference to Figure 8 to correctly transfer P2P data.

[0162] If both peer stations have performed step 620, i.e., if they have both established membership of their respective rTWT schedules with the AP, then only one rTWT schedule may be considered for P2P transmission. In that case, only one of the two peer stations performs step 630, while the other performs the corresponding step 660. Any criteria may be implemented to determine which rTWT schedule is retained, such as the first exchanged notification TDLS action frame (with a bTWT ID) being retained, or the peer station with the larger AID value winning.

[0163] Also, a peer station may simultaneously be involved in direct links with multiple other partner peers, and as a result, multiple rTWT agreements (membership in rTWT schedules) may be requested by a TDLS peer STA (or one rTWT schedule may be used to carry multiple TDLS sessions).

[0164] Figure 8 illustrates the scenario of Figure 2 using a timeline frame exchange when an initiator peer notifies its partner peer of an rTWT schedule for a P2P low-latency traffic stream according to an embodiment of the present invention. The same references as in Figure 2 correspond to the same phases / steps / frames / entities.

[0165] 2, before establishing membership in the rTWT schedule for P2P, the initiator peer non-AP station (STA2) negotiates a Tunneled Direct Link Setup (TDLS) session with the partner peer non-AP station (STA4) (phase 210) (TDLS discovery (not shown) and setup), as described above. Of course, in a variant, STA4 may initiate the TDLS session.

[0166] Also, similar to FIG. 2, the initiator peer STA2 sets up an rTWT schedule with the scheduling AP 110 (phase 220) as described above (SCS P2P stream definition (221-222), rTWT negotiation and its membership establishment (223-224).

[0167] 2, once rTWT schedule membership is established, the initiator STA2 notifies the partner STA2 of the rTWT schedule, typically by specifying the corresponding bTWT ID in a TDLS action frame 800. This TDLS action frame is sent at an opportunity to transmit within the established TDLS session (thus, when both peer stations are simultaneously active, as indicated by status bands 201 and 202). This can take any format, as specified above with respect to step 630.

[0168] The TDLS action frame 800 is preferably transmitted directly to the STA 4 without relaying (forwarding) by the AP, although other transmission paths including relaying by the AP may also be considered as alternatives.

[0169] The TWT scheduling AP includes a broadcast TWT element in the Beacon frame 230 indicating the rTWT schedule in which the AP intends to allocate resources to STA2 (for which STA2 has established membership). Both peer stations receive the Beacon frame 230.

[0170] Here, as shown in state strip 202, partner peer STA4 wakes up at the start of rTWT SP 840 corresponding to the bTWT ID.

[0171] In the illustrated scenario, the TWT scheduling AP 110 still sends a PS-Poll trigger frame 241 to confirm that the initiator's peer STA2 is awake (a PS-Poll frame 242 in response). The TWT scheduling AP 110 can block acknowledge (243) the PS-Poll frame 242 to multiple TWT scheduled stations.

[0172] The TWT scheduling AP 110 then sends an MU RTS TXS trigger frame 244 to allocate a portion of the time in the TXOP to the initiator's peer STA2, which is acknowledged in response by the initiator's peer STA2 sending a CTS frame 245.

[0173] Thereafter, since the partner peer STA4 is present to exchange data with the initiator peer STA2, the initiator peer STA2 can send its P2P data 801 directly to the partner peer STA4, which responds by performing an acknowledgement 802 (and optionally sending data).

[0174] 9 illustrates, using a flowchart, exemplary steps in a peer non-AP MLD (or station) according to an alternative embodiment of FIG. 6. In these embodiments, establishing membership in the rTWT schedule occurs before establishing a TDLS session, and advertising the bTWT ID occurs during TDLS session establishment. In some embodiments, advertising a TDLS action frame includes a TDLS Setup Request action frame for establishing a Tunneled Direct Link Setup (TDLS) session between two peer non-AP stations.

[0175] Again, peer non-AP stations are assumed to be associated with an AP.

[0176] In step 910, the initiator's peer STA2 establishes membership in the rTWT schedule with the AP 110. This step corresponds to phase 220 in Figure 2 and is similar to step 620 described above. As a result, the initiator STA2 obtains an rTWT (broadcast TWT) schedule identified by the bTWT ID.

[0177] Next, in step 920, the initiator peer STA2 initiates the establishment of a TDLS session with the partner peer STA4. Specific to these embodiments, the TDLS Setup Request action frame includes the negotiated bTWT ID to inform STA4 (substep 925). To do so, the TDLS Setup Request action frame is supplemented to include any of fields 303a, 303b, or 303c described above.

[0178] In response, STA4 establishes a TDLS session with the initiator peer STA2 (step 950), during which it receives a TDLS Setup Request action frame containing the bTWT ID in step 660. STA4 can therefore now identify the rTWT SP advertised in the management frame sent by the AP.

[0179] Both peer stations can then conventionally receive management frames (such as beacon frame 230 in FIG. 2) from the AP and become awake at the start of the rTWT SP identified by the bTWT ID. These steps are not shown in the figure for clarity.

[0180] Finally, during a given rTWT SP corresponding to the advertised rTWT, both TDLS peer stations can exchange P2P data (steps 930 and 960, similar to steps 640 and 670). These steps correspond to phase 840.

[0181] FIG. 10 illustrates an alternative scenario to FIG. 8 in which the establishment of rTWT membership precedes the establishment of a P2P session using frame exchanges in a timeline.

[0182] Similar to Figures 2 and 8, the initiator peer STA2 sets up an rTWT schedule with the scheduling AP110 (phase 220) as described above (defining the SCS P2P stream (221-222), negotiating rTWT and establishing membership (223-224)).

[0183] When the initiator peer STA2 wants to establish a TDLS session with its partner peer STA4 (phase 1010), the initiator peer issues a TDLS Setup Request frame 1011 containing the negotiated bTWT ID (more generally, any field 303a, 303b or 303c), followed by a TDLS Setup Response 1012 from the partner peer STA4 and a TDLS Setup Confirm frame 1013 from the initiator peer STA2.

[0184] The TDLS Setup Response 1012 may also carry the negotiated bTWT ID (or more generally, any field 303a, 303b, or 303c).

[0185] The TDLS Setup Confirm frame 1013 may also carry the negotiated bTWT ID (more generally, any field 303a, 303b or 303c).

[0186] If the bTWT ID provided in the TDLS Setup Request frame 1011 does not match the bTWT ID provided in the TDLS Setup Response frame 1012, the initiator's peer STA2 may silently discard the received TDLS Setup Response frame 1012.

[0187] In other words, an rTWT schedule can be successfully considered by both the initiator station and the partner station if its bTWT ID is indicated in both the TDLS Setup Request frame 1011 and the TDLS Setup Response frame 1012 and confirmed in the TDLS Setup Confirm frame 1013.

[0188] The TWT scheduling AP includes a broadcast TWT element in the Beacon frame 230 indicating the negotiated rTWT schedule (for which STA2 has established membership) in which the AP intends to allocate resources to STA2. Both peer stations receive the Beacon frame 230.

[0189] Similar to FIG. 8, and as shown in status band 202, partner peer STA4 now wakes up at the start of rTWT SP 840 corresponding to the bTWT ID.

[0190] In this scenario, the TWT scheduling AP 110 also transmits a PS-Poll trigger frame 241 to confirm that the initiator's peer STA2 is awake (a PS-Poll frame 242 in response). The TWT scheduling AP 110 can block acknowledge (243) the PS-Poll frame 242 to multiple TWT scheduled stations.

[0191] The TWT scheduling AP 110 then sends an MU RTS TXS trigger frame 244 to allocate a portion of the time in the TXOP to the initiator's peer STA2, which is acknowledged in response by the initiator's peer STA2 sending a CTS frame 245.

[0192] Thereafter, since partner peer STA4 is now present to exchange data with initiator peer STA2, initiator peer STA2 can send P2P data 801 directly to partner peer STA4, which responds by performing an acknowledgement 802.

[0193] The above embodiments (FIGS. 6-10) describe how to efficiently set up an rTWT schedule for P2P transmissions between two peer stations having a P2P session. Because the AP performs admission control for TWT and SCS mechanisms, especially as they relate to P2P traffic, it may also configure policies in the BSS such that a peer station closes the P2P (TDLS) session if the AP rejects a TWT or SCS agreement with either of the two peer stations.

[0194] 11a shows a schematic diagram of a communication device 1100 that is either a non-AP MLD incorporating multiple non-AP stations 110 or an AP MLD incorporating multiple APs 100 of a wireless network NETW configured to implement at least one embodiment of the present invention. The communication device 1100 may preferably be a device such as a microcomputer, a workstation or a lightweight handheld device. The communication device 1100 preferably includes: a central processing unit 1101 such as a processor, denoted as CPU; a memory 1103 for storing executable code of a method or method steps according to an embodiment of the invention, and registers adapted to record variables and parameters necessary for the execution of the method; and at least one communication interface 1102 connected via a transmitting and receiving antenna 1104 to a wireless communication network, for example a communication network according to one of the standards of the IEEE 802.11 family; The device has a communication bus 1113 to which the devices are connected.

[0195] Preferably, a communication bus provides communication and interoperability between various elements included in or connected to communication device 1100. The representation of a bus is not limiting, and in particular a central processing unit is operable to communicate instructions to any element of communication device 1100 directly or with another element of communication device 1100.

[0196] The executable code may be stored in a memory that may be either read-only, a hard disk, or a removable digital medium such as a disk. According to an optional variant, the executable code of the program may be received by the communication network via the interface 1102 so as to be stored in the memory of the communication device 1100 before being executed.

[0197] In an embodiment, the device is a programmable device that uses software to implement embodiments of the invention, however, embodiments of the invention may alternatively be implemented in whole or in part in hardware (e.g., in the form of an application specific integrated circuit (ASIC)).

[0198] 11b is a block diagram that schematically illustrates the architecture of a communications device 1100 adapted to at least partially implement the present invention. As shown, the device 1100 is comprised of a physical (PHY) layer block 1123, a MAC layer block 1122, and an application layer block 1121.

[0199] The PHY layer block 1123 (here, multiple 802.11 standardized PHY layer modules) has the task of formatting, modulating, or demodulating 20 MHz channels or composite channels and transmitting and receiving frames such as 802.11 frames on the wireless medium NETW, such as medium access trigger frames for reserving transmission slots, MAC data and management frames based on a 20 MHz width for interacting with legacy 802.11 stations, and OFDMA-type MAC data frames with a width smaller than the legacy 20 MHz (typically 2 MHz or 5 MHz).

[0200] The MAC layer block or controller 1122 preferably includes an MLE MAC 802.11 layer 1124 that implements conventional 802.11 MAC operations, and additional blocks 1125 for at least partially implementing embodiments of the present invention. The MAC layer block 1122 may optionally be implemented in software that is loaded into RAM 1103 and executed by CPU 1101. The MLE MAC 802.11 layer 1124 may implement an upper MAC stack with a series of lower MAC modules.

[0201] Preferably, an additional block 1125 called P2P management module for performing low latency service of P2P streams over multi-link communication (in peer non-AP MLD) performs part of the embodiment of the present invention. This block performs the operations of Figures 6 to 10 depending on the role of the communication device 1100, initiator or partner peer.

[0202] The MAC 802.11 layer 1124 and P2P management 1125 interact with each other to establish and handle accurate communications over OFDMA RUs among multiple non-AP MLD stations in accordance with an embodiment of the present invention.

[0203] In the top of Fig. 11b, the application layer block 1121 executes applications that generate and receive data packets, e.g., video streams. The application layer block 1121 represents all stack layers above the MAC layer, according to ISO standardization.

[0204] FIG. 12a is a diagram illustrating a modification of Table 9-494 (per 802.11be draft version 3.0) describing the format of the TDLS Setup Request Action field according to an embodiment of the present invention.

[0205] A new entry is provided (last assigned row number + 3) to support the Broadcast TWT ID field. The Broadcast TWT ID element indicates a specific Broadcast TWT that is accepted by the TWT scheduling AP and for which the sending STA (TDLS initiator STA acting as a TWT scheduled STA) provides the TWT parameters to its partner TDLS responder STA.

[0206] FIG. 12b shows a modification of Table 9-495 (according to the 802.11be draft version 3.0) describing the format of the TDLS Setup Response Action field according to an embodiment of the present invention.

[0207] A new entry is provided (last allocated row number + 3) to support the Broadcast TWT ID field. The Broadcast TWT ID element is present if a Broadcast TWT ID element is present in the TDLS Setup Request frame that elicited this TDLS Setup Response frame.

[0208] The Broadcast TWT ID element indicates the specific Broadcast TWT that was accepted by the TWT scheduling AP and for which the receiving STA (TDLS initiator peer acting as a TWT scheduled STA) provided TWT parameters to the partner TDLS responder STA sending this TDLS Setup Response frame. Otherwise, the Broadcast TWT ID element is not present.

[0209] FIG. 12c is a diagram illustrating a modification of Table 9-496 (as 802.11be draft version 3.0) describing the format of the TDLS Setup Confirm Action field according to an embodiment of the present invention.

[0210] A new entry is provided (last assigned row number + 3) to support the Broadcast TWT ID field. The Broadcast TWT ID indicates a specific Broadcast TWT that the TWT scheduling AP accepts and the sending STA (TDLS initiator STA acting as a TWT scheduled STA) provides the TWT parameters to its partner TDLS responder STA.

[0211] FIG. 12d is a diagram illustrating a modification of Table 9-501 (as 802.11be draft version 3.0) describing the format of the TDLS Peer Traffic Indication Action field according to an embodiment of the present invention.

[0212] A new entry is provided (last assigned row number +1) to support the Broadcast TWT ID field. The Broadcast TWT ID element is defined in 9.4.2.199 (TWT element) of IEEE P802.11-REVme™ / D1.0, December 2021. If present, the Broadcast TWT ID element indicates the specific Broadcast TWT that the sending STA requests the receiving STA to join.

[0213] By including a Broadcast TWT ID that identifies the rTWT schedule and therefore its Service Period (SP), the TDLS Peer Traffic Indication action frame enables the receiving TDLS peer STA to obtain, for example, the rTWT timing parameters for the SP from the management frame sent by the TWT scheduling AP. Thus, the receiving TDLS peer STA can wake up at the appropriate time to receive (or exchange) data with the TWT scheduled STA (TDLS peer STA) within the rTWT SP.

[0214] FIG. 12e is a diagram illustrating a modification of Table 9-505 (as 802.11be draft version 3.0) describing the format of the TDLS Peer PSM Request Action field according to an embodiment of the present invention.

[0215] A new entry is provided (last assigned row number +1) to support the Broadcast TWT ID field. The Broadcast TWT ID element is defined in 9.4.2.199 (TWT element) of IEEE P802.11-REVme™ / D1.0, December 2021.

[0216] The TDLS peer STA may include a Broadcast TWT ID in the TDLS Peer PSM Request, and if the TDLS Peer PSM Response frame indicates a status code of SUCCESS, a wake-up schedule is established based on the Broadcast TWT ID of the TDLS direct link. Preferably, the Broadcast TWT ID indicating the wake-up schedule is present in the response if the status code is set to TDLS_REJECTED_ALTERNATIVE_PROVIDED, and is not present otherwise.

[0217] FIG. 12f is a diagram illustrating a modification of Table 9-506 (as 802.11be draft version 3.0) describing the format of the TDLS Peer PSM Response Action field according to an embodiment of the present invention.

[0218] A new entry is provided (last assigned row number +1) to support the Broadcast TWT ID field. The Broadcast TWT ID element is defined in 9.4.2.199 (TWT element) of IEEE P802.11-REVme™ / D1.0, December 2021.

[0219] The TDLS peer STA may include the Broadcast TWT ID in the TDLS Peer PSM Request, and if the TDLS Peer PSM Response frame indicates the status code SUCCESS, a wake-up schedule is established based on the Broadcast TWT ID of the TDLS direct link.

[0220] Although the present invention has been described with reference to particular embodiments, it is not limited to those embodiments, and modifications within the scope of the invention will be apparent to those skilled in the art.

[0221] Many further modifications and variations will be suggested to those skilled in the art by reference to the foregoing exemplary embodiments, which are given by way of example only and are not intended to limit the scope of the invention, which is determined solely by the appended claims. In particular, different features from different embodiments may be interchanged where appropriate.

[0222] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite articles "a" or "an" do not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be used to advantage.

Claims

1. 1. A method for communicating in a wireless network, comprising: transmitting an action frame used for Tunneled Direct Link Setup (TDLS) from a peer non-Access Point (AP) station that is a member of a Broadcast Target Wake Time (TWT) schedule to another non-AP station, the action frame including a Broadcast TWT ID; exchanging peer-to-peer data directly with the other peer non-AP stations during a TWT service period (SP) corresponding to a broadcast TWT schedule identified based on the broadcast TWT ID; A method comprising:

2. 1. A method of communication in a wireless network, comprising: receiving an action frame used for Tunneled Direct Link Setup (TDLS) from another peer non-AP station that is a member of a broadcast target wake time (TWT) schedule, the action frame including a broadcast TWT ID; exchanging peer-to-peer data directly with the other peer non-AP stations during a TWT service period (SP) corresponding to a broadcast TWT schedule identified based on the broadcast TWT ID; A method comprising:

3. The method according to claim 1 or 2, wherein the action frame includes a Broadcast TWT Info field that includes the Broadcast TWT ID subfield.

4. The method of claim 1 or 2, wherein the action frame includes a Restricted TWT Parameter Set subfield that includes the Broadcast TWT ID subfield.

5. 5. The method of claim 4, wherein the Restricted TWT Parameter Set subfield includes a Restricted TWT P2P TID Bitmap subfield that specifies which traffic identifier (TID) or TIDs are allowed as delay-sensitive traffic streams for peer-to-peer exchange.

6. 6. The method of claim 5, wherein the action frame includes both the Restricted TWT Parameter Set subfield and a TPU Buffer Status subfield containing information about traffic buffered at a peer non-AP station from which the action frame was transmitted at the time the action frame was transmitted, and only buffered traffic corresponding to the TID or TIDs identified in the Restricted TWT P2P TID Bitmap subfield is reported in the TPU Buffer Status field.

7. The method of claim 1 or 2, wherein the action frame comprises an action frame of a TDLS category having a TDLS Action field of TDLS Peer Traffic Indication or TDLS Peer Power Save Mode Request or Response.

8. 3. The method of claim 1 or 2, wherein the action frame comprises an action frame of the TDLS category having a TDLS Action field set to any value between 11 and 255 to define a TDLS Peer rTWT Indication.

9. 3. The method of claim 1, wherein the action frame comprises a Tunneled Direct Link Setup (TDLS) Request action frame for establishing a TDLS session between two peer non-AP stations.

10. 10. The method of claim 9, further comprising exchanging TDLS Setup Response action frames and TDLS Setup Confirm action frames between the two peer non-AP stations, wherein the TDLS Setup Response and Confirm action frames include information of the broadcast TWT schedule.

11. The method of claim 1, further comprising, at a peer non-AP station that is a source of the action frame, negotiating a Tunneled Direct Link Setup (TDLS) session with the other peer non-AP station before establishing membership in the broadcast TWT schedule, wherein the action frame is transmitted within the TDLS session.

12. 3. The method of claim 2, further comprising: at the other peer non-AP station, negotiating a Tunneled Direct Link Setup (TDLS) session with the peer non-AP station from which the action frame is transmitted, wherein the action frame is received within the TDLS session once established.

13. The method of claim 1 or 2, wherein the peer non-AP station or the other peer non-AP station belongs to a non-AP multi-link device (MLD).

14. The method of claim 1, wherein when an action frame with a status code indicating SUCCESS is received from the other non-AP station in response to the action frame, the method directly exchanges the peer-to-peer data with the other peer non-AP station during a TWT service period (SP) corresponding to the broadcast TWT schedule identified based on the broadcast TWT ID.

15. The method of claim 1, wherein the peer non-access point (AP) station is a station conforming to the IEEE 802.11 series of standards.

16. The method of claim 2, wherein the peer non-access point (AP) station is a station conforming to the IEEE 802.11 series of standards.

17. A communication device functioning as a non-access point (AP) station, comprising: transmitting means for transmitting an action frame used for Tunneled Direct Link Setup (TDLS) to other non-AP stations when the communication device is a member of a Broadcast Target Wake Time (TWT) schedule, the action frame including a Broadcast TWT ID; communication means for directly exchanging peer-to-peer data with the other peer non-AP stations during a TWT service period (SP) corresponding to a broadcast TWT schedule identified based on the broadcast TWT ID; A communication device comprising:

18. A communication device that functions as a non-access point (AP) station, comprising: receiving means for receiving an action frame used for Tunneled Direct Link Setup (TDLS) from another peer non-AP station that is a member of a broadcast target wake time (TWT) schedule, the action frame including a broadcast TWT ID; communication means for directly exchanging peer-to-peer data with the other peer non-AP stations during a TWT service period (SP) corresponding to a broadcast TWT schedule identified based on the broadcast TWT ID; A communication device comprising:

19. The communication device of claim 17 or 18, wherein the action frame includes a Broadcast TWT Info field that includes the Broadcast TWT ID subfield.

20. The communication device of claim 17, wherein when an action frame having a status code indicating SUCCESS is received from the other non-AP station in response to the action frame, the communication device directly exchanges the peer-to-peer data with the other peer non-AP station during a TWT service period (SP) corresponding to the broadcast TWT schedule identified based on the broadcast TWT ID.

21. The communication device according to claim 17, wherein the non-AP station is a station conforming to the IEEE 802.11 standard series.

22. The communication device of claim 18, wherein the non-AP station is a station conforming to the IEEE 802.11 standard series.

23. A 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 according to claim 1 or 2.

Images