Multilink Limited TWT

Abstract

Radio protocol CSMA / CA and scheduling SP of R-TWT for RTA frame exchange. In addition to link level scheduling, R-TWT can also be scheduled from MLD level. R-TWT scheduler MLD is configured to schedule multi-link (ML) R-TWTs where SP is scheduled on multiple links. These ML R-TWTs can be one or more SL R-TWTs, and ML R-TWTs can be R-TWTs independent from SL R-TWTs. R-TWT scheduler MLD (a) can assign unique ML level R-TWT ID to identify ML R-TWTs, and if ML R-TWT consists of SL R-TWTs, each SL R-TWT is assigned unique link level R-TWT ID for identification on that link, and (b) only needs to complete ML R-TWT signaling on one link for ML R-TWT management on multiple links.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of U.S. Provisional Patent Application Serial No. 63 / 263,340, filed November 1, 2021, which claims priority to and the benefit of U.S. Patent Application Serial No. 18 / 049,285, filed October 24, 2022, each of which is incorporated herein by reference in its entirety. Priority is claimed to each of the above-referenced applications.

[0002] STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT Not applicable

[0003] Notification of copyrighted material Portions of the material in this patent document may be subject to copyright protection under the copyright laws of the United States and other countries. The copyright owner has no objection to the reproduction by any third party of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office publicly available files or records, but otherwise reserves all copyright rights. The copyright owner does not hereby waive any of its rights to have this patent document maintained in secrecy, including, but not limited to, the right pursuant to 37 CFR § 1.14.

[0004] The techniques of this disclosure relate generally to wireless local area networks using CSMA / CA, and more particularly to multi-link (MLD) R-TWT scheduling for ML R-TWT with service periods (SPs) on multiple links. [Background technology]

[0005] Current wireless technologies using Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) focus on high network throughput performance but lack low latency performance. However, an increasing number of applications, such as real-time applications (RTA), require low latency, and thus a technology gap exists.

[0006] RTA requires low-latency communication and uses best-effort communication. Data generated from RTA is called RTA traffic and is packetized as RTA frame(s) at the sending STA. Data generated from non-time-sensitive applications is called non-RTA traffic and is packetized as non-RTA frame(s) at the sending STA. The sending STA then transmits packets carrying the frames over the channel to the receiving STA.

[0007] RTA frames require low latency due to high delivery timeliness requirements. RTA frames are valid if they are delivered within a certain time frame. One solution in CSMA / CA wireless technology is to schedule a Restricted Target Wake Time (R-TWT) Service Period (SP) for RTA frame exchange. During the R-TWT SP, RTA frames have a higher transmission priority than other frames. Summary of the Invention [Problem to be solved by the invention]

[0008] However, current implementations of the R-TWT mechanism suffer from scheduling and overhead issues. The present disclosure overcomes these issues and provides additional advantages. [Means for solving the problem]

[0009] A wireless local area network (WLAN) uses carrier sense multiple access with collision avoidance (CSMA / CA) to schedule service periods (SPs) of restricted target wake times (R-TWTs) for RTA frame exchange. During R-TWT SPs, RTA frames have a higher transmission priority than other frames. This disclosure describes a protocol that enables an R-TWT scheduling MLD to schedule multilink (ML) R-TWTs whose service periods (SPs) are scheduled on multiple links. These ML R-TWTs can be one or more single-link (SL) R-TWTs, and the ML R-TWTs can be R-TWTs independent of SL R-TWTs. The R-TWT scheduling MLD can assign unique ML-level R-TWT IDs to identify the ML R-TWTs. If the ML R-TWT consists of SL R-TWTs, each SL R-TWT is assigned a unique link-level R-TWT ID for identification on the link. The R-TWT scheduling AP MLD only needs to complete ML R-TWT signaling on one link for ML R-TWT management on multiple links.

[0010] The non-AP MLD sends an ML R-TWT request frame to negotiate membership in the ML R-TWT. The AP MLD responds with an ML R-TWT response frame to accept or reject the request from the non-AP MLD. If the AP MLD accepts the request, the non-AP MLD becomes a member of the ML R-TWT.

[0011] A non-AP STA transmits a frame containing an ML TWT element for ML R-TWT signaling. The ML TWT element carries one or more Broadcast ML TWT Parameter Sets fields. The ML TWT element includes link information indicating which link the information in the Broadcast ML TWT Parameter Sets field applies to.

[0012] Further aspects of the technology described herein will become apparent in the remainder of this specification, and this detailed description is intended to fully disclose preferred embodiments of the technology without limiting them.

[0013] The techniques described herein will be better understood by reference to the following drawings, which are for illustrative purposes only. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 is an interaction communication diagram for implementing target wake time (TWT) in IEEE 802.11ax. [Figure 2] FIG. 10 is a data field diagram of a TWT setting frame. [Figure 3] FIG. 1 is a data field diagram of the TWT element defined in IEEE 802.11ax. [Figure 4] FIG. 10 is a data field diagram of the control field of the TWT element. [Figure 5] This is a data field diagram of the broadcast TWT parameter information field (TWT parameter information field in the TWT element when the negotiation type is 2 or 3). [Figure 6] FIG. 6 is a data field diagram of the Request Type field of the Broadcast TWT Parameter Information field of FIG. 5. [Figure 7] FIG. 6 is a data field diagram of the Broadcast TWT Information field of the Broadcast TWT Parameter Information field of FIG. 5. [Figure 8] FIG. 1 is a communication diagram of R-TWT SP communication operation in a scenario with AP1, STA1, STA2, and STA3. [Figure 9] FIG. 1 is an interaction diagram of TWT teardown signaling defined in IEEE 802.11ax. [Figure 10] FIG. 10 is a data field diagram of a TWT teardown frame. [Figure 11]FIG. 10 is a data field diagram of the TWT flow field. [Figure 12] FIG. 10 is a data field diagram of the TWT flow field. [Figure 13] FIG. 10 is a data field diagram of the TWT flow field. [Figure 14] FIG. 1 is a hardware block diagram of station (STA) hardware in accordance with at least one embodiment of the present disclosure. [Figure 15] FIG. 1 is a hardware block diagram of a station configuration, such as that included in multi-link device (MLD) hardware, in accordance with at least one embodiment of the present disclosure. [Figure 16] FIG. 1 is a station topology diagram for discussion in accordance with at least one embodiment of the present disclosure. [Figure 17] FIG. 10 is a flow diagram for an AP belonging to an R-TWT scheduling AP MLD to announce ML R-TWT scheduling, in accordance with at least one embodiment of the present disclosure. [Figure 18] FIG. 10 is a flow diagram for an AP belonging to an R-TWT scheduling AP MLD to announce ML R-TWT scheduling, in accordance with at least one embodiment of the present disclosure. [Figure 19] FIG. 10 is a flow diagram for an R-TWT scheduled MLD to request ML R-TWT membership, in accordance with at least one embodiment of the present disclosure. [Figure 20] FIG. 10 is a flow diagram of an R-TWT scheduling AP MLD responding to an ML R-TWT membership, in accordance with at least one embodiment of the present disclosure. [Figure 21] FIG. 10 is an interaction diagram of ML R-TWT membership negotiation signaling in accordance with at least one embodiment of the present disclosure. [Figure 22] FIG. 10 is a flow diagram of an R-TWT scheduling AP MLD tearing down an ML R-TWT, in accordance with at least one embodiment of the present disclosure. [Figure 23]FIG. 10 is an interaction diagram of ML R-TWT teardown signaling using ML-level R-TWT ID, in accordance with at least one embodiment of the present disclosure. [Figure 24] FIG. 10 is a data field diagram of a ML R-TWT configuration frame used for membership management of ML R-TWTs, in accordance with at least one embodiment of the present disclosure. [Figure 25] FIG. 10 is a data field diagram of an ML R-TWT teardown frame in accordance with at least one embodiment of the present disclosure. [Figure 26] FIG. 10 is a data field diagram of an ML TWT element, in accordance with at least one embodiment of the present disclosure. [Figure 27] FIG. 10 is a data field diagram of the format of the control field of the ML TWT element, in accordance with at least one embodiment of the present disclosure. [Figure 28] FIG. 10 is a data field diagram of a Broadcast ML TWT Parameter Sets field in accordance with at least one embodiment of the present disclosure. [Figure 29] FIG. 10 is a data field diagram of a Request Type field of a Broadcast ML TWT Parameter Sets field in accordance with at least one embodiment of the present disclosure. [Figure 30] FIG. 10 is a data field diagram of a Request Type field of a Broadcast ML TWT Parameter Sets field in accordance with at least one embodiment of the present disclosure. [Figure 31] FIG. 10 is a data field diagram of a link information field in accordance with at least one embodiment of the present disclosure. [Figure 32] FIG. 10 is a data field diagram of a link information field in accordance with at least one embodiment of the present disclosure. [Figure 33] FIG. 10 is a data field diagram of a link information field in accordance with at least one embodiment of the present disclosure. [Figure 34] FIG. 10 is a data field diagram of a link information field in accordance with at least one embodiment of the present disclosure. [Figure 35]FIG. 10 is a data field diagram of a link information field in accordance with at least one embodiment of the present disclosure. [Figure 36] FIG. 10 is a communication diagram of R-TWT scheduling in which an AP advertises only ML R-TWT SP scheduling on its own link, in accordance with at least one embodiment of the present disclosure. [Figure 37] FIG. 10 is a communication diagram in which an R-TWT scheduling AP announces SL R-TWT scheduling on all links, in accordance with at least one embodiment of the present disclosure. [Figure 38] FIG. 10 is a communication diagram of another option in which the R-TWT scheduling AP announces SL R-TWT scheduling on all links, in accordance with at least one embodiment of the present disclosure. [Figure 39] FIG. 1 is a communication diagram of R-TWT scheduling in which an AP announces ML R-TWT scheduling for SPs on its link, in accordance with at least one embodiment of the present disclosure. [Figure 40] FIG. 1 is a communication diagram of an ML R-TWT configuration procedure in accordance with at least one embodiment of the present disclosure. [Figure 41] FIG. 1 is a communication diagram of an ML R-TWT configuration procedure in accordance with at least one embodiment of the present disclosure. [Figure 42] FIG. 1 is a communication diagram of an ML R-TWT configuration procedure over multiple links, in accordance with at least one embodiment of the present disclosure. [Figure 43] FIG. 1 is a communication diagram of a configuration procedure for an ML R-TWT over one link, in accordance with at least one embodiment of the present disclosure. [Figure 44] FIG. 1 is a communication diagram of an ML R-TWT configuration procedure for an ML R-TWT, in accordance with at least one embodiment of the present disclosure. [Figure 45] FIG. 10 is a communication diagram of an ML R-TWT configuration procedure for an ML R-TWT in which only partial requests are accepted, in accordance with at least one embodiment of the present disclosure. [Figure 46]FIG. 10 is a communication diagram of R-TWT scheduling in which an AP announces SL R-TWT scheduling and ML R-TWT scheduling in an ML TWT element, in accordance with at least one embodiment of the present disclosure. [Figure 47] FIG. 10 is a communication diagram of ML R-TWT configuration using MLD-level R-TWT IDs, in accordance with at least one embodiment of the present disclosure. [Figure 48] FIG. 1 is a communication diagram of R-TWT scheduling in which an AP announces ML R-TWT scheduling for all AP MLDs to which it belongs, in accordance with at least one embodiment of the present disclosure. [Figure 49] FIG. 1 is a communication diagram of ML R-TWT operation over a special MLD link, in accordance with at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0015] 1. Current Wireless Technology 1.1. Restricted TWT (R-TWT) Figure 1 shows an example of the target wake time (TWT) setting defined in IEEE 802.11ax. The STA interaction model can be the same as that defined in the IEEE 802.11 standard.

[0016] When a non-AP STA decides to initiate a TWT setup procedure with an AP, the non-AP STA's Station Management Entity (SME) sends an MLME-TWTSETUP.request message to its Medium Access Control (MAC) Sublayer Management Entity (MLME). When the non-AP STA's MLME receives the MLME-TWTSETUP.request message, it collects the information in the MLME-TWTSETUP.request message and sends a TWT setup frame (i.e., a TWT request frame) to the AP. The AP's MLME receives the frame and generates an MLME-TWTSETUP.indication message to its SME.

[0017] Next, the SME of the AP sends an MLME-TWTSETUP.response message containing the TWT configuration result to its MLME. The MLME of the AP then sends a TWT configuration frame (i.e., a TWT response frame) to the non-AP STA. The MLME of the non-AP STA receives the frame and sends an MLME-TWTSETUP.confirm message to its SME. As a result, the non-AP can know whether the TWT configuration was successful or not.

[0018] Figure 2 shows the format of a TWT setting frame, which has fields called Frame Control, Duration, Address (1-3), Sequence Control, Data, and Frame Check Sequence (FCS). At the bottom of the figure, the subfields within the Data field are shown as Category, Action, Dialog Token, and TWT element, which are detailed in Figure 3.

[0019] The format of the TWT element defined in IEEE 802.11ax is shown in Figure 3. The fields are shown as Element ID, Length, Control, and TWT Parameter Information. If the Negotiation Type field in the Control field of the TWT element is set to a value of 2 or 3, the TWT Parameter Information field in the TWT element carries the Broadcast TWT Parameter Information field as shown in Figure 5.

[0020] At present, there is an update to IEEE802.11be (draft P802.11be_D1.01). If the value of the Broadcast TWT Recommended field in the Request Type field of the Broadcast TWT Parameter Information field is set to 4, this indicates that the Broadcast TWT (B-TWT) indicated in the Broadcast TWT Parameter Information field is a Restricted TWT (R-TWT).

[0021] Figure 4 shows the subfields of the control field of the TWT element shown in Figure 3. These subfields are shown as Neighbor Discovery Protocol (NDP) Paging Indicator, Responder Power-Management (PM) Mode, Negotiation Type, TWT Information Frame Disabled, Wake Duration Unit, and Reserved subfields.

[0022] FIG. 5 shows the broadcast TWT parameter information field (the TWT parameter information field in the TWT element when the negotiation type is 2 or 3).

[0023] Figure 6 shows the subfields within the Request Type field of the Broadcast TWT Parameter Information field of Figure 5. These subfields are shown as TWT Request, TWT Setup Command, Trigger, Last Broadcast Parameter Set, Flow Type, Broadcast TWT Recommendation, TWT Wake Interval Exponent, and Reserved subfields.

[0024] Figure 7 shows the subfields of the Broadcast TWT Information field of the Broadcast TWT Parameter Information field of Figure 5. These subfields are shown as Restricted TWT Traffic Information Present, Reserved, Broadcast TWT ID, and Broadcast TWT Persistence.

[0025] According to the IEEE 802.11be definition, the R-TWT element has the following characteristics: (a) Limited TWT, referred to as the R-TWT scheduling AP. The R-TWT scheduling AP is an Extra High Throughput (EHT) AP that supports limited TWT operation and sets the Limited TWT Support subfield in the transmitted EHT Capabilities element to a value of 1. (b) Limited TWT, referred to as the R-TWT scheduled STA. The R-TWT scheduling STA is a non-AP EHT STA that supports limited TWT operation and sets the Limited TWT Support subfield in the transmitted EHT Capabilities element to a value of 1. (c) The R-TWT scheduled STA can establish membership in one or more R-TWTs scheduled by the R-TWT scheduling AP. R-TWT configuration signaling is the same as broadcast TWT, with the addition of parameter settings used for R-TWT membership negotiation between the R-TWT scheduled STA and the R-TWT scheduling AP. After the R-TWT scheduled STA establishes membership in the R-TWT scheduled by the R-TWT scheduling AP, it has a higher priority or is allowed to exchange frames with the R-TWT scheduling AP during the R-TWT SP. On the other hand, R-TWT scheduled STAs that are not members of the R-TWT have a lower priority or are not allowed to exchange frames with the R-TWT scheduling AP during the R-TWT SP.

[0026] Figure 8 shows an example of R-TWT SP communication operation in a scenario with AP1, STA1, STA2, and STA3. AP1 is the R-TWT scheduling AP that announces R-TWT1 scheduling and manages R-TWT1 members. STA1 and STA2 are R-TWT1 member STAs. AP1 schedules and prioritizes frame exchanges with member STAs (e.g., UL PPDUs of SCS1 with STA1 and DL PPDUs of SCS2 with STA2) during the R-TWT1 SP. A STA that can receive (sense) and recognize (understand) R-TWT scheduling is called an R-TWT-scheduled STA. STA3 is an R-TWT-scheduled STA but is not a member STA of the R-TWT1. STA3 must end its TXOP before the start time of the R-TWT1 SP. STA3 can enter quiet mode or not contend for the channel during the R-TWT1 SP. The scheduling AP can broadcast a quiet element during the R-TWT SP to announce the quiet interval, and STAs that sense this element can enter quiet mode.

[0027] Figure 9 shows the TWT teardown signaling defined in IEEE 802.11ax. The STA interaction model can be the same as that defined in the IEEE 802.11ax standard.

[0028] The AP decides to tear down a TWT and does the following: The station management entity (SME) of the AP sends an MLME-TWTTEARDOWN.request message to the MAC sublayer management entity (MLME). When the MLME of the AP receives the MLME-TWTTEARDOWN.request message, it collects the information in the MLME-TWTTEARDOWN.request message and transmits (e.g., unicast, groupcast, or broadcast) a TWT teardown frame to the non-AP STA. The MLME of the non-AP STA receives the frame and generates an MLME-TWTTEARDOWN.indication message to its SME, carrying the information in the frame. The SME of the non-AP STA then sends an MLME-TWTTEARDOWN.indication message to its MLME. As a result, the MLME of the non-AP STA knows which TWT(s) will be torn down by the AP.

[0029] 10 shows the format of a TWT teardown frame, which has fields called Frame Control, Duration, Address (1 to 3), Sequence Control, Data, and FCS. Here, a data field is shown, which has subfields called Category, Action, and TWT Flow.

[0030] Figures 11-13 show the fields of the TWT flow field as shown in Figure 10. Figure 11 shows a Type 0 or 1 TWT flow field format with subfields TWT Flow Identifier, Reserved, Negotiation Type, and Teardown All TWT. Figure 12 shows a Type 2 TWT flow field format with subfields Reserved, Negotiation Type, and Reserved. Figure 13 shows a Type 3 TWT flow field indicating the teardown of a broadcast TWT whose ID is indicated in the Broadcast TWT ID field. If the Broadcast TWT ID field references an R-TWT, this field indicates the teardown of the R-TWT. This field also includes the Negotiation Type and Teardown All TWT subfields.

[0031] 2. Problem statement Current wireless communication systems prioritize RTA traffic transmission using EDCA and R-TWT. During R-TWT SPs, RTA traffic is transmitted with priority. However, current wireless communication systems define a multilink device (MLD), where each STA belongs to one or more STAs operating on different links. R-TWT SPs can be scheduled on multiple links to improve the quality of service (QoS) for RTA traffic transmission, such as throughput, latency, reliability, and jitter. However, current R-TWT management and operation is performed only at the link level. There is no mechanism for managing and scheduling R-TWTs from the MLD perspective. As a result of R-TWTs being scheduled individually on each link, signaling overhead for R-TWT management can be significant. Furthermore, coordination of R-TWTs on different links is not feasible given link-level management considerations.

[0032] 3. Contribution of this Disclosure By utilizing the proposed technique, the R-TWT scheduling MLD can schedule a multi-link (ML) R-TWT in which SPs are scheduled on multiple links. As explained in Section 1.1, an ML R-TWT can consist of one or more single-link (SL) R-TWTs in which SPs are scheduled on the same link. Alternatively, an ML R-TWT can be an R-TWT independent of the SL R-TWTs.

[0033] By utilizing the disclosed protocol, the R-TWT scheduling MLD can assign unique ML-level R-TWT IDs to identify ML R-TWTs. If the ML R-TWTs consist of SL R-TWTs, each SL R-TWT is assigned a unique link-level R-TWT ID for identification on that link.

[0034] By utilizing the protocol of the present disclosure, the R-TWT scheduling AP MLD only needs to complete (terminate) ML R-TWT signaling on one link for ML R-TWT management on multiple links.

[0035] 4. Embodiment 4.1. Communication Station (STA and MLD) Hardware FIG. 14 illustrates an example embodiment 10 of STA hardware configured to execute the protocol of the present disclosure. An external I / O connection 14 couples to an internal bus 16 of circuitry 12, on which a CPU 18 and memory (e.g., RAM) 20 are preferably connected for executing program(s) implementing the communications protocol. The host machine contains at least one modem 22 supporting communications, coupled to at least one RF module 24, 28, each connected to one or more antennas 29, 26a, 26b, 26c-26n. RF modules with multiple antennas (e.g., antenna arrays) enable beamforming during transmission and reception. In this manner, the STA can transmit signals using multiple sets of beam patterns.

[0036] The bus 14 can connect various devices, such as sensors and actuators, to the CPU. Executing on the processor 18 are instructions from memory 20 for executing programs that implement communication protocols that are executed to enable the STAs to perform the functions of an access point (AP) station or a regular station (non-AP STA). It should also be understood that this programming is configured to operate in different modes (TXOP owner, TXOP sharing participant, source, intermediate, destination, first AP, other AP, station associated with first AP, station associated with other AP, coordinator, coordinatee, AP in OBSS, STA in OBSS, etc.) depending on what role it plays in the current communication situation.

[0037] The STA HW shown therefore consists of at least one modem and associated RF circuitry for providing communications over at least one band. This disclosure is primarily directed to the sub-6 GHz band.

[0038] It should be understood that the present disclosure can be implemented using multiple modems 22, each coupled to any number of RF circuits. In general, the more RF circuits used, the wider the coverage of the antenna beam directions. It should be understood that the number of RF circuits and antennas utilized will depend on the hardware constraints of a particular device. Some of the RF circuits and antennas can be disabled when a STA determines that it does not need to communicate with neighboring STAs. In at least one embodiment, the RF circuits include frequency converters and array antenna controllers, etc., and are connected to multiple antennas that are controlled to perform beamforming for transmission and reception. In this manner, a STA can transmit signals using a set of multiple beam patterns, with each beam pattern direction considered an antenna sector.

[0039] Additionally, multiple instances of station hardware such as those shown can be combined into a multi-link device (MLD), which typically has a processor and memory to coordinate activity, although each STA within the MLD does not necessarily require a separate CPU and memory.

[0040] FIG. 15 shows an example embodiment 40 of a multi-link device (MLD) hardware configuration. A Soft-AP MLD is an MLD consisting of one or more affiliated STAs operating as an AP. The Soft-AP MLD should support multiple radio operation on 2.4 GHz, 5 GHz, and 6 GHz. The basic link set among the multiple radios is a link pair that satisfies simultaneous transmit / receive (STR) mode, such as a basic link set (2.4 GHz and 5 GHz) or a basic link set (2.4 GHz and 6 GHz).

[0041] A conditional link is a link that forms a non-simultaneous transmit / receive (NSTR) link pair with some fundamental link. For example, these link pairs can include a 6 GHz link as a conditional link corresponding to the 5 GHz link when 5 GHz is the fundamental link, and can include a 5 GHz link as a conditional link corresponding to the 6 GHz link when 6 GHz is the fundamental link. Soft APs are used in different scenarios, including Wi-Fi hotspots and tethering.

[0042] An MLD has multiple STAs attached to it, each operating on a different frequency link. The MLD has external I / O access to applications, which connects to an MLD management entity 48 having a CPU 62 and memory (e.g., RAM) 64 to enable the execution of program(s) that implement the communication protocol at the MLD level. The MLD can distribute tasks to its attached stations, illustrated here as STA1 42, STA2 44 through STA N 46, collect information from them, and share that information among its attached STAs.

[0043] In at least one embodiment, each STA in the MLD has its own CPU 50 and memory (RAM) 52, which are coupled via a bus 58 to at least one modem 54 connected to at least one RF circuit 56 having one or more antennas. In this example, the RF circuit has multiple antennas 60a, 60b, 60c-60n, such as in the form of an antenna array. The modem in combination with the RF circuit and associated antenna(s) transmits / receives data frames to / from nearby STAs. In at least one implementation, the RF module includes a frequency converter, an array antenna controller, and other circuitry for interfacing with the antennas.

[0044] It should be understood that each STA in an MLD does not necessarily require its own processor and memory, as they may share resources with each other and / or with an MLD management entity depending on the particular MLD implementation. It should be understood that the above MLD diagram is provided by way of example and not limitation, and that the present disclosure can work with a wide variety of MLD implementations.

[0045] 4.2. Network Topology for Consideration 16 illustrates an example STA topology 65 for consideration in an embodiment of the present disclosure. This diagram is provided to assist in explaining the related technology and to enhance understanding of the proposed technology. It should be understood that the present disclosure is in no way limited to the topology of this example, as the protocol can be utilized in communications between WLAN STAs and MLDs of any desired topology.

[0046] An MLD is a device that has multiple associated STAs and one MAC Service Access Point (SAP) to a Logical Link Control (LLC) that contains one MAC data service.

[0047] If an AP belongs to an MLD, the MLD is an AP MLD. If a non-AP STA belongs to an MLD, the MLD is a non-AP MLD.

[0048] 16 illustrates a scenario with three MLDs 70, 72, and 74. AP1 76 and AP2 78 belong to multi-link device (MLD) 70 #1, STA1 80 and STA4 86 belong to MLD #2 72, and STA3 84 and STA5 88 belong to MLD #3 74. STA2 84 is an R-TWT scheduled station that may include a non-AP STA operating on link 1 or a single-link MLD (i.e., a special MLD with only one STA and operating on one link). STA6 92 is not an R-TWT scheduled station, and this station may also include a non-AP STA operating on link 1 or a single-link MLD (i.e., a special MLD with only one STA and operating on one link).

[0049] As shown, this scenario assumes the presence of three MLDs, two APs, and six STAs within a given area, shown here as a conference room 94 with one or more openings (e.g., doors and windows) 96. STA1, STA2, STA3, and STA6 are associated with AP1 via link 1, and STA4 and STA5 are associated with AP2 via link 2.

[0050] All STAs use EDCA for random channel access on all links. The R-TWT scheduling AP can schedule and announce R-TWT. The R-TWT scheduled STA is a non-AP STA that can receive and recognize R-TWT announcements from the R-TWT scheduling AP and support R-TWT operation. The R-TWT scheduled STA can negotiate R-TWT membership with the R-TWT scheduling AP. Once the R-TWT scheduled STA becomes an R-TWT member STA, the traffic (e.g., UL, DL, P2P) of the R-TWT scheduled STA (i.e., the R-TWT member STA) is scheduled and prioritized during the R-TWT SP.

[0051] AP1 and AP2 are APs that schedule R-TWT. STA1 to STA5 are STAs that are scheduled by R-TWT, but STA6 is not a STA that is scheduled by R-TWT.

[0052] 4.3.ML R-TWT Definition Here, we introduce the definitions used in this disclosure. An AP MLD that supports ML R-TWT operation is called the R-TWT scheduling AP MLD. A non-AP MLD that supports ML R-TWT operation is called the R-TWT scheduled MLD. After successfully negotiating ML R-TWT settings with the R-TWT scheduling AP MLD, the R-TWT scheduled MLD becomes a member MLD of that R-TWT. In this case, the traffic of the member MLD is given priority during that R-TWT SP. For example, as shown in Figure 16, MLD1 is the R-TWT scheduling AP MLD. MLD2 and MLD3 are R-TWT scheduled MLDs.

[0053] A SL R-TWT is scheduled by the R-TWT scheduling AP, and its SP is scheduled on the same link of the R-TWT scheduling AP, as defined in Section 1.1. The R-TWT scheduling AP assigns a unique ID, called the link-level R-TWT ID, to the SL R-TWT. The link-level R-TWT ID can be used by the R-TWT scheduling AP and its associated STAs to identify the SL R-TWT on its own link.

[0054] An ML R-TWT is scheduled by an R-TWT scheduling MLD, and its SP is scheduled on one or more links. An ML R-TWT consists of one or more SL R-TWTs scheduled by different APs belonging to the same R-TWT scheduling AP MLD. The SP of an ML R-TWT is the SP of these SL R-TWTs. An ML R-TWT can be either an implicit ML R-TWT or an explicit ML R-TWT.

[0055] An explicit ML R-TWT is an ML R-TWT that has been assigned a unique ID, called the MLD-level R-TWT ID, by the R-TWT scheduling AP MLD on all its links (or links), which can be used by the R-TWT scheduling AP MLD and the belonging MLDs on all its links to identify the ML R-TWT.

[0056] An implicit ML R-TWT is not assigned a unique MLD-level R-TWT ID by the R-TWT scheduling AP MLD. An implicit ML R-TWT can be a group of SL R-TWTs that share at least one of the following in common: (a) SL R-TWTs have the same link-level R-TWT ID but are scheduled on different links, (b) SL R-TWTs have the same SP scheduling on different links, or (c) SL R-TWTs whose scheduling is announced within the same ML TWT element.

[0057] It should be noted that the implicit ML R-TWT is not the implicit TWT (individual TWT) defined in IEEE802.11.

[0058] An ML R-TWT is the same as an SL R-TWT if it consists of only one SL R-TWT.

[0059] In some cases, the R-TWT-scheduled MLD can be a member MLD of the ML R-TWT on some of the links on which the ML R-TWT SP is scheduled. In this case, the member MLD's traffic is prioritized only on these links during the ML R-TWT SP, rather than on all links of the ML R-TWT SP. For example, an ML R-TWT schedules its SP on Link 1, Link 2, and Link 3. The R-TWT-scheduled MLD is a member MLD of this ML R-TWT only on Link 1 and Link 2. In this case, the R-TWT-scheduled MLD's traffic is prioritized on Link 1 and Link 2 during the ML R-TWT SP.

[0060] The behavior of the R-TWT scheduling AP and the R-TWT scheduled STA for the ML R-TWT SP on each link can be the same as the R-TWT behavior defined in IEEE 802.11be, e.g., the R-TWT scheduled STA must end its TXOP before the start of the ML R-TWT SP scheduled on that link.

[0061] In at least one embodiment / mode / option, the SP scheduling (such as SP start time, SP duration, and interval between SPs) of ML R-TWTs on different links must be the same.

[0062] 4.4.ML R-TWT Signaling This section describes ML R-TWT signaling for ML R-TWT scheduling announcements, ML R-TWT membership negotiation, and ML R-TWT teardown. The purpose of ML R-TWT signaling is to have signaling transmitted over one link manage the ML R-TWT.

[0063] If all R-TWT scheduled MLDs are operating (or enabled) on the same link, the R-TWT scheduling AP only needs to initiate a signal sequence on that link (such as a trigger frame + PS-Poll in a B-TWT SP) indicating the start of an ML R-TWT SP on multiple links.

[0064] The R-TWT scheduling AP only needs to send a signal (such as a broadcast EOSP signal) on multiple links indicating the end of the ML R-TWT SP on that link. The R-TWT scheduling AP can announce the ML R-TWT scheduling by sending a beacon only on that link.

[0065] When the R-TWT scheduled MLD requests membership in an ML R-TWT for transmission of a traffic stream under a traffic specification (TSPEC) or QoS characteristic element during an ML R-TWT SP, the AP considers whether this request can meet the QoS requirements of the traffic stream based on the capacities of all links on which the ML R-TWT SP is scheduled. Note that for SL R-TWT membership negotiation, the AP only needs to consider whether this negotiation can meet the QoS requirements of the traffic stream based on the capacities of the links on which the SL R-TWT SP is scheduled.

[0066] Traffic transmitted during the ML R-TWT SP may follow the TID-link mapping between non-AP MLD and AP MLD. In the case of ML R-TWT SP on multiple links, all these links may have the same TID-link mapping in the ML R-TWT SP, or each link may have at least one TID of delay-sensitive traffic that can be mapped to the link during the ML R-TWT SP.

[0067] It should be noted that the ML R-TWT signaling described in this disclosure can also be used for broadcast TWT signaling if the Broadcast TWT Recommended field in the Request Type field of the Broadcast ML TWT Parameter Information field is set to a value of “2” or “3”.

[0068] ML R-TWT Scheduling Announcement 17 and 18 show an example embodiment 110 in which an AP belonging to an R-TWT scheduling AP MLD announces ML R-TWT scheduling. When the AP plans to transmit 112 a frame announcing ML R-TWT scheduling, it may have several options as determined in block 114.

[0069] If the AP selects option 1, it adds ML TWT element(s) to the frame in block 116 of Figure 18, carrying Broadcast ML TWT Parameter Set(s) field(s) announcing the scheduling of ML R-TWT with SP scheduled on the AP's link and concurrent SP on other links. Examples of option 1 are shown in Figures 39 and 40.

[0070] If the AP selects option 2 in block 114 of Figure 17, it adds ML TWT element(s) to the frame in block 120 of Figure 18, carrying broadcast ML TWT parameter set field(s) that announce only the scheduling of ML R-TWT SPs on its own links. For example, if ML R-TWT SPs are scheduled on link 1 and link 2, the AP on link 1 will announce only the ML R-TWT SP scheduling on link 1 in its frame, and the AP on link 2 will announce only the ML R-TWT SP scheduling on link 2 in its frame. An example is shown in Figure 36.

[0071] If the AP selects option 3 in block 114 of Figure 17, then in block 122 of Figure 18, it adds ML TWT element(s) to the frame carrying Broadcast ML TWT Parameter Set(s) field(s) announcing the scheduling of all ML R-TWTs scheduled by the R-TWT scheduling AP MLD. This case is shown in Figures 37, 38, 46 and 48.

[0072] The AP then transmits (eg, unicast, multicast, groupcast, or broadcast) a frame to its associated non-AP STAs in each of these cases at 118 in FIG.

[0073] The frame carrying the information of ML R-TWT scheduling can be a beacon frame, a (ML) probe response frame, a (re)association response frame, or other management frame.

[0074] The ML TWT element can be included in a Multiple BSSID element defined in IEEE 802.11 to announce ML R-TWT scheduling of the R-TWT MLD of the corresponding non-transmitting BSS.

[0075] The formats of the ML TWT element and the Broadcast ML TWT parameter set field are given in section 4.5.

[0076] 4.4.2.ML R-TWT Membership Negotiation This section shows a flowchart of the ML R-TWT membership negotiation from the R-TWT scheduled MLD side and the R-TWT scheduling AP MLD side.

[0077] 19 illustrates an example embodiment 130 in which the R-TWT scheduled MLD requests ML R-TWT membership. The R-TWT scheduled MLD will negotiate 132 with the R-TWT scheduling AP MLD over a link, such as link 1, regarding membership of the ML R-TWT to be scheduled by the R-TWT scheduling AP MLD.

[0078] In this case, a STA belonging to the R-TWT scheduled MLD on link 1 transmits an ML R-TWT request frame carrying the broadcast ML TWT parameter set field for that ML R-TWT in the ML TWT element over link 1 (134).

[0079] A check 136 determines whether the R-TWT scheduled MLD has received an ML TWT response frame indicating that the R-TWT scheduling AP accepts the ML R-TWT membership request. If this condition is met, the R-TWT scheduled MLD is a member of the ML R-TWT (138).

[0080] If this condition is not met, the R-TWT scheduled MLD is not a member of the ML R-TWT (140).

[0081] It is also possible to transmit the ML R-TWT request frame and the ML TWT response frame via different links, as shown in Figure 42. The formats of the ML R-TWT request frame and the ML TWT response frame are shown in Figure 24.

[0082] When the R-TWT-scheduled MLD requests an ML R-TWT on which SPs are scheduled on multiple links, in at least one embodiment / mode / option, the R-TWT-scheduling AP MLD can respond that the R-TWT-scheduled MLD should become a member of the ML R-TWT on the partial links on which the ML R-TWT SPs are scheduled. For example, if the ML R-TWT consists of multiple SL R-TWTs, the ML R-TWT-scheduling MLD can become a member of some of the SL R-TWTs but is not permitted as a member of other SL R-TWTs. The ML R-TWT-scheduling MLD can then independently request membership for the other SL R-TWTs of which it is not a member. In at least one other embodiment / mode / option, the R-TWT-scheduling AP MLD can be configured to accept membership of the ML R-TWT SP on all links on which the ML R-TWT SPs are scheduled, or to not permit membership on any of these links.

[0083] 20 illustrates an example embodiment 150 in which an R-TWT scheduling AP MLD responds to an ML R-TWT membership. The R-TWT scheduling AP MLD receives an ML R-TWT request frame for negotiating ML R-TWT membership from the R-TWT scheduled AP MLD over a link, such as link 1 (152).

[0084] The R-TWT scheduling AP MLD then transmits an ML R-TWT response frame on either link 1 or another link, carrying the broadcast ML TWT parameter set field for that ML R-TWT to indicate the membership negotiation decision for that ML R-TWT (154).

[0085] In at least one embodiment / mode / option, the R-TWT scheduling AP MLD must send the ML R-TWT Response frame on the same link as the link on which the ML R-TWT Request frame was sent (e.g., link 1 in this example). The formats of the ML R-TWT Request and ML TWT Response frames are shown in Figure 24.

[0086] 21 illustrates an example embodiment 170 of ML R-TWT membership negotiation signaling (i.e., setup procedure) between an R-TWT scheduled MLD (non-AP MLD) and an R-TWT scheduling AP MLD (AP MLD). The figure shows communication between a non-AP MLD Station Management Entity (SME) 172 and its MLD / STA MAC Layer Management Entity (MLME) 174, as well as communication over the network with an AP MLD / AP MLME 176 and its AP SME 178. The STA interaction model can be the same as that defined in the IEEE 802.11be standard.

[0087] The non-AP MLD decides to initiate an ML R-TWT setup procedure with the AP MLD. The station management entity (SME) of the non-AP MLD sends an MLME-TWTSETUP.request message 180 to the MAC sublayer management entity (MLME). When the MLME of the non-AP MLD / STA receives the MLME-TWTSETUP.request message, it collects the information in the MLME-TWTSETUP.request message and sends an ML R-TWT setup frame 182 (i.e., an ML R-TWT request frame) to the AP MLD. The MLME of the AP or AP MLD receives the frame and generates an MLME-TWTSETUP.indication message 184 to the SME.

[0088] The SME of the AP MLD then processes this request information and sends an MLME-TWTSETUP.response message 188 containing the ML R-TWT configuration result to that MLME. The MLME of the AP or AP MLD then sends an ML R-TWT configuration frame 190 (i.e., an ML R-TWT response frame) to the non-AP MLD. The MLME of the non-AP MLD or STA receives the frame and sends an MLME-TWTSETUP.confirm message 192 to the SME. As a result, the non-AP MLD can determine (know) whether the ML R-TWT configuration was successful. The format of the ML R-TWT configuration frame is shown in Figure 24.

[0089] In at least one embodiment / mode / option, an AP MLD may send an unsolicited ML R-TWT response frame to a non-AP MLD to establish, modify, or terminate ML R-TWT membership in the non-AP MLD.

[0090] 4.4.3.ML R-TWT Teardown 22 illustrates an example embodiment 210 in which an R-TWT scheduling AP MLD tears down an ML R-TWT. The AP determines 212 one of several options, shown here as Option 1 and Option 2, for tearing down the ML R-TWT.

[0091] If option 1 is selected in block 212, the R-TWT scheduling AP MLD uses the ML-level R-TWT ID to tear down the ML R-TWT in block 214. In this case, the R-TWT scheduling AP MLD transmits an ML R-TWT teardown frame indicating the ML-level R-TWT ID to be torn down (216). The format of the ML R-TWT teardown frame may be as shown in FIG. 25.

[0092] If option 2 is selected in block 212, the R-TWT scheduling AP MLD tears down one SL R-TWT of the ML R-TWT using the SL-level R-TWT ID in block 218. In this case, the R-TWT scheduling AP MLD transmits a TWT teardown frame carrying a TWT flow field with a negotiation type subfield=3 on the link on which the SP of that SL R-TWT is scheduled (220). Note that in this case, other SL R-TWTs of the ML R-TWT are not torn down. The format of the TWT teardown frame can be, but is not limited to, the one shown in FIG. 10.

[0093] Figure 23 shows an example embodiment 230 of ML R-TWT teardown signaling using an ML-level R-TWT ID. The STA interaction model can be the same as that defined in the IEEE 802.11be standard. Similar to Figure 21, Figure 23 shows communication between a non-AP MLD Station Management Entity (SME) 172 and its MLD / STA MAC Layer Management Entity (MLME) 174, as well as communication with an AP MLD / AP MLME 176 and its AP SME 178 over the network.

[0094] The AP MLD decides (232) to tear down the ML R-TWT. The station management entity (SME) of the AP MLD sends an MLME-TWTTEARDOWN.request message 234 to its MAC sublayer management entity (MLME) or the MLME of the AP to which it belongs. When the MLME of the AP or AP MLD receives the MLME-TWTTEARDOWN.request message, it collects the information in the MLME-TWTTEARDOWN.request message and sends (unicast, groupcast, or broadcast) an ML R-TWT teardown frame 236 to the non-AP MLD. The MLME of the non-AP MLD or STA receives the frame and generates an MLME-TWTTEARDOWN.indication message to its SME, conveying the information in the frame.

[0095] Next, the SME of the non-AP MLD sends an MLME-TWTTEARDOWN.indication message to its MLME or the MLME of the AP to which it belongs. As a result, the MLME of the non-AP MLD or STA can recognize which TWT(s) have been torn down by the AP. The format of the TWT teardown frame is shown in Figure 25.

[0096] Frame Format This section describes the formats of the ML R-TWT configuration frame and the ML R-TWT teardown frame.

[0097] 4.5.1.ML R-TWT Configuration Frame FIG. 24 illustrates an example embodiment 310 of an ML R-TWT configuration frame used for ML R-TWT membership management.

[0098] An ML R-TWT configuration frame is an ML R-TWT request frame when sent to request membership of an ML R-TWT. An ML R-TWT configuration frame is an ML R-TWT response frame when sent in response to an ML R-TWT membership request. Note that in at least one embodiment / mode / option, an R-TWT scheduling AP MLD can send a unilateral ML R-TWT response frame to a non-AP MLD to establish, modify, or terminate ML R-TWT membership of the non-AP MLD.

[0099] The ML R-TWT configuration frame has the following fields: The Frame Control field indicates the type of frame. The Duration field contains the Network Allocation Vector (NAV) information used for CSMA / CA channel access. The Address 1 field contains the address of the receiver of the frame. The Address 2 field contains the address of the STA that sent the frame. The Address 3 field contains the BSSID of the receiver. The Sequence control field contains the fragment number and sequence number of the frame.

[0100] The data field contains the following subfields: The Category and Action subfields are set to indicate that the frame is an ML R-TWT configuration frame. In at least one embodiment / mode / option, the Category and Action fields may be set to the same values ​​as for a TWT configuration frame as shown in Figure 2.

[0101] The Dialog Token subfield is used to match ML R-TWT Response frames with ML R-TWT Request frames when there are multiple concurrent ML R-TWT membership negotiations. In an ML R-TWT membership negotiation, the ML R-TWT Response frame and the ML R-TWT Request frame should share the same unique dialog token number. If the ML R-TWT Response frame and the ML R-TWT Request frame are sent over different links, these dialog tokens must be unique across all links between the non-AP MLD sending the ML R-TWT Request frame and the AP MLD sending the ML R-TWT Response frame.

[0102] The ML TWT element is configured to indicate ML R-TWT membership negotiation or management information. The format of the ML TWT element is shown in Figure 26.

[0103] 4.5.2.ML R-TWT Teardown Frame Figure 25 shows an example embodiment 330 of an ML R-TWT teardown frame with the following fields: The Frame Control field indicates the type of frame. The Duration field contains the NAV information used for CSMA / CA channel access. The Address 1 field contains the address of the receiver of the frame. The Address 2 field contains the address of the STA that sent the frame. The Address 3 field contains the BSSID of the receiver. The Sequence control field contains the fragment number and sequence number of the frame.

[0104] The data field contains the following subfields: The Category and Action subfields are set to indicate that the frame is an ML R-TWT teardown action frame. The Category and Action subfields are set to the same numbers as for a TWT teardown frame as shown in Figure 10.

[0105] The TWT Flow subfield is set by the AP MLD scheduling the R-TWT to indicate which ML R-TWTs are torn down. Upon receiving this subfield, the receiving side, i.e., the MLD scheduled by the R-TWT, can recognize (know) which ML R-TWTs have been torn down. Therefore, the receiving side should not request membership for the ML R-TWT. If the receiving side is already a member of the ML R-TWT, it should immediately resign from membership upon receiving this subfield. If the ML R-TWT consists of multiple SL R-TWTs, tearing down an ML R-TWT may also tear down the SL R-TWTs. Alternatively, in at least one embodiment / aspect / option, tearing down an ML R-TWT does not necessarily tear down its associated SL R-TWTs.

[0106] The subfields of the TWT Flow subfield are as follows: The ML R-TWT ID subfield is set to indicate which ML R-TWTs have been torn down by the R-TWT scheduling AP MLD. This subfield can be spared when the Teardown All ML R-TWT field is set to '1'.

[0107] The Negotiation Type subfield is set to indicate that the contents of the ML R-TWT field presence and all ML R-TWT teardown fields of the TWT flow field are for ML R-TWT teardown. For example, the Negotiation Type can be set to a value of 2.

[0108] The Teardown All ML R-TWT field is set to indicate whether the R-TWT scheduling MLD will tear down all ML R-TWTs. This subfield may be implemented as a one-bit indication, as illustrated here. When this subfield is set to a first state (e.g., "1"), it indicates that the R-TWT scheduling MLD will tear down all of its ML R-TWTs. Otherwise, it is set to a second state (e.g., "0"), which indicates that the R-TWT scheduling MLD will tear down only the ML R-TWT indicated in the ML R-TWT ID field.

[0109] 4.6.ML TWT Element Format This section describes the format of the ML TWT element, which is configured to indicate ML R-TWT membership negotiation or management information.

[0110] When sent in an ML R-TWT request frame, the ML TWT element is set to indicate the sender's ML R-TWT membership request. When the receiver receives this element, it determines whether to accept the membership request based on the requirements of the ML R-TWT membership request. The receiver then transmits an ML R-TWT response frame indicating its decision regarding the membership request.

[0111] The ML TWT element, when sent in the ML R-TWT response frame, is set to indicate the decision of the ML R-TWT membership request.

[0112] If the ML R-TWT membership request is accepted, the ML TWT element also carries the member's ML R-TWT SP scheduling. When a receiver, such as the R-TWT scheduled MLD, receives this field, it knows that the ML R-TWT membership request has been accepted, becomes a member of the ML R-TWT, and operates according to the ML R-TWT SP scheduling.

[0113] If the ML R-TWT membership request is rejected, the receiver knows that it is not a member of the ML R-TWT. The ML TWT element can also carry proposal parameters that the receiver can use to re-request ML R-TWT membership.

[0114] When the ML TWT element is transmitted in an ML R-TWT scheduling announcement frame, such as a beacon, this field is set to indicate the ML R-TWT scheduling of the ML R-TWT scheduling AP MLD. A receiver that receives this element can confirm the ML R-TWT scheduling of the ML R-TWT scheduling AP MLD. If the receiver is the R-TWT scheduled MLD, it operates according to the ML R-TWT scheduling. The receiver can also request membership in the ML R-TWT announced by the ML R-TWT scheduling AP MLD.

[0115] There may also be multiple ML TWT elements within the same ML R-TWT configuration frame or within the same ML R-TWT scheduling announcement frame.

[0116] Figure 26 shows an example embodiment 350 of an ML TWT element with the following fields: An Element ID field is set to indicate that the element is an ML TWT element. This field may be set to the same value as the TWT element as shown in Figure 3. A Length field is set to indicate the length of the element. A Control field is also included, the subfields of which are described below in Figure 27. A TWT Parameter Information field, which may have multiple Broadcast ML TWT Parameter Set fields, the subfields of which are described in Figure 28.

[0117] The Broadcast ML TWT Parameter Set field indicates ML R-TWT scheduling when used in a scheduling announcement. A receiver, such as an R-TWT scheduled MLD, operates according to the ML R-TWT scheduling and can request membership in the ML R-TWT.

[0118] If the R-TWT scheduled MLD uses the broadcast ML TWT parameter set field to send an ML R-TWT membership request, this field is set to indicate the ML R-TWT requirements. When the ML R-TWT scheduled AP MLD receives the request, it decides whether to accept or reject the request based on the requirements of the R-TWT scheduled MLD.

[0119] When the R-TWT scheduling MLD uses the broadcast ML TWT parameter set field to accept a membership request from the R-TWT scheduled MLD, this field is set to indicate the ML R-TWT scheduling of which the R-TWT scheduled MLD will be a member. After receiving this field, the R-TWT scheduled MLD becomes a member of the ML R-TWT. The traffic of the R-TWT scheduled MLD is transmitted with priority during the ML R-TWT SP.

[0120] If the R-TWT scheduling MLD uses the Broadcast ML TWT Parameter Set field to reject a membership request from the R-TWT scheduled MLD (e.g., the TWT Configuration Command field is set to "Reject TWT"), the R-TWT scheduled MLD, after receiving this field, recognizes that the membership request has been rejected by the R-TWT scheduling MLD or that the existing ML R-TWT membership has been terminated.

[0121] If the R-TWT scheduling MLD uses the Broadcast ML TWT Parameter Set field to reject a membership request from the R-TWT scheduled MLD (e.g., the TWT Configuration Command field is set to "Alternate TWT" or "Dictate TWT"), this field is set to indicate the proposed parameters that the R-TWT scheduled MLD can use to request ML R-TWT membership the next time. When the R-TWT scheduled MLD receives this field, it recognizes that it did not obtain ML R-TWT membership, but it can re-request ML R-TWT membership using the proposed parameters.

[0122] Each Broadcast ML TWT parameter set field can represent the parameter settings of multiple (including one) SL R-TWTs or one ML R-TWT. As an example: (a) One Broadcast ML TWT parameter set field can represent an ML R-TWT with an MLD-level R-TWT ID. (b) One Broadcast ML TWT parameter set field can represent one or more SL R-TWTs with the same parameter settings and the same SL-level R-TWT ID but scheduled on different links. SL R-TWTs in the same Broadcast ML TWT parameter set field can belong to the same ML R-TWT.

[0123] Figure 27 illustrates an example embodiment 370 of the control field of the ML TWT element shown in Figure 26. The NDP Paging Indicator, Responder PM Mode, Negotiation Type, TWT Information Frame Disable, and Wake Period Units fields can be the same as those in the control field of the TWT element shown in Figure 4.

[0124] The ML TWT Indication field is set to indicate whether the TWT parameter information field in the ML TWT element carries a broadcast ML TWT parameter set field. This field can be implemented as a 1-bit indication. For example, if this field is set to a first state (e.g., "1"), the ML TWT element carries only the broadcast ML TWT parameter set field. Otherwise, if this field is set to a second state (e.g., "0"), the ML TWT element carries only the broadcast TWT parameter set field. Note that if the element ID of the ML TWT element is the same as that in the TWT element, this field can also be used to indicate whether the element is a TWT element or an ML TWT element. If this field is set to a first state (e.g., "1"), the element is an ML TWT element, while if this field is set to a second state (e.g., "0"), the element is a TWT element.

[0125] The Link Info Present field is set to indicate the presence of a link information field. When this field is set to a first state (e.g., "1"), a link information field is present in the control field. When this field is set to a second state (e.g., "0"), a link information field is not present in the control field.

[0126] The Link Info field is set to indicate which link the contents of the ML TWT element apply to (i.e., which link the contents of all Broadcast ML TWT Parameter Sets fields in the ML TWT element apply to). When a receiver such as an MLD receives this field, it has information about which links the contents of the ML TWT element apply to and forwards these parameters to the associated STAs operating on those links. For example, if an MLD receives an ML TWT element on Link 1 and the Link Info field in the Control field is set to Link 2, this ML TWT element is for an R-TWT SP scheduled on Link 2. The MLD can forward the Broadcast ML TWT Parameter Sets field to the associated STAs on Link 2. The format of the Link Info field can be one of those shown in Figures 31 to 35.

[0127] Note that the link information field in the control field shown in FIG. 27 and the link information field in the broadcast ML TWT parameter set field shown in FIG. 28 cannot exist simultaneously in the same ML TWT element.

[0128] If the Link Information field is not present in both the Control field and the Broadcast ML TWT Parameter Sets field, then the Broadcast ML TWT Parameter Sets field is for the SL R-TWT on the link on which the Broadcast ML TWT Parameter Sets field is sent.

[0129] Figure 28 illustrates an example embodiment 390 of a Broadcast ML TWT Parameter Sets field. Each Broadcast ML TWT Parameter Sets field can represent parameter settings for one or more SL R-TWTs that belong to an ML R-TWT (scheduled on the same link level ID but different links). The Request Type field can be set as shown in Figure 29.

[0130] The Target Wake Time field is set to indicate the start time of the R-TWT SP. When set for a scheduling announcement, this field indicates the start time of the first R-TWT SP after the scheduling announcement frame (e.g., a beacon). The R-TWT scheduled MLD will have information about the start time of the first R-TWT SP after receiving this field. When set for an ML R-TWT membership request of the R-TWT scheduled MLD, this field indicates the start time of the first R-TWT SP when the R-TWT scheduled MLD becomes a member of the R-TWT. The R-TWT scheduling MLD can decide whether to accept the membership request according to this field. When set for an ML R-TWT response when the TWT configuration command field is set to "Alternate TWT" or "TWT indication," this field indicates a suggested parameter that the R-TWT scheduling MLD can use to set this field the next time it decides to request R-TWT membership. When set for an ML R-TWT response accepting an ML R-TWT request, this field indicates the start time of the first SP of the R-TWT after the R-TWT scheduled MLD receives this field and becomes a member of the R-TWT.

[0131] The target wake time field can be set using one of the following options: In option 1, the target wake time field is set to the TSF time of the STA sending this field; In option 2, the target wake time field is set to the TSF time of the link indicated in the Link Information field of the same Broadcast ML TWT Parameter Set field if the link information can only indicate one link; In option 3, the target wake time field is set to the TSF time of the link indicated in the Link Information field of the Control field of the ML TWT element if the link information can only indicate one link; In option 4, the target wake time field is set to the TSF time of the link that is the first bit of the Link Information field (MSB or LSB in the Link Bitmap shown in Figure 32, or the first Link ID field shown in Figures 33-35).

[0132] The nominal minimum TWT Wake Duration field is set to indicate the R-TWT SP duration. The TWT Wake Interval Mantissa field and the TWT Wake Interval Exponent field shown in FIG. 29 are set to represent the interval between R-TWT SPs similar to that specified in IEEE 802.11ax. The Broadcast TWT Info field may be as shown in FIG. 30. The Restricted TWT Traffic Info field is present when the Restricted TWT Traffic Info Present field shown in FIG. 30 is set to a first state (e.g., "1"), and this field may be the same as that specified in IEEE 802.11be. The Broadcast ML TWT ID field is set to indicate the MLD level R-TWT ID of the ML R-TWT. The receiver can use this field to identify the ML R-TWT.

[0133] The Link Info field is set to indicate which link the contents of the Broadcast ML TWT Parameter Sets field apply to. When the receiver receives this field, it has information about which link the contents of the Broadcast ML TWT Parameter Sets field apply to and forwards these parameters to the STAs operating on those links. For example, if an MLD receives a Broadcast ML TWT Parameter Sets field on link 1 and the Link Info field of the Broadcast ML TWT Parameter Sets field is set to link 2, then this Broadcast ML TWT Parameter Sets field is for the R-TWT SP scheduled on link 2. The MLD can forward the Broadcast ML TWT Parameter Sets field to the associated STAs on link 2. The format of the Link Info field can be one of those shown in Figures 31 to 35.

[0134] 29 illustrates an example embodiment 410 of the Request Type field of the Broadcast ML TWT Parameter Sets field. The TWT Request, TWT Configuration Command, Trigger, Last Broadcast Parameter Set, Flow Type, Broadcast TWT Recommended, and TWT Wake Interval Index fields can be the same as those defined in IEEE 802.11ax.

[0135] The Trigger-based Only field is set to indicate whether the ML R-TWT scheduling AP MLD can contend for the channel during the R-TWT SP. In at least one embodiment, this field can be a one-bit indication. For example, if this field is set to a first state (e.g., "1"), only the ML R-TWT scheduling AP MLD can trigger the R-TWT member's UL traffic transmission during the R-TWT SP. If this field is set to a second state (e.g., "0"), the R-TWT member can contend for and access the channel for UL traffic transmission during the R-TWT SP.

[0136] In at least one embodiment / mode / option, if the Broadcast TWT Recommended field is set to indicate that the Broadcast ML TWT Parameter Sets field is for R-TWT (e.g., a value of 4), the Trigger field functions as a Trigger Based Only field and the Trigger Based Only field is not required.

[0137] FIG. 30 illustrates an example embodiment 430 of the Request Type field of the Broadcast ML TWT Parameter Sets field, with the following subfields:

[0138] The Restricted TWT Traffic Info Present field, in at least one embodiment, is a one-bit indication of whether a restricted TWT traffic information field is present in the Broadcast ML TWT Parameter Set field, and may be identical to that shown in FIG. 7.

[0139] The ML TWT ID Present field is set to indicate whether a Broadcast ML TWT ID field is present in the Broadcast ML TWT Parameter Sets field shown in FIG. 28. In at least one embodiment, this field can be a one-bit indication. For example, if this field is set to a first state (e.g., "1"), then a Broadcast ML TWT ID field is present in the Broadcast ML TWT Parameter Sets field. Otherwise, this field is set to a second state (e.g., "0"), and no Broadcast ML TWT ID field is present in the Broadcast ML TWT Parameter Sets field.

[0140] The Link Info Present field, in at least one embodiment, can be a one-bit indication of whether a Link Info field is present in the Broadcast ML TWT Parameter Sets field shown in Figure 28. For example, if this field is set to a first state (e.g., "1"), then a Link Info field is present in the Broadcast ML TWT Parameter Sets field. Otherwise, this field is set to a second state (e.g., "0"), and no Link Info field is present in the Broadcast ML TWT Parameter Sets field. In this case, the Broadcast ML TWT Parameter Sets field is for the ML R-TWT parameter setting on the link over which this field is transmitted.

[0141] The Broadcast TWT ID field is set to indicate the link-level R-TWT ID of the SL R-TWT. The parameters in the Broadcast ML TWT Parameter Settings field are for the specific SL R-TWT(s) on the link indicated in the Link Information field.

[0142] The Broadcast TWT Persistence field may be the same as that defined in IEEE 802.11ax.

[0143] In at least one embodiment / mode / option, the ML TWT ID Present field is set to indicate whether the broadcast TWT ID should be set to the MLD level R-TWT ID or the link level R-TWT ID. When the ML TWT ID Present field is set to a first state (e.g., "1"), the broadcast TWT ID field is set to indicate the MLD level R-TWT ID. When the ML TWT ID Present field is set to a second state (e.g., "0"), the broadcast TWT ID field is set to indicate the link level R-TWT ID.

[0144] 31-35 show five options 450, 470, 490, 510 and 530 for the format of the link information field by way of example and not limitation.

[0145] Option 1 in Figure 31 allows a Link Information field to carry only one Link ID field, which is set to represent the one link to which the information applies.

[0146] In option 2 of Figure 32, the link information field can carry one link bitmap field. This field can be the same as that defined in IEEE 802.11be. The link bitmap field consists of multiple bits. Each bit represents a link. If a bit is set to a first state (e.g., "1"), it indicates that the information applies to the link corresponding to this bit. Otherwise, the bit is set to a second state (e.g., "0"), indicating that the information does not apply to the link corresponding to this bit.

[0147] In option 3 of Figure 33, the Link Information field can carry multiple Link ID fields. Each Link ID field is set to represent one link to which the information applies. The More Link ID field is set to indicate whether there are other Link ID fields to follow. For example, if the More Link ID field is set to a first state (e.g., "1"), then there are other Link ID fields to follow. Otherwise, the field is set to a second state (e.g., "0") and there are no other Link ID fields to follow.

[0148] In option 4 of Figure 34, the Link Information field can carry multiple Link ID fields. Each Link ID field is set to represent one link to which the information applies. The Last Link ID field is set to indicate whether there is another subsequent Link ID field. For example, if the Last Link ID field is set to the second state (e.g., "0"), then there is another subsequent Link ID field. Otherwise, this field is set to the first state (e.g., "1") and there is no subsequent Link ID field.

[0149] Option 5 in Figure 35 allows a Link Information field to carry multiple Link ID fields. Each Link ID field is set to represent one link to which the information applies. The Link ID fields are preceded by a Number of Link IDs field. This field is set to indicate the number of Link ID fields in the Link Information field.

[0150] Note that the format of the link information field in the ML TWT element for ML R-TWT scheduling announcement may be different from the format of the link information field in the ML TWT element for ML R-TWT configuration (membership negotiation).

[0151] In at least one embodiment / mode / option, the ML TWT indication field is not necessary because the Broadcast ML TWT parameter sets field includes the Link Information Present field and the ML TWT ID Present field. These two fields are preferably located in the reserved bits of the Broadcast TWT parameter sets field as shown in Figure 5. For example, when they are set to a second state (e.g., "0"), the Broadcast ML TWT parameter sets field is the same as the Broadcast TWT parameter sets field as shown in Figure 5.

[0152] Example This section provides several examples of ML R-TWT signaling. The network topology in these examples is shown in Figure 16. In the examples in this section, SL R-TWTx represents the SL R-TWT with link-level R-TWT ID=x, and ML R-TWTy represents the ML R-TWT with MLD-level R-TWT ID=y.

[0153] In these frame exchange examples, a pair of "{}" within a frame represents an ML TWT element. The content between the "{}" represents the content of that ML TWT element. A pair of "<>" within an ML TWT element represents a Broadcast ML TWT Parameter Set field. The content between the "<>" represents the content of the Broadcast ML TWT Parameter Set field. For example, {<SL R-TWT1,リンク1,2> ,<SL R-TWT2,リンク1>} represents an ML TWT element carrying two Broadcast ML TWT Parameter Set fields. One Broadcast ML TWT Parameter Set field is for SL R-TWT1 (SL R-TWT1 on Link 1) where SP is scheduled on Link 1, and another SL R-TWT1 (SL R-TWT1 on Link 1) where SP is scheduled on Link 2. Another Broadcast ML TWT Parameter Set field is for SL R-TWT2 (SL R-TWT2 on Link 1) where SP is scheduled on Link 1.<SL R-TWT1,ML R-TWT2,リンク1,2>} represents a ML TWT element carrying one broadcast ML TWT parameter set field for SL R-TWT1 on Link 1 and Link 2 belonging to ML R-TWT2.

[0154] 4.7.1. Link Information per Broadcast ML TWT Parameter Set Field This section also considers a scenario where there is only one link information field per broadcast ML TWT parameter set field, as shown in Figure 28. That is, there is no link information field in the control field of the ML TWT element, as shown in Figure 27.

[0155] 4.7.1.1. Implicit ML R-TWT This section considers the scenario where an implicit ML R-TWT contains one or more SL R-TWTs. Each SL R-TWT is assigned a unique link-level R-TWT ID by the R-TWT-scheduled AP on that link. The R-TWT-scheduling AP MLD does not assign an ML-level R-TWT ID to an ML R-TWT. That is, there is no Broadcast ML TWT ID field in the Broadcast ML TWT Parameter Set field as shown in Figure 28.

[0156] In the example in this section, AP1 schedules SL R-TWT4 on link 1. AP2 schedules SL R-TWT2 and SL R-TWT4 on link 2. The scheduling of SL R-TWT4 on link 1 and link 2 is the same (i.e., the SP start time, SP duration, and interval between SPs are the same), but the scheduling of SL R-TWT2 is different from the other two. According to Section 4.3, SL R-TWT4 on link 1 and link 2 can be considered as an implicit ML R-TWT, and SL R-TWT2 can be considered as another implicit ML R-TWT.

[0157] 36 illustrates an example R-TWT scheduling embodiment 610 in which an AP advertises only ML R-TWT SP scheduling on its own link. By way of example and not limitation, this figure illustrates the interaction between MLD1 70, which includes AP1 76 and AP2 78, and MLD3 74, which includes STA3 84 and STA5 88.

[0158] When AP1 transmits a beacon 614 on link 1, the beacon carries an ML TWT element. The ML TWT element carries a Broadcast ML TWT Parameter Sets field that indicates only the start 620 and duration 624 of SL R-TWT4 SP scheduling on link 1. Note that the Broadcast ML TWT Parameter Sets field of the SL R-TWT4 does not include a Link Information field that indicates that this field is for the SL R-TWT4 on link 1.

[0159] When AP2 transmits a beacon 612 on link 2, the beacon carries an ML TWT element. The ML TWT element carries two broadcast ML TWT parameter set fields: one indicating the scheduling 616 of SL R-TWT2 on link 2, and the other indicating the scheduled start 618 and duration 624 of SL R-TWT4 on link 2.

[0160] AP1 and AP2 can exchange frames with members of the SL R-TWT4 on Link 1 and Link 2 during SL R-TWT4 SPs on Link 1 620 and Link 2 618. AP1 and AP2 can exchange frames with members of the SL R-TWT4 on Link 1 and Link 2 during SL R-TWT4 SPs on Link 1 and Link 2, respectively. As shown, the SL R-TWT4 on Link 1 and Link 2 is trigger-based only. As a result, AP1 and AP2 access the channel to trigger UL and DL transmissions. Members of the SL R-TWT4 on Link 1 and Link 2 should not access the channel during SL R-TWT4 SPs on Link 1 and Link 2.

[0161] AP2 can exchange frames with members of SL R-TWT2 on Link 2 during the SL R-TWT2 SP on Link 2. As shown, the SL R-TWT2 on Link 2 is not trigger-based only. As a result, if STA5 is a member of the SL R-TWT2 on Link 2, it can contend for the channel during the SL R-TWT2 SP on Link 2, access the channel, and exchange frames with AP2.

[0162] AP1 can be seen transmitting a trigger frame (TF) 622a, and AP2 can be seen transmitting TF 622b, to which STA3 and STA5 respond with UL PPDUs 626a and 626b, respectively. Upon receiving the transmissions, the APs respond with BAs 628a and 628b. AP1 and AP2 can be seen transmitting DLMU PPDUs 630a and 630b, and receiving BAs 632a and 632b from STA3 and STA5, respectively. Each of these transmissions indicates alignment with the link of the non-simultaneous transmit / receive (NSTR) link pair. STA5 then transmits a non-triggered UL PPDU 636 within the SL R-TWT2 SP 634 on link 2 and receives BA 638 from AP2.

[0163] Note that in the above case, the Link Information field is not required. The format of the ML TWT element can be the same as the TWT element. That is, the ML TWT element can be decoded by STAs that support broadcast TWT as specified in IEEE 802.11ax. Therefore, the ML TWT element can also be used to announce broadcast TWT scheduling.

[0164] Note that if Link 1 and Link 2 are not links of an NSTR link pair, PPDU alignment in the SL R-TWT4 SP on Link 1 and Link 2 is not required.

[0165] Figure 37 illustrates an example embodiment 710 in which an R-TWT scheduling AP advertises SL R-TWT scheduling on all links. In this example, the link information field in the broadcast ML TWT parameter set field can represent multiple links. That is, the format of the link information field can be as shown in Figures 32-35. By way of example and not limitation, this figure illustrates the interaction between MLD1 70, which has AP1 76 and AP2 78, and MLD3 74, which has STA3 84 and STA5 88.

[0166] AP1 transmits a beacon 714 on Link 1 carrying an ML TWT element. The ML TWT element carries two Broadcast ML TWT Parameter Sets fields: one field indicates scheduling of SL R-TWT2 722 on Link 2, and the other field indicates scheduling of SL R-TWT4 724 on Link 1 and Link 2. The Target Wake Time field of the Broadcast ML TWT Parameter Sets field is set to the TSF time of AP1.

[0167] AP2 transmits a beacon 712 on Link 2 carrying an ML TWT element. The ML TWT element carries two Broadcast ML TWT Parameter Sets fields: one indicating the scheduling of SL R-TWT2 716 on Link 2, and the other indicating the scheduling of start 718 and duration 724 of SL R-TWT4 on Links 1 and 2. The Target Wake Time field of the Broadcast ML TWT Parameter Sets field in the ML TWT element is set to the TSF time of AP2.

[0168] The remainder of the figure is similar to FIG. 36, with AP1 transmitting a trigger frame (TF) 726a, AP2 transmitting TF 726b, to which STA3 and STA5 respond with UL PPDUs 728a and 728b, respectively. Upon receiving the transmissions, the APs respond with BAs 730a and 730b. AP1 and AP2 transmit DLMU PPDUs 732a and 732b, and can be seen receiving BAs 734a and 734b from STA3 and STA5, respectively. Each of these transmissions is shown aligned with a link in the NSTR link pair. STA5 then transmits a non-triggered UL PPDU 738 within the SL R-TWT2 SP 736 on link 2 to receive BA 740 from AP2.

[0169] Figure 38 shows another example embodiment 810 in which the R-TWT scheduling AP advertises SL R-TWT scheduling on all links. In this example, the link information field in the broadcast ML TWT parameter set field can represent only one link. That is, the format of the link information field can be as shown in Figure 31 or Figure 32 (e.g., only one bit can be set to "1"). This figure also shows, by way of example and not limitation, the interaction between MLD1 70 with AP1 76 and AP2 78 and MLD3 74 with STA3 84 and STA5 88.

[0170] AP1 transmits a beacon 814 on Link 1 carrying an ML TWT element. The ML TWT element carries three Broadcast ML TWT Parameter Set fields. The first Broadcast ML TWT Parameter Set field indicates the scheduling of SL R-TWT2 821 on Link 2. The second and third Broadcast ML TWT Parameter Set fields indicate the scheduling of the start 820 and duration 824 of SL R-TWT4 on Link 1 and Link 2. The Target Wake Time field of the Broadcast ML TWT Parameter Set field is set to the TSF time of the AP on the link indicated in the Link Information field of that Broadcast ML TWT Parameter Set field. For example, the Target Wake Time field of the Broadcast ML TWT Parameter Set field of SL R-TWT2 on Link 2 is set to the TSF time of AP2 on Link 2.

[0171] AP2 transmits a beacon 812 on link 2 carrying ML TWT elements that are identical to those in the beacon transmitted on link 1.

[0172] The remainder of the figure is similar to FIG. 36, with AP1 transmitting a trigger frame (TF) 822a, AP2 transmitting a TF 822b, to which STA3 and STA5 respond with UL PPDUs 826a and 826b, respectively. Upon receiving the transmissions, the APs respond with BAs 828a and 828b. AP1 and AP2 can be seen transmitting DLMU PPDUs 830a and 830b and receiving BAs 832a and 832b from STA3 and STA5, respectively. Each of these transmissions is shown aligned with a link in the NSTR link pair. STA5 then transmits a non-triggered UL PPDU 836 within the SL R-TWT2 SP 834 on link 2 and receives BA 838 from AP2.

[0173] Figure 39 illustrates an example embodiment 910 of R-TWT scheduling in which an AP advertises ML R-TWT scheduling for SPs on that link. In this example, the link information field in the broadcast ML TWT parameter set field can represent multiple links. That is, the format of the link information field can be as shown in Figures 32-35. This figure also illustrates, by way of example and not limitation, the interaction between MLD1 70, which has AP1 76 and AP2 78, and MLD3 74, which has STA3 84 and STA5 88.

[0174] AP1 transmits a beacon 914 carrying an ML TWT element on Link 1. Because SL R-TWT4 on Link 1 and SL R-TWT4 on Link 2 are considered ML R-TWTs, the ML TWT element carries one Broadcast ML TWT Parameter Set field that indicates the scheduling of the start 920 and duration 924 of SL R-TWT4 on Link 1 and Link 2. The Target Wake Time field of the Broadcast ML TWT Parameter Set field is set to the TSF time of AP1.

[0175] AP2 transmits a beacon 912 on Link 2 carrying an ML TWT element. The ML TWT element carries two Broadcast ML TWT Parameter Set fields: one indicating the scheduling of SL R-TWT2 916 on Link 2, and the other indicating the scheduling of the start 918 and duration 924 of SL R-TWT4 on Link 1 and Link 2, since SL R-TWT4 on Link 1 and SL R-TWT4 on Link 2 are considered ML R-TWTs. The Target Wake Time field of the Broadcast ML TWT Parameter Set field of the ML TWT element is set to the TSF time of AP2.

[0176] The remainder of the figure is similar to FIG. 38, with AP1 transmitting a trigger frame (TF) 922a, AP2 transmitting TF 922b, to which STA3 and STA5 respond with UL PPDUs 926a and 926b, respectively. Upon receiving the transmissions, the APs respond with BAs 928a and 928b. AP1 and AP2 can be seen transmitting DLMU PPDUs 930a and 930b and receiving BAs 932a and 932b from STA3 and STA5, respectively. Each of these transmissions is shown aligned with a link in the NSTR link pair. STA5 then transmits a non-triggered UL PPDU 936 within the SL R-TWT2 SP 934 on link 2 and receives BA 938 from AP2.

[0177] An example embodiment 1010 of an ML R-TWT configuration procedure is shown in Figure 40. This figure also shows, by way of example and not limitation, the interaction between MLD1 70 with AP1 76 and AP2 78 and MLD3 74 with STA3 84 and STA5 88.

[0178] The ML R-TWT membership negotiation begins with STA3 sending an ML R-TWT request frame 1014 to AP1 over Link 1 to request membership in the SL R-TWT2, which has an SP scheduled on Link 2 (1012). After receiving this request, AP1 returns an ML R-TWT response 1016 indicating that the membership request has been accepted. The ML R-TWT response 1016 may also indicate the start time 1018 of STA5's first SL R-TWT2 SP on Link 2. As a result, STA5 becomes a member STA of the SL R-TWT2. If the SL R-TWT2 is not trigger-based only, STA5 may contend for the channel during the SL R-TWT2 SP 1020 and send UL PPDUs 1024 and 1028 to AP2. The figure also shows AP2 responding to the receipt of the UL PPDU with BAs 1026 and 1030.

[0179] The spacing 1022 between SL R-TWT2 SPs on Link 2 is determined from parameters set during ML R-TWT configuration. Its purpose is to periodically indicate that the R-TWT schedule will have multiple SPs. Outside of an R-TWT SP, all STAs contend for the channel using EDCA as specified in IEEE 802.11ax, except that the R-TWT scheduled STA must end its TXOP before the start time of the next R-TWT SP.

[0180] Figure 41 illustrates an example embodiment 1110 of an ML R-TWT configuration procedure when the Link Information field is not present in the Broadcast ML TWT Parameter Sets field. This figure also illustrates, by way of example and not limitation, the interaction between MLD1 70 with AP1 76 and AP2 78 and MLD3 74 with STA3 84 and STA5 88.

[0181] The ML R-TWT membership negotiation 1112 begins with STA5 sending an ML R-TWT request frame 1114 to AP2 over link 2 to request membership in SL R-TWT2, which has an SP scheduled on link 2. After AP2 receives this request, it returns an ML R-TWT response 1116 indicating that the membership request has been accepted. The ML R-TWT response 1116 may also indicate the start time 1118 of STA5's first SL R-TWT2 SP on link 2. As a result, STA5 becomes a member STA 1122 of the SL R-TWT2. If the SL R-TWT2 is not trigger-based only, STA5 may contend for the channel during the SL R-TWT2 SP 1122 and send UL PPDUs 1124 and 1128 to AP2. The figure also shows AP2 responding to the receipt of the UL PPDU with BAs 1126 and 1130.

[0182] The spacing 1120 between SL R-TWT2 SPs on Link 2 is determined from parameters set during ML R-TWT configuration. Its purpose is to periodically indicate that the R-TWT schedule will have multiple SPs. Outside of an R-TWT SP, all STAs contend for the channel using EDCA as specified in IEEE 802.11ax, except that the R-TWT scheduled STA must end its TXOP before the start time of the next R-TWT SP.

[0183] Note that the link information field is not required in this case. The format of the ML TWT element can be the same as the TWT element. That is, the ML TWT element can be decoded by STAs that support broadcast TWT as specified in IEEE 802.11ax. Therefore, the ML TWT element can also be used for broadcast TWT configuration.

[0184] An example embodiment 1210 of an ML R-TWT configuration procedure over multiple links is shown in Figure 42. This figure also shows, by way of example and not limitation, the interaction between MLD1 70 with AP1 76 and AP2 78 and MLD3 74 with STA3 84 and STA5 88.

[0185] The ML R-TWT membership negotiation 1212 begins with STA3 sending an ML R-TWT request frame 1214 to AP1 over Link 1 to request membership in SL R-TWT2, which has SP scheduled on Link 2. After receiving this request, AP1 sends an ACK frame 1216 indicating that the request was received.

[0186] AP1 then forwards this request (not shown because it is an intra-MLD transmission) to AP2. AP2 then transmits an ML R-TWT response 1218 over link 2 indicating that the membership request has been accepted. The ML R-TWT response 1218 may also indicate the start time 1222 of STA5's first SL R-TWT2 SP on link 2. STA5 then transmits an ACK frame 1220 indicating that it has received the response and is now a member STA of the SL R-TWT2. If the SL R-TWT2 is not trigger-based only, STA5 can contend for the channel during the SL R-TWT2 SP 1226 and transmit UL PPDUs 1228 and 1232 to AP2. The figure also shows AP2 responding to the receipt of the UL PPDU with BAs 1230 and 1234.

[0187] The interval 1224 between SL R-TWT2 SPs on Link 2 is determined from parameters set during ML R-TWT configuration. Its purpose is to periodically indicate that the R-TWT schedule will have multiple SPs. Outside of an R-TWT SP, all STAs contend for the channel using EDCA as specified in IEEE 802.11ax, except that the R-TWT scheduled STA must end its TXOP before the start time of the next R-TWT SP.

[0188] Figure 43 illustrates an example embodiment 1310 of an ML R-TWT configuration procedure for ML R-TWT over one link. In this example, the ML R-TWT consists of SL R-TWT4 on link 1 and SL R-TWT4 on link 2. The Link Information field within the Broadcast ML TWT Parameter Set field can represent multiple links; that is, the format of the Link Information field can be as shown in Figures 32-35. This figure also illustrates, by way of example and not limitation, the interaction between MLD1 70 with AP1 76 and AP2 78 and MLD3 74 with STA3 84 and STA5 88.

[0189] ML R-TWT membership negotiation 1312 begins with STA3 sending an ML R-TWT request frame 1314 to AP1 over Link 1 to request membership in the SL R-TWT4 scheduled on Link 1 and Link 2. After AP1 receives this request, it sends back an ML R-TWT response frame 1316 indicating that the membership request has been accepted. The target wake time field of the broadcast ML TWT parameter set field of the SL R-TWT4 is set to indicate the start time 1318 of the first SL R-TWT4 SP for STA3 on Link 1 and STA5 on Link 2 within the TSF time of AP1 (on Link 1).

[0190] As a result, STA3 becomes a member STA of R-TWT4 on link 1, and STA5 becomes a member STA of R-TWT4 1322 on link 2. STA3 and STA5 exchange frames with AP1 and AP2, respectively, during SL R-TWT4 SPs on links 1 and 2. Thus, AP1 is shown sending DL PPDUs 1324a and 1328a and receiving BAs 1326a and 1330a from STA3, and AP2 is shown sending DL PPDUs 1324b and 1328b and receiving BAs 1326b and 1330b from STA5.

[0191] The spacing 1320 between SL R-TWT4 SPs on Link 1 is determined from parameters set during ML R-TWT configuration. Its purpose is to periodically indicate that the R-TWT schedule will have multiple SPs. Outside of an R-TWT SP, all STAs contend for the channel using EDCA as specified in IEEE 802.11ax, except that the R-TWT scheduled STA must end its TXOP before the start time of the next R-TWT SP.

[0192] Figure 44 illustrates an example embodiment 1410 of an ML R-TWT configuration procedure. In this example, the ML R-TWT consists of an SL R-TWT4 on link 1 and an SL R-TWT4 on link 2. Compared to the previous example, the link information field in the broadcast ML TWT parameter set field can represent only one link. That is, the format of the link information field can be as shown in Figure 31 or Figure 32 (e.g., only one bit can be set to "1"). This figure also illustrates, by way of example and not limitation, the interaction between MLD1 70 with AP1 76 and AP2 78 and MLD3 74 with STA3 84 and STA5 88.

[0193] The ML R-TWT membership negotiation 1412 begins with STA3 sending an ML R-TWT request frame to AP1 over Link 1 to request membership in SL R-TWT4, which is scheduled on Link 1 and Link 2. After receiving this request, AP1 sends back an ML R-TWT response frame 1416 indicating that the membership request has been accepted.

[0194] The ML R-TWT request / response frame includes an ML TWT element with two Broadcast ML TWT Parameter Set fields, one for SL R-TWT4 on Link 1 and one for SL R-TWT4 on Link 2. The Target Wake Time field of the Broadcast ML TWT Parameter Set field for SL R-TWT4 on Link 1 is set to indicate the start time 1418 of the first SL R-TWT4 SP of STA3 on Link 1 within the TSF time of AP1 (on Link 1). The Target Wake Time field of the Broadcast ML TWT Parameter Set field for SL R-TWT4 on Link 2 is set to indicate the start time 1420 of the first SL R-TWT4 SP of STA5 on Link 2 within the TSF time of AP2 (on Link 2).

[0195] As a result, STA3 becomes a member STA of R-TWT4 on link 1, and STA5 becomes a member STA of R-TWT4 on link 2. STA3 and STA5 exchange frames with AP1 and AP2, respectively, during SL R-TWT4 SPs on links 1 and 2. Specifically, AP1 is shown to send DL PPDUs 1426a and 1430a and receive BAs 1428a and 1432a from STA3, and AP2 is shown to send DL PPDUs 1426b and 1430b and receive BAs 1428b and 1432b from STA5.

[0196] The spacing 1422 between SL R-TWT4 SPs on Link 1 and Link 2 is determined from parameters set during ML R-TWT configuration. Its purpose is to periodically indicate that the R-TWT schedule will have multiple SPs. Outside of the R-TWT SPs, all STAs contend for the channel using EDCA as specified in IEEE 802.11ax, except that the R-TWT scheduled STA must end its TXOP before the start time of the next R-TWT SP.

[0197] Figure 45 illustrates an example embodiment 1510 of an ML R-TWT configuration procedure for an ML R-TWT in which only partial requests are accepted. In this example, the ML R-TWT consists of an SL R-TWT4 on link 1 and an SL R-TWT4 on link 2. In this example, the Link Information field in the Broadcast ML TWT Parameter Set field can represent only one link. That is, the format of the Link Information field can be as shown in Figure 31 or Figure 32 (e.g., only one bit can be set to "1"). This figure also illustrates, by way of example and not limitation, the interaction between MLD1 70 with AP1 76 and AP2 78 and MLD3 74 with STA3 84 and STA5 88.

[0198] The ML R-TWT membership negotiation 1512 begins with STA3 sending an ML R-TWT request frame 1514 to AP1 via Link 1 to request membership for SL R-TWT4, which is scheduled on Link 1 and Link 2. After receiving this request, AP1 returns an ML R-TWT response frame 1516 indicating that it will only accept the membership request for SL R-TWT4 on Link 2 and indicating its start time 1518.

[0199] Therefore, STA5 becomes a member STA of R-TWT4 on link 2, and STA3 is not a member STA of R-TWT4 on link 1. STA5 exchanges frames with AP2 during SL R-TWT4 SP on link 2. Specifically, AP2 is shown sending DL PPDUs 1524 and 1528 and receiving BAs 1526 and 1530 from STA5.

[0200] The interval 1520 between SL R-TWT4 SPs for Link 1 and Link 2 is determined from parameters set during ML R-TWT configuration. Its purpose is to periodically indicate that the R-TWT schedule will have multiple SPs. Outside of the R-TWT SPs, all STAs contend for the channel using EDCA as specified in IEEE 802.11ax, except that the R-TWT scheduled STA must end its TXOP before the start time of the next R-TWT SP.

[0201] 4.7.1.2 Explicit ML R-TWT In this section, we consider the scenario where an explicit ML R-TWT consists of one or more SL R-TWTs. Each SL R-TWT is assigned a unique link-level R-TWT ID by the R-TWT-scheduling AP on that link. The R-TWT-scheduling AP MLD also assigns an ML-level R-TWT ID to that ML R-TWT. Specifically, the Broadcast ML TWT ID field is present within the Broadcast ML TWT Parameter Set field as shown in Figure 28 if this field is for the SL R-TWT(s) belonging to the ML R-TWT.

[0202] In the example in this section, AP1 schedules SL R-TWT1 on link 1. MLD1 schedules ML R-TWT1, which consists of SL R-TWT2 on link 1 and link 2.

[0203] Figure 46 illustrates an example embodiment 1610 of R-TWT scheduling in which an AP announces SL R-TWT scheduling and ML R-TWT scheduling in the ML TWT element. This figure also illustrates, by way of example and not limitation, the interaction between MLD1 70 with AP1 76 and AP2 78 and MLD3 74 with STA3 84 and STA5 88.

[0204] AP1 transmits a beacon 1614 on Link 1 carrying an ML TWT element. The ML TWT element contains two broadcast ML TWT parameter set fields: one element for scheduling SL R-TWT1 1622 and a subsequent SL R-TWT1 1620 on Link 2; and the other element for SL R-TWT2 on Link 1 and Link 2.

[0205] AP2 also transmits a beacon 1612 on Link 1 carrying an SL TWT element. The SL TWT element contains two broadcast ML TWT parameter set fields: one for scheduling SL R-TWT1 1618 (same for Link 1 and Link 2) and one only for its successor 1616 on Link 2. The other element is for SL R-TWT2, which consists of SL R-TWT2 1626 on Link 1 and Link 2.

[0206] Thereafter, MLD1 can exchange frames with members of ML R-TWT1 on Link 1 and Link 2 during ML R-TWT1 SP 1626. AP2 can exchange frames with members of SL R-TWT1 on Link 2 during SL R-TWT1 SP. Specifically, AP1 can be seen to have sent TF 1624a, received UL PPDU 1628a, sent BA 1630a and DLMU PPDU 1632a, and received BA 1634a, and AP2 can be seen to have sent TF 1624b, received UL PPDU 1628b, sent BA 1630b and DLMU PPDU 1632b, and received BA 1634b.

[0207] After SL R-TWT1 SP1616 on link 2 ends, another SL R-TWT1 SP1636 on link 2 starts, with STA5 sending UL PPDU1638 and receiving BA1640.

[0208] Figure 47 illustrates an example embodiment 1710 of ML R-TWT configuration using MLD-level R-TWT ID. In this example, MLD3 recognizes (determines) that MLD1 has scheduled ML R-TWT1, which consists of SL R-TWT2 on Link 1 and Link 2 as shown in Figure 46. As a result, MLD3 can request membership for ML R-TWT1 using the MLD-level R-TWT ID. This figure also illustrates, by way of example and not limitation, the interaction between MLD1 70, with AP1 76 and AP2 78, and MLD3 74, with STA3 84 and STA5 88.

[0209] The ML R-TWT membership negotiation 1712 begins with STA3 sending an ML R-TWT request frame 1714 to AP1 over link 1 to request membership in ML R-TWT1. After receiving this request, AP1 returns an ML R-TWT response frame 1716 indicating that the membership request has been accepted, as well as a start time 1718 and an end time 1722.

[0210] Therefore, MLD3 becomes a member of ML R-TWT1. STA3 and STA5 exchange frames with AP1 and AP2, respectively, during ML R-TWT1 SP 1723 on Link 1 and Link 2. Specifically, AP1 is shown sending DL PPDUs 1720a and 1726a and receiving BAs 1724a and 1728a from STA3, and AP2 is shown sending DL PPDUs 1720b and 1726b and receiving BAs 1724b and 1728b from STA5.

[0211] The interval 1722 between ML R-TWT1 SPs on Link 1 and Link 2 is determined from parameters set during ML R-TWT configuration. Its purpose is to periodically indicate that the R-TWT schedule will have multiple SPs. Outside of the R-TWT SPs, all STAs contend for the channel using EDCA as specified in IEEE 802.11ax, except that the R-TWT scheduled STA must end its TXOP before the start time of the next R-TWT SP.

[0212] 4.7.2. Link information fields per ML TWT element In this section, we consider the same scenario as described in Section 4.7.1.1, except that there is a link information field within the control field.

[0213] Figure 48 illustrates an example embodiment 1810 of R-TWT scheduling in which an AP advertises ML R-TWT scheduling for all AP MLDs to which it belongs. In this example, the link information field in the broadcast ML TWT parameter set field can represent multiple links. That is, the format of the link information field can be as shown in Figures 32-35. This figure also illustrates, by way of example and not limitation, the interaction between MLD1 70, which includes AP1 76 and AP2 78, and MLD3 74, which includes STA3 84 and STA5 88.

[0214] AP1 transmits a beacon 1814 on Link 1 carrying two ML TWT elements. The first ML TWT element carries one broadcast ML TWT parameter set field for scheduling 1821 SL R-TWT2 1834. In the first ML TWT element, the link information field in the control field is set to "Link 2," indicating that SL R-TWT2 is scheduled on Link 2. The second ML TWT element carries one broadcast ML TWT parameter set field for SL R-TWT4. In the second ML TWT element, the link information field in the control field is set to "Link 1 and Link 2," indicating SL R-TWT4 scheduling 1820 of SL R-TWT4 1824 on Link 1 and Link 2.

[0215] AP2 transmits a beacon 1812 on Link 2 carrying two ML TWT elements. These two elements, similar to the beacon transmitted by AP1, carry SL R-TWT2 scheduling on Link 2 1816 and SL R-TWT4 scheduling on Links 1 and 2 1818.

[0216] The remainder of the figure is similar to Figure 38, with AP1 transmitting TF 1822a and AP2 transmitting TF 1822b, to which STA3 and STA5 respond with UL PPDUs 1826a and 1826b, respectively. Upon receiving the transmissions, the APs respond with BAs 1828a and 1828b. AP1 and AP2 can be seen transmitting DL MUPPDUs 1830a and 1830b, and receiving BAs 1832a and 1832b from STA3 and STA5, respectively. Each of these transmissions is shown aligned with the links of the NSTR link pair.

[0217] STA5 then sends an untriggered UL PPDU 1836 in SL R-TWT2 SP 1834 on link 2 to receive a BA 1838 from AP2.

[0218] In this example, the Target Wake Time field of the Broadcast ML TWT Parameter Sets field is set to the TSF time of the AP transmitting the Broadcast ML TWT Parameter Sets field. For example, the Target Wake Time field of the Broadcast ML TWT Parameter Sets field transmitted on Link 1 is set to the TSF time of AP1 on Link 1. The Target Wake Time field of the Broadcast ML TWT Parameter Sets field transmitted on Link 2 is set to the TSF time of AP2 on Link 2.

[0219] 4.8.ML R-TWT Operation over Special MLD Links This section describes some ML R-TWT operations over specialized MLD links, such as enhanced Multi-Link Single-Radio (eMLSR) links, enhanced Multi-Link Multi-Radio (eMLMR) links, and Non-Simultaneous Transmit-Receive (NSTR) links.

[0220] Figure 49 illustrates an example embodiment 1910 of ML R-TWT operation over special MLD links. The network topology for this example is shown in Figure 16. This example considers a scenario in which (a) MLD1 and MLD3 operate in eMLSR mode on Link 1 and Link 2, or (b) MLD1 and MLD3 operate in eMLMR mode, with Link 1 and Link 2 being eMLMR links, or (c) MLD3 is an NSTR MLD, with Link 1 and Link 2 being an NSTR link pair for MLD3. This figure also illustrates, by way of example and not limitation, the interaction between MLD1 70, with AP1 76 and AP2 78, and MLD3 74, with STA3 84 and STA5 88.

[0221] In ML R-TWT setup 1912, STA3 requests membership (1914), and AP1 responds with an ML R-TWT response 1916 that schedules only SL R-TWT4 on link 2, including a schedule 1918 and a period 1922. Non-AP MLD3 negotiates membership for SL R-TWT4 with AP MLD1, and STA5 becomes a member of SL R-TWT4. STA5 can exchange frames with AP2 during the SL R-TWT4 SP. As a result, STA3 must end its TXOP (1919) on link 1 before the start time of the R-TWT4 SP, and may not be able to access channel 1920 on link 1 until the R-TWT4 SP ends or until STA5 finishes exchanging frames with AP2 during the R-TWT4 SP.

[0222] Considering the delay of eMLSR / eMLMR, STA3 needs to end the TXOP on link 1 eMLSR / eMLMR a given delay time before the start time of R-TWT4 SP. AP1 cannot transmit to STA3 on link 1 until R-TWT4 SP ends. It is recognized that this delay time can be specified in the relevant EML capability field and indicated in the association procedure.

[0223] The communication can be seen with AP2 completing a backoff (BO) 1926, sending a MU request to send (RTS) 1928, and receiving a clear to send (CTS) 1930 from STA5. AP2 then sends a DL PPDU 1932, which STA5 receives and then sends a BA 1934. After the interval between SL R-TWT4 SPs 1924, another SL R-TWT4 1936 on link 2 can begin.

[0224] It should be understood that a similar condition applies to the AP acting as a TXOP and having to ensure that the TXOP is terminated within a given time before the start of the R-TWT SP on the first special link.

[0225] 5. General Scope of Embodiments Embodiments of the present technology may be described herein with reference to flowcharts of methods and systems according to embodiments of the present technology, and / or procedures, algorithms, steps, operations, formulas, or other computational expressions, which may also be implemented as computer program products. In this regard, each block or step of the flowcharts, and combinations of blocks (and / or steps) of the flowcharts, and any procedures, algorithms, steps, operations, formulas, or computational expressions, may be implemented by various means, such as hardware, firmware, and / or software that includes one or more computer program instructions embodied in computer-readable program code. It will be appreciated that any such computer program instructions may be executed by one or more computer processors, including, but not limited to, a general-purpose computer or a special-purpose computer, or any other programmable processing device to produce a machine, such that the computer program instructions executing on the computer processor or other programmable processing device produce means for performing the specified function(s).

[0226] Thus, the flowchart blocks and procedures, algorithms, steps, operations, formulas, or computational expressions described herein support combinations of means for performing a particular function(s), combinations of steps for performing a particular function(s), and computer program instructions for performing a particular function(s) as embodied in computer-readable program code logic means. It will also be understood that each flowchart block and any procedures, algorithms, steps, operations, formulas, or computational expressions described herein, and combinations thereof, can also be implemented by a dedicated hardware-based computer system that performs the particular function(s) or step(s), or a combination of dedicated hardware and computer-readable program code.

[0227] Furthermore, these computer program instructions, embodied in computer-readable program code or the like, may be stored in one or more computer-readable memories or memory devices that can direct a computer processor or other programmable processing device to function in a particular manner, such that the instructions stored in these computer-readable memories or memory devices produce an article of manufacture that includes instruction means for performing the functions specified in the flowchart(s). The computer program instructions may be executed by the computer processor or other programmable processing device to cause a series of operational steps to be performed on the computer processor or other programmable processing device to generate a computer-implemented process, such that the instructions executing on the computer processor or other programmable processing device provide steps for performing the function specified in the flowchart(s) block(s), procedure(s), algorithm(s), step(s), operation(s), mathematical formula(s), or computational expression(s).

[0228] Furthermore, as used herein, the terms "program" or "program executable" will be understood to mean one or more instructions executable by one or more computer processors to perform one or more functions described herein. The instructions may be embodied in software, firmware, or a combination of software and firmware. The instructions may be stored locally on a non-transitory medium of the device or remotely, such as on a server, or all or a portion of the instructions may be stored locally or remotely. Remotely stored instructions may be downloaded (pushed) to the device upon user initiation or automatically based on one or more factors.

[0229] Furthermore, as used herein, the terms processor, hardware processor, computer processor, central processing unit (CPU), and computer are used interchangeably to refer to devices capable of executing instructions and communicating with input / output interfaces and / or peripheral devices, and it will be understood that the terms processor, hardware processor, computer processor, CPU, and computer are intended to include single or multiple devices, single-core devices and multi-core devices, and variations thereof.

[0230] From the description herein, it will be understood that the present disclosure encompasses multiple technology implementations, including but not limited to the following.

[0231] An apparatus for wireless communication in a network, the apparatus comprising: (a) wireless communication circuitry as an independent wireless station (STA) or an STA within a multilink device (MLD), operating as either a normal STA or an access point (AP) STA that communicates wirelessly with other wireless stations (STAs) using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN) where enhanced distributed channel access (EDCA) is utilized for random channel access on all links; (b) a processor coupled to the wireless communication circuitry and operating on the WLAN; and (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs, the instructions, when executed by the processor, causing: (d)(i) an AP station having a service period (SP) scheduled on multiple links to schedule a multilink (ML) restricted target wake time (R-TWT); and (d)(ii) an ML station to negotiate membership in an ML R-TWT from a non-AP multilink device (MLD). and (d)(iii) the AP MLD responding to the ML R-TWT request frame with an ML R-TWT response frame indicating acceptance or rejection of the request in the ML R-TWT request frame from the non-AP MLD, and (d)(iv) if the AP MLD accepts the request, the non-AP MLD becomes a member of an ML R-TWT protocol.

[0232] An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit, which is an independent wireless station (STA) or an STA in a multilink device (MLD), operating as either a normal STA or an access point (AP) STA that communicates wirelessly with other wireless stations (STAs) using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN) where enhanced distributed channel access (EDCA) is utilized for random channel access on all links; (b) a processor coupled to the wireless communication circuit and operating on the WLAN; and (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs, wherein (d) the instructions, when executed by the processor, perform steps of a wireless communication protocol for the wireless communication circuit, including: (d)(i) a non-AP STA transmitting a frame including an ML target wake time (TWT) element for a multilink (ML) restricted target wake time (R-TWT); (d)(ii) the ML TWT element carries one or more broadcast ML TWT parameter set fields; and (d)(iii) a non-AP STA transmitting a frame including an ML target wake time (TWT) element for a multilink (ML) restricted target wake time (R-TWT). The TWT element includes link information indicating which links the information in the Broadcast ML TWT Parameter Set field applies to when an R-TWT schedule is scheduled on only some links, the device.

[0233] An apparatus for wireless communication in a network, the apparatus comprising: (a) wireless communication circuitry as an STA, which is an independent wireless station (STA) or an STA in a multilink device (MLD), operating as either a normal STA or an access point (AP) STA that communicates wirelessly with other wireless stations (STAs) using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN) where enhanced distributed channel access (EDCA) is utilized for random channel access on all links; (b) a processor coupled to the wireless communication circuitry and operating on the WLAN; and (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs, the instructions, when executed by the processor, causing: (d)(i) an AP station that has a service period (SP) scheduled on multiple links to set a multilink (ML) restricted target wake time (R-TWT), and a non-AP multilink device (MLD) that has a service period (SP) scheduled on multiple links to set a multilink (MLD) restricted target wake time (R-TWT). and (d)(ii) scheduling communication over a special MLD link for a first station on a first MLD; and (d)(iii) requiring that a second station on the first MLD must terminate a transmit opportunity (TXOP) with a given delay period remaining before initiating frame exchange over the special MLD link by the first station on the first MLD.

[0234] A wireless communication system / device to which CSMA / CA is applied, which performs packet transmission, and includes: (a) an AP MLD scheduling an ML R-TWT in which an SP is scheduled on multiple links; (b) a non-AP MLD transmitting an ML R-TWT request frame to negotiate membership of the ML R-TWT; (c) the AP MLD responding with an ML R-TWT response frame to accept or reject the request from the non-AP MLD; and (d) if the AP MLD accepts the request, the non-AP MLD becomes a member of the ML R-TWT.

[0235] A wireless communication system / device to which CSMA / CA is applied, which performs packet transmission, and which includes: (a) an STA transmitting a frame including an ML TWT element for ML R-TWT signaling; (b) the ML TWT element carrying one or more broadcast ML TWT parameter set fields; and (c) the ML TWT element including link information indicating to which link the information in the broadcast ML TWT parameter set field applies.

[0236] An apparatus, method, or system of any preceding implementation, wherein the AP MLD can announce the scheduling of the ML R-TWT in a beacon frame, a (ML) probe response frame, a (re)association frame, or a ML R-TWT scheduling announcement frame.

[0237] Any prior implementation of an apparatus, method, or system, wherein an AP belonging to an AP MLD can only announce the scheduling of ML R-TWT SPs on its own link.

[0238] An apparatus, method, or system of any preceding implementation, wherein an AP belonging to an AP MLD can announce the scheduling of all ML R-TWTs scheduled by the AP MLD.

[0239] An apparatus, method, or system of any preceding implementation, in which an AP belonging to an AP MLD can only announce the scheduling of ML R-TWTs for which some SPs are scheduled on the same link of the AP.

[0240] An apparatus, method, or system of any preceding implementation, wherein an AP belonging to an AP MLD can announce scheduling of ML R-TWT and SL R-TWT in the same frame.

[0241] An apparatus, method, or system of any preceding implementation, wherein an ML R-TWT can consist of one or more SL R-TWTs scheduled on different links by APs belonging to an AP MLD.

[0242] The apparatus, method, or system of any preceding implementation, wherein the AP MLD can assign a unique ML-level R-TWT ID to the ML R-TWT to identify the ML R-TWT.

[0243] The apparatus, method, or system of any preceding implementation, wherein the AP MLD can assign the same SL level R-TWT ID to an SL R-TWT to indicate that the SL R-TWTs of the ML R-TWT belong to the same ML R-TWT.

[0244] An apparatus, method, or system of any preceding implementation, wherein an SL R-TWT having the same SL level R-TWT ID within the same ML TWT element can be considered as an ML R-TWT.

[0245] An apparatus, method, or system of any preceding implementation, in which an SL R-TWT with the same SP scheduling, e.g., the same SP start time, SP period, and SP interval, on a different link can be considered as an ML R-TWT.

[0246] The apparatus of claim 1 , wherein SL R-TWTs having the same ML level R-TWT ID can be considered as ML R-TWTs.

[0247] The apparatus, method, or system of any preceding implementation, wherein the ML R-TWT request frame or response frame may include link information indicating the link to which the corresponding ML R-TWT parameters apply.

[0248] The apparatus, method, or system of any preceding implementation, wherein the ML R-TWT request or response frame may include one or more ML TWT elements that convey ML R-TWT information for one or more links.

[0249] An apparatus, method, or system of any preceding implementation, wherein an AP MLD can accept an ML R-TWT membership request on a partial link of the ML R-TWT.

[0250] An apparatus, method, or system of any preceding implementation, wherein membership negotiation for the ML R-TWT can occur before the AP MLD announces scheduling of the ML R-TWT.

[0251] An apparatus, method, or system of any preceding implementation in which the ML TWT element can share the same element ID as the TWT element.

[0252] Any preceding implementation of an apparatus, method, or system, wherein the ML TWT element may carry one link information field that indicates to which link the information in all broadcast ML TWT parameter sets fields applies.

[0253] Any preceding implementation of an apparatus, method, or system, wherein each link information field may carry one link information field indicating which link the information applies to.

[0254] An apparatus, method, or system of any preceding implementation, wherein the AP MLD can announce the scheduling of the ML R-TWT in a beacon frame, a (ML) probe response frame, a (re)association frame, or a ML R-TWT scheduling announcement frame.

[0255] Any prior implementation of an apparatus, method, or system, wherein an AP belonging to an AP MLD can only announce the scheduling of ML R-TWT SPs on its own link.

[0256] An apparatus, method, or system of any preceding implementation, wherein an AP belonging to an AP MLD can announce the scheduling of all ML R-TWTs scheduled by the AP MLD.

[0257] An apparatus, method, or system of any preceding implementation, in which an AP belonging to an AP MLD can only announce the scheduling of ML R-TWTs for which some SPs are scheduled on the same link of the AP.

[0258] An apparatus, method, or system of any preceding implementation, wherein an AP belonging to an AP MLD can announce scheduling of ML R-TWT and SL R-TWT in the same frame.

[0259] An apparatus, method, or system of any preceding implementation, wherein an ML R-TWT can consist of one or more SL R-TWTs scheduled on different links by APs belonging to an AP MLD.

[0260] The apparatus, method, or system of any preceding implementation, wherein the AP MLD can assign a unique ML-level R-TWT ID to the ML R-TWT to identify the ML R-TWT.

[0261] The apparatus, method, or system of any preceding implementation, wherein the AP MLD can assign the same SL level R-TWT ID to an SL R-TWT to indicate that the SL R-TWTs of the ML R-TWT belong to the same ML R-TWT.

[0262] An apparatus, method, or system of any preceding implementation, wherein an SL R-TWT having the same SL level R-TWT ID within the same ML TWT element can be considered as an ML R-TWT.

[0263] An apparatus, method, or system of any preceding implementation, in which an SL R-TWT with the same SP scheduling, e.g., the same SP start time, SP period, and SP interval, on a different link can be considered as an ML R-TWT.

[0264] An apparatus, method, or system of any preceding implementation, wherein an SL R-TWT having the same ML level R-TWT ID can be considered as an ML R-TWT.

[0265] The apparatus, method, or system of any preceding implementation, wherein the ML R-TWT request frame or response frame may include link information indicating the link to which the corresponding ML R-TWT parameters apply.

[0266] The apparatus, method, or system of any preceding implementation, wherein the ML R-TWT request or response frame may include one or more ML TWT elements that convey ML R-TWT information for one or more links.

[0267] An apparatus, method, or system of any preceding implementation, wherein an AP MLD can accept an ML R-TWT membership request on a partial link of the ML R-TWT.

[0268] An apparatus, method, or system of any preceding implementation, wherein membership negotiation for the ML R-TWT can occur before the AP MLD announces scheduling of the ML R-TWT.

[0269] An apparatus, method, or system of any preceding implementation in which the ML TWT element can share the same element ID as the TWT element.

[0270] Any preceding implementation of an apparatus, method, or system, wherein the ML TWT element may carry one link information field that indicates to which link the information in all broadcast ML TWT parameter sets fields applies.

[0271] Any preceding implementation of an apparatus, method, or system, wherein each link information field may carry one link information field indicating which link the information applies to.

[0272] The apparatus, method, or system of any preceding implementation, wherein the special MLD link comprises a non-simultaneous transmit-receive (NSTR) link.

[0273] The apparatus, method, or system of any preceding implementation, wherein the special MLD link includes an enhanced Multi-Link Single Radio (eMLSR) link.

[0274] The apparatus, method, or system of any preceding implementation, wherein the special MLD link includes an enhanced Multi-Link Multi-Radio (eMLMR) link.

[0275] The term "implementation," as used herein, is intended to include, without limitation, any embodiment, example, or other form for practicing the techniques described herein.

[0276] As used herein, the singular forms "a," "an," and "the" include plural references unless the context clearly indicates otherwise. Reference to an object in the singular does not mean "one and only one" unless expressly stated otherwise, but rather "one or more."

[0277] In this disclosure, phrases such as "A, B, and / or C" indicate that either A, B, or C, or any combination of items A, B, and C, can be present. Phrases such as "at least one of" followed by a group of listed elements indicate that at least one of the group of elements is present, including, where applicable, any possible combination of the listed elements.

[0278] References in this disclosure to "one embodiment," "at least one embodiment," or similar embodiment phrases indicate that a particular feature, structure, or characteristic described in connection with the described embodiment is included in at least one embodiment of the disclosure. Thus, these references to various embodiments do not necessarily refer to all the same embodiment, or to a specific embodiment that is different from all other embodiments described. Reference to an embodiment should be interpreted to mean that the particular feature, structure, or characteristic of a given embodiment can be combined in any suitable manner in one or more embodiments of the disclosed device, system, or method.

[0279] As used herein, the term "set" means a collection of one or more objects. Thus, for example, a set of objects can include a single object or multiple objects.

[0280] Relative terms such as first and second, top and bottom, upper and lower, and left and right in this document are used merely to distinguish one entity or action from another and do not necessarily require or imply any such actual relationship or ordering between such entities or actions.

[0281] The terms "comprises, compris- ing, has, having, includes, including, contains, containing," or any other variations of these terms are intended to cover non-exclusive inclusions, and thus a process, method, article, or apparatus that comprises, has, or includes a list of elements does not include only those elements, but may also include other elements not expressly listed or that are inherent to such process, method, article, or apparatus. An element following "comprises ... a, has ... a, includes ... a, contains ... a" does not exclude, without further constraints, the presence of additional identical elements in the process, method, article, or apparatus that comprises, has, or includes that element.

[0282] As used herein, the terms “approximately,” “approximate,” “substantially,” “essentially,” and “about,” or any variation thereof, are used to describe and explain slight variations. When used in connection with events or circumstances, these terms can mean that the events or circumstances will definitely occur and that the events or circumstances are highly likely to occur. When used in connection with a numerical value, these terms can mean a variation range of ±10% or less, such as ±5% or less, ±4% or less, ±3% or less, ±2% or less, ±1% or less, ±0.5% or less, ±0.1% or less, or ±0.05% or less of the numerical value. For example, “substantially” aligned can mean an angular variation range of ±10° or less, such as ±5° or less, ±4° or less, ±3° or less, ±2° or less, ±1° or less, ±0.5° or less, ±0.1° or less, or ±0.05° or less.

[0283] Additionally, amounts, ratios, and other numerical values ​​may be presented in range format herein. Such range formats are used for convenience and simplicity, and should be understood to include numerical values ​​explicitly specified as the limits of the range, but also to include all individual numerical values ​​or subranges within the range, as if each such numerical value and subrange were expressly set forth. For example, a ratio within the range of about 1 to about 200 should be understood to include the explicitly recited limits of about 1 and about 200, but also to include individual ratios such as about 2, about 3, and about 4, as well as subranges such as about 10 to about 50 and about 20 to about 100.

[0284] The term "coupled," as used herein, is defined as connected, but not necessarily by a direct mechanical connection. A device or structure that is "configured" in a particular way is configured in at least that way, but may also be configured in unlisted ways.

[0285] Benefits, advantages, solutions to problems, and any element(s) that cause or make more pronounced any benefit, advantage, or solution should not be construed as a critical, necessary, or essential feature or element of the technology described herein or any or all of the claims.

[0286] Also, in the foregoing disclosure, various features may be grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Inventive subject matter may comprise less than all features of a single disclosed embodiment.

[0287] The Abstract of the Disclosure is intended to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.

[0288] It is understood that some jurisdictions have a practice of requiring the deletion of one or more portions of the disclosure after filing. Accordingly, the reader should refer to the application as of its filing date for the original content of the disclosure. The deletion of any of the disclosed content should not be construed as an abandonment, forfeiture, or dedication to the public of any subject matter of the application as originally filed.

[0289] The following claims are hereby incorporated into this disclosure, with each claim standing on its own as a separate inventive subject matter.

[0290] Although the description herein contains many details, these should not be construed as limiting the scope of the disclosure, but merely as exemplifying some of the presently preferred embodiments, and therefore, the scope of the disclosure will be understood to fully encompass other embodiments that may become apparent to those skilled in the art.

[0291] Structural and functional equivalents of elements of embodiments of the present disclosure known to those skilled in the art are also expressly incorporated herein by reference and are intended to be within the scope of the claims. Furthermore, no elements, components, or method steps of the present disclosure are intended to be publicly disclosed, regardless of whether they are explicitly recited in the claims. No claim element herein should be construed as a "means-plus-function" element unless the element is expressly recited using the phrase "means for." Also, no claim element herein should be construed as a "step-plus-function" element unless the element is expressly recited using the phrase "step for." [Explanation of symbols]

[0292] 132 The R-TWT scheduled MLD will negotiate with the R-TWT scheduling AP MLD over a link, e.g., link 1, regarding ML R-TWT membership. 134 A STA belonging to the MLD to which the R-TWT is scheduled sends an ML R-TWT request frame carrying the broadcast ML TWT parameter set field of its ML R-TWT in the ML TWT element over a link such as link 1. 136 Has the R-TWT scheduled AP MLD received an ML TWT response frame indicating that the R-TWT scheduled AP MLD accepts the membership request? 138 The MLD receiving the R-TWT schedule is a member of that ML R-TWT. 140 The MLD receiving the R-TWT schedule is not a member of the MLD R-TWT.

Claims

1. 1. An apparatus for wireless communication in a network, comprising: (a) a wireless communication circuit as an independent wireless station (STA) or an STA in a multi-link device (MLD) that operates as either a normal STA or an access point (AP) STA that communicates wirelessly with other wireless stations (STAs) using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is used for random channel access on all links; (b) a processor coupled to the wireless communication circuitry for operating on the WLAN; (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs; (d) the instructions, when executed by the processor, (i) an AP station, whose service period (SP) is scheduled on multiple links, schedules a multi-link (ML) restricted target wake time (R-TWT); (ii) receiving an ML R-TWT request frame from a non-AP multi-link device (MLD) to negotiate membership in an ML R-TWT; (iii) the AP's MLD responding to the MLR-TWT request frame with an MLR-TWT response frame indicating acceptance or rejection of the request in the MLR-TWT request frame from the non-AP MLD; performing steps of a wireless communication protocol for said wireless communication circuit, including: (iv) if the AP MLD accepts the request, the non-AP MLD becomes a member of the MLD R-TWT; An ML R-TWT may consist of one or more SL R-TWTs scheduled on different links by the AP station; An apparatus characterized in that

2. The AP MLD may announce the scheduling of the ML R-TWT in a beacon frame, a (ML) probe response frame, a (re)association frame, or a ML R-TWT scheduling announcement frame; 10. The apparatus of claim 1.

3. An AP belonging to the AP MLD can only announce the scheduling of MLR R-TWT SPs on its own link.

10. The apparatus of claim 1.

4. An AP belonging to the AP MLD can announce the scheduling of all ML R-TWTs scheduled by the AP MLD; 10. The apparatus of claim 1.

5. An AP belonging to the AP MLD can only announce the scheduling of MLR R-TWTs on which some SPs are scheduled on the same link of the AP; 10. The apparatus of claim 1.

6. APs belonging to the AP MLD can announce the scheduling of ML R-TWT and SL R-TWT in the same frame; 10. The apparatus of claim 1.

7. The AP MLD can assign a unique ML-level R-TWT ID to the ML R-TWT to identify the ML R-TWT; 10. The apparatus of claim 1.

8. The AP MLD may assign the same SL level R-TWT ID to the SL R-TWT of the ML R-TWT to indicate that the SL R-TWT belongs to the same ML R-TWT; 10. The apparatus of claim 1.

9. SL R-TWTs with the same SL level R-TWT ID within the same ML TWT element can be considered as an ML R-TWT; 10. The apparatus of claim 1.

10. SL R-TWTs with the same SP scheduling, e.g., the same SP start time, SP period, and SP interval, on different links can be considered as ML R-TWTs.

10. The apparatus of claim 1.

11. An SL R-TWT with the same ML level R-TWT ID can be considered as an ML R-TWT.

10. The apparatus of claim 1.

12. The ML R-TWT request or response frame may include link information indicating the link to which the corresponding ML R-TWT parameters apply; 10. The apparatus of claim 1.

13. An ML R-TWT request or response frame may include one or more ML TWT elements that carry ML R-TWT information for one or more links; 10. The apparatus of claim 1.

14. The AP MLD can accept ML R-TWT membership requests on the partial links of the ML R-TWT; 10. The apparatus of claim 1.

15. The membership negotiation of the ML R-TWT can take place before the AP MLD announces the scheduling of said ML R-TWT; 10. The apparatus of claim 1.

16. 1. An apparatus for wireless communication in a network, comprising: (a) a wireless communication circuit as an independent wireless station (STA) or an STA in a multi-link device (MLD) that operates as either a normal STA or an access point (AP) STA that communicates wirelessly with other wireless stations (STAs) using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is used for random channel access on all links; (b) a processor coupled to the wireless communication circuitry for operating on the WLAN; (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs; (d) the instructions, when executed by the processor, (i) a non-AP STA transmits a frame including a Multilink (ML) Target Wake Time (TWT) element for a Multilink (ML) Restricted Target Wake Time (R-TWT); performing steps of a wireless communication protocol for said wireless communication circuit, including: (ii) the ML TWT element carries one or more Broadcast ML TWT parameter set fields; (iii) the ML TWT element includes link information indicating to which links the information in the Broadcast ML TWT Parameter Set field applies when R-TWT schedules are scheduled on only some links; An ML R-TWT may consist of one or more SL R-TWTs scheduled on different links by the non-AP STAs; An apparatus characterized in that

17. The ML TWT element may share the same element ID as a TWT element.

17. The apparatus of claim 16.

18. The ML TWT element may carry one Link Information field that indicates to which link the information in all Broadcast ML TWT Parameter Set fields applies.

17. The apparatus of claim 16.

19. Each link information field may carry one link information field indicating which link the information applies to.

17. The apparatus of claim 16.

20. 1. An apparatus for wireless communication in a network, comprising: (a) a wireless communication circuit as an independent wireless station (STA) or an STA in a multi-link device (MLD) that operates as either a normal STA or an access point (AP) STA that communicates wirelessly with other wireless stations (STAs) using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN) in which enhanced distributed channel access (EDCA) is used for random channel access on all links; (b) a processor coupled to the wireless communication circuitry for operating on the WLAN; (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs; (d) the instructions, when executed by the processor, (i) an AP station whose service period (SP) is scheduled on multiple links configures a multi-link (ML) restricted target wake time (R-TWT), and a non-AP multi-link device (MLD) can negotiate membership in the ML R-TWT; (ii) scheduling a communication of a first station on a first MLD over a special MLD link; (iii) requiring that a second station of the first MLD must terminate a transmission opportunity (TXOP) with a given delay period remaining before a first station of the first MLD initiates frame exchange over the special MLD link; performing steps of a wireless communication protocol for said wireless communication circuit, including: An ML R-TWT may consist of one or more SL R-TWTs scheduled on different links by the AP station; An apparatus characterized in that

21. The special MLD link includes a non-simultaneous transmit-receive (NSTR) link.

21. The apparatus of claim 20.

22. The special MLD link includes an enhanced Multi-Link Single Radio (eMLSR) link.

21. The apparatus of claim 20.

23. The specialized MLD link includes an enhanced Multi-Link Multi-Radio (eMLMR) link.

21. The apparatus of claim 20.

Images