CN116889071A - Limited target wake time service period expiration - Google Patents

Abstract

The present application relates to a wireless communication protocol using CSMA/CA, EDCA and R-TWT to prioritize RTA traffic transmissions. RTA traffic is preferentially transmitted during the R-TWT SP and provides a mechanism for ensuring proper indication and termination of the R-TWT SP. During this process, when an member STA has no more frames to send, it communicates with the R-TWT scheduling AP. The R-TWT scheduling AP may also terminate the R-TWT SP before its scheduled end time, allowing non-member STAs to contend for the channel immediately. In addition, after completing frame exchanges with the R-TWT member STA during the R-TWT SP, the R-TWT scheduling AP may exchange frames with an STA having the R-TWT characteristics but not the R-TWT member STA.

Description

Limited target wake time service period expiration

Cross Reference to Related Applications

The present application claims the priority and benefit of U.S. patent application Ser. No. 17/844,555, filed on 6/20/2022, incorporated herein by reference in its entirety. The present application claims priority and benefit from U.S. provisional patent application Ser. No. 63/260,155, filed on 8/11/2021, incorporated herein by reference in its entirety.

Statement regarding federally sponsored research or development in the united states

Is not suitable for

Reminder for copyrighted material

Some of the material in this patent document is subject to copyright protection under the copyright laws of the united states and other countries. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the patent and trademark office patent file or records, but otherwise reserves all copyright rights whatsoever. The copyright owner does not disclaim any rights to keep this patent document secret, including but not limited to rights in accordance with 37 c.f.r. ≡1.14.

Background

1. Technical field

The technology of the present disclosure relates generally to wireless local area networks using CSMA/CA, and more particularly to terminating a limited target wake time (R-TWT) Service Period (SP).

2. Discussion of the background art

Current wireless technologies using CSMA/CA focus on achieving high throughput network performance, but lack low latency capability. Many applications, such as real-time applications (RTAs), however, require low latency.

Real-time applications require low latency communications and use best effort communications. The data generated from the RTA is referred to as RTA traffic (traffic) and will be packetized into RTA frames at the sender STA. In contrast, data generated from non-time sensitive applications is referred to as non-RTA traffic and will be packetized into non-RTA frames at the sender STA. The transmitting STA then transmits the packet within the frame to the receiver STA over the channel.

RTA frames require low latency due to their high timeliness requirements for delivery. RTA frames are valid when delivered within a specific time period. One solution in the CSMA/CA wireless protocol is to schedule a Service Period (SP) for a limited target wake-up time (R-TWT) for an RTA frame exchange. During R-TWT SP, RTA frames have a higher transmission priority than other frames. But may present R-TWT problems with efficiency and fair use.

Thus, there is a need for improved R-TWT operation. The present disclosure meets this need and provides additional R-TWT benefits.

Disclosure of Invention

Current wireless communication systems, such as under IEEE 802.11be, utilize EDCA and R-TWT to prioritize RTA traffic transmissions. During R-TWT SP, RTA traffic is sent preferentially. But because the R-TWT SP duration is pre-scheduled and declared, in some cases the R-TWT SP duration may eventually be longer than the transmission time required by the R-TWT member STAs.

The present disclosure describes the following protocols: the protocol includes a mechanism for communicating that the R-TWT SP has ended immediately after all RTA traffic is sent during the R-TWT SP; and the protocol addresses the R-TWT scheduling challenge of identifying APs of the transmitted RTA frame (which may be UL, DL or P2P).

Therefore, in order to improve the efficiency of channel usage and avoid the problem of fair use (abuse) of the R-TWT SP, the R-TWT SP should be terminated immediately after the RTA frame exchange is completed.

In this disclosure, the R-TWT schedules the AP and the member STAs of the R-TWT negotiate which traffic to schedule and prioritize the traffic during the R-TWT SP.

In this disclosure, a member STA may send a signal to the R-TWT scheduling AP during the R-TWT SP to indicate that it no longer has any scheduled UL and/or P2P to transmit during the R-TWT SP.

In the present disclosure, after all scheduled traffic is transmitted during the R-TWT SP, the R-TWT scheduling AP may transmit a signal to other STAs indicating termination of the R-TWT SP.

In the present disclosure, after the completion of all scheduled traffic transmissions during the R-TWT SP, the R-TWT scheduling AP may share the remaining time of the R-TWT SP for frame exchanges with STAs that are R-TWT scheduled STAs but are not member STAs of the R-TWT.

More specifically, in at least one embodiment of the present disclosure, an R-TWT scheduling AP and an R-TWT member STA begin an R-TWT SP for frame exchange therebetween. When there are no more frames to transmit during the R-TWT SP, the R-TWT member STA transmits a signal to the R-TWT scheduling AP. When all frame exchanges are implemented during the R-TWT SP, the R-TWT schedule AP sends a signal to indicate the termination of the R-TWT SP.

In at least one other embodiment of the present disclosure, an R-TWT scheduling AP and an R-TWT member STA begin an R-TWT SP for implementing frame exchanges therebetween. The R-TWT scheduling AP terminates the R-TWT SP before the scheduled end time of the R-TWT SP. STAs that are not member STAs of the R-TWT begin contending for the channel immediately after the R-TWT SP is terminated.

In at least another embodiment of the present disclosure, the R-TWT schedules the AP and the R-TWT member STA to start the R-TWT SP. The R-TWT scheduling AP exchanges frames with the R-TWT member STA during the R-TWT SP. The R-TWT schedules the AP to exchange frames with a STA that is not an R-TWT member STA and implements the R-TWT feature after ending the frame exchange with the R-TWT member STA during the R-TWT SP. There are many additional elements and benefits of the present disclosure.

Additional aspects of the technology described herein will be brought forth in the description which follows, wherein the detailed description is for the purpose of fully disclosing preferred embodiments of the technology without placing limitations thereon.

Drawings

The techniques described herein will be more fully understood by reference to the accompanying drawings, in which:

fig. 1 is a data field diagram of a TSPEC element as defined in IEEE 802.11.

Fig. 2 is a data field diagram of contents in the TS information field as shown in fig. 1.

Fig. 3 is a data field diagram of the contents of a TCLAS element as defined in IEEE 802.11.

Fig. 4 is a data field diagram of the contents of a TCLAS processing unit as defined in IEEE 802.11.

Fig. 5 is a data field diagram of a TWT unit defined in IEEE 802.11 ax.

Fig. 6 is a data field diagram of the control field of the TWT unit as shown in fig. 5.

Fig. 7 is a data field diagram of a broadcast TWT parameter information field valid for a particular negotiation type.

Fig. 8 is a data field diagram of a request type field in a broadcast TWT parameter information field.

Fig. 9 is a data field diagram of a broadcast TWT information field of the broadcast TWT parameter information field of fig. 7.

Fig. 10 is a communication diagram of SCS setting defined in IEEE 802.11be (draft p802.11be_d1.01).

Fig. 11 is a data field diagram of an SCS request frame.

Figure 12 is a data field diagram of SCS descriptor elements from the SCS status list field seen in figure 11.

Fig. 13 is a data field diagram of a format for an SCS response frame.

Figure 14 is a data field diagram of SCS status subfield.

Fig. 15 is a communication diagram of TWT settings as defined in IEEE 802.11 ax.

Fig. 16 is a data field diagram of a TWT setting frame.

FIG. 17 is a communication diagram of R-TWT SP communications.

Fig. 18 is a hardware block diagram of Station (STA) hardware in accordance with at least one embodiment of the present disclosure.

Fig. 19 is a hardware block diagram of a multi-link device (MLD) hardware configuration in accordance with at least one embodiment of the present disclosure.

Fig. 20 is a network topology of an exemplary network in accordance with at least one embodiment of the present disclosure.

FIG. 21 is a communication diagram of R-TWT member settings in accordance with at least one embodiment of the present disclosure.

Figure 22 is a data field diagram of a TWT setup frame with SCS traffic information in accordance with at least one embodiment of the disclosure.

FIG. 23 is a flow chart of an R-TWTx SP terminated by an R-TWT scheduling AP according to at least one embodiment of the present disclosure.

Fig. 24-26 are flowcharts of R-TWTx member STAs transmitting signals to indicate all frames of their R-TWTx scheduled UL and P2P traffic flows transmitted during R-TWTx SP in accordance with at least one embodiment of the present disclosure.

Fig. 27 is a data field diagram of QoS data for an R-TWT and QoS control fields in QoS null frames in accordance with at least one embodiment of the present disclosure.

FIG. 28 is a communication diagram of an R-TWT scheduling AP broadcasting QoS null frames with EOSP set to a first state (e.g., "1") to indicate termination of the R-TWT SP according to at least one embodiment of the present disclosure.

Fig. 29 is a communication diagram of an R-TWT SP in which R-TWT member STAs are allowed to contend for a channel during the R-TWT SP in accordance with at least one embodiment of the disclosure.

Fig. 30 is a communication diagram in which the termination indicates an unsuccessfully received R-TWT SP.

Fig. 31 is a communication diagram of an STA transmitting QoS null frames, with EOSP of the QoS null frames set to a second state (e.g., "0") to end TXOP sharing time triggered during R-TWT SP in accordance with at least one embodiment of the present disclosure.

Fig. 32 is a communication diagram of STA transmitting QoS null frames with EOSP set to a first state (e.g., "1") to end the TXOP sharing time triggered by R-TWT SP.

Fig. 33 is a communication diagram of an R-TWT scheduling AP scheduling transmissions of STAs that are R-TWT schedules that are not R-TWT member STAs during an R-TWT SP in accordance with at least one embodiment of the disclosure.

Fig. 34 is a communication diagram of an R-TWT scheduling AP waiting for scheduled UL traffic to arrive during an R-TWT SP in accordance with at least one embodiment of the disclosure.

FIG. 35 is a communication diagram of an R-TWT scheduling AP terminating an R-TWT SP without having more frames of the scheduled traffic flow for the R-TWT to be transmitted according to at least one embodiment of the present disclosure.

Fig. 36 is a communication diagram of an R-TWT scheduling AP exchanging frames with an R-TWT non-member STA while waiting for scheduled traffic to arrive in accordance with at least one embodiment of the disclosure.

FIG. 37 is a communication diagram of the respective termination of a multi-link R-TWT SP on each link according to at least one embodiment of the present disclosure.

FIG. 38 is a communication diagram of termination of an ML R-TWT SP over a link according to at least one embodiment of the present disclosure.

Detailed Description

1. Introduction to 802.11 cells

1.1 Traffic Specification (TSPEC)

Fig. 1 depicts content in a TSPEC element defined in IEEE 802.11. The element ID field indicates the type of element; in this case a TSPEC unit. The length field indicates the length of the TSPEC element. The TS information (Info) field contains traffic flow information as shown in fig. 2.

It should be noted that in this disclosure, a field that is not described has the same function as a previous field having the name in other units.

The nominal MSDU size field indicates the nominal size of the MSDU or A-MSDU belonging to the TS under this TSPCs. The maximum MSDU size field contains the maximum size of the MSDU or A-MSDU belonging to the TS under this TSPCs. The minimum service interval field indicates the minimum time between the start times of two consecutive Service Periods (SPs). The maximum service interval field indicates the maximum time between the start times of two consecutive SPs. The inactivity interval field indicates the time allowed to elapse without the arrival or transmission of an MSDU belonging to the TS; after the time, the TS is deleted. The pause interval field indicates the time allowed to elapse without the arrival or transmission of an MSDU belonging to the TS before the generation of a successive quality of service (QoS) (+) contention-free (CF) poll for the TS is stopped. The service start time field indicates the start time of the first SP. The minimum data rate field indicates the minimum data rate specified by the MAC SAP for transmitting the MSDU or a-MSDU belonging to the TS under this TSPEC. The average data rate field indicates the average data rate specified by the MAC SAP for transmitting MSDUs or a-MSDUs belonging to the TS under this TSPEC.

The peak data rate field indicates the maximum data rate specified by the MAC SAP for transmitting MSDUs or a-MSDUs belonging to the TS under this TSPEC. The burst size field indicates the maximum burst of MSDUs or a-MSDUs that belong to the TS under this TSPEC at the peak data rate. The delay bound field indicates the maximum time allowed for transmitting an MSDU or a-MSDU belonging to a TS under this TSPEC. The minimum PHY rate field indicates the lowest PHY rate for transmitting an MSDU or a-MSDU belonging to a TS under this TSPEC. The excess bandwidth allowed field indicates the ratio of the bandwidth utilized to transmit an MSDU or a-MSDU belonging to a TS under this TSPEC and its retransmission to the bandwidth utilized to transmit the MSDU or a-MSDU once at the minimum PHY rate. The medium time field indicates the amount of time that the STA is allowed to access the medium. The DMG attribute field is given when the TSPEC is applied to a directional multi-gigabit (DMG) BSS.

Fig. 2 depicts the content in the TS information field (shown in fig. 1) as defined in IEEE 802.11. The subfields of the TS information field are as follows. The traffic type subfield specifies whether the traffic is periodic. The TSID subfield provides an ID number to identify the TS. The direction subfield specifies the direction of data transmission. The access policy subfield specifies the method for obtaining channel access. The aggregate subfield specifies whether aggregate scheduling is required. The APSD subfield indicates whether automatic PS delivery is used. The user priority subfield indicates the user priority of the MSDU or a-MSDU belonging to the TS. The TS information Ack policy subfield indicates whether an Ack is required and what form of Ack is to be utilized. The schedule subfield indicates the type of schedule.

1.1.2 TCLAS Unit

Fig. 3 depicts the contents of a TCLAS element defined in IEEE 802.11. The element ID field indicates the type of element; this is shown in this example as a TCLAS cell. The length field indicates the length of the TCLAS element. The user priority field indicates the user priority from an upper layer. The frame classifier field indicates the method to be utilized for classifying frames from an upper layer.

1.1.3 TCLAS processing Unit

Fig. 4 depicts the contents of a TCLAS processing unit defined in IEEE 802.11. The element ID field indicates the type of element; here indicated as TCLAS processing unit. The length field indicates the length of the TCLAS processing unit. The processing field indicates a method of classifying traffic from an upper layer when there are a plurality of TCLAS elements.

1.1.4 TWT units

Fig. 5 depicts a format of a TWT unit defined in ieee802.11ax with information for unit ID, length, control and TWT parameters.

FIG. 6 depicts control fields of the TWT unit shown in FIG. 5; and has the following fields: NDP paging indicator, responder PM mode, negotiation type, TWT information frame disable, wakeup duration unit, and reservation. The negotiation type subfield indicates the type of negotiation to be performed.

Fig. 7 depicts a broadcast TWT parameter information element that is active when the negotiation type as described in fig. 6 is set to a value of "2" or "3". The various subfields are shown as request type, target wake time, nominal minimum TWT wake duration, TWT wake interval mantissa, and broadcast TWT information.

It should be noted that there is an update in IEEE 802.11be (draft p802.11be_d1.01). When the broadcast TWT recommendation field in the request type field in the broadcast TWT parameter information field is set to "4", this means that the broadcast TWT (B-TWT) indicated in the broadcast TWT parameter information field is a limited TWT (R-TWT).

Fig. 8 depicts a request type field in the broadcast TWT parameter information field, with the following subfields: TWT request, TWT set command, trigger, last broadcast parameter set, stream type, broadcast TWT recommendation, TWT wake interval index, and reserved subfield.

Fig. 9 depicts a broadcast TWT information field in the broadcast TWT parameter information field, which has the following fields. A broadcast TWT ID subfield and a broadcast TWT persistence subfield.

1.2 SCS Signaling

Fig. 10 depicts an example of SCS settings defined in IEEE 802.11be (draft p802.11be_d1.01). The interworking model of the STA may be the same as defined in the IEEE 802.11 standard.

The non-AP STA decides to initiate SCS setup procedure with the AP. The Station Management Entity (SME) of the non-AP STA sends an MLME-scs. Request message to its MAC sublayer management entity (MLME). When the MLME of the non-AP STA receives the MLME-scs.request message, it gathers information in the MLME-scs.request message and sends an SCS request frame to the AP. The MLME of the AP receives the frame and generates an MLME-scs. Indication message for its SME.

Subsequently, the SME of the AP transmits an MLME-SCS. Response message containing the SCS set result to its MLME. Subsequently, the MLME of the AP transmits an SCS response frame to the non-AP STA. The MLME of the non-AP STA receives the frame and sends an MLME-scs. Confirm message to its SME. The non-AP may then identify whether the SCS set up was successful.

Fig. 11 depicts the format of SCS request frame. The SCS descriptor list field may carry a plurality of SCS descriptor units as shown in fig. 12.

Figure 12 depicts one of the SCS descriptor elements from the list of SCS descriptors seen in figure 11.

Figure 13 depicts the format of the SCS response frame. The SCS status list field may carry a plurality of SCS status fields as shown in fig. 14.

Figure 14 depicts SCS status subfields that represent SCS set results (e.g., accept, reject cause, terminate, etc.) of the SCS indicated in the SCSID field.

1.3, R-TWT signaling

Fig. 15 depicts an example of TWT settings defined in IEEE 802.11 ax. The interworking model of the STA may be the same as defined in the IEEE 802.11 standard.

The non-AP STA decides to initiate a TWT setup procedure with the AP. The Station Management Entity (SME) of the non-AP STA sends a MLME-twtsetup. Request message to its MAC sublayer management entity (MLME). When the MLME of the non-AP STA receives the MLME-twtsetup.request message, it gathers the information in the MLME-twtsetup.request message and sends a TWT setup frame (i.e., TWT request frame) to the AP. The MLME of the AP receives the frame and generates an MLME-twtsetup. Indication message for the SME for which the request was processed.

Subsequently, the SME of the AP sends a MLME-twtsetup. Response message containing the TWT setting result to its MLME. Subsequently, the MLME of the AP transmits a TWT setting frame (i.e., TWT response frame) to the non-AP STA. The MLME of the non-AP STA receives the frame and sends a MLME-twtsetup. Confirm message to its SME. The non-AP then identifies whether the TWT setting was successful.

The limited TWT R-TWT scheduling AP (referred to as R-TWT scheduling AP) is an EHT AP that supports limited TWT operation and sets the limited TWT support subfield in the transmitted EHT capability unit to "1", according to the definition in IEEE 802.11 be.

A limited TWT R-TWT scheduled STA (referred to as an R-TWT scheduled STA) is a non-AP EHT STA that supports limited TWT operation and sets the limited TWT support subfield in the transmitted EHT capability unit to "1".

The R-TWT scheduled STA may establish membership of one or more R-TWT scheduled by the R-TWT scheduling AP. The R-TWT setup signaling is the same as a broadcast TWT with additional parameter settings that are used for membership negotiation of R-TWTs between STAs of the R-TWT schedule and the R-TWT scheduling AP. After the R-TWT scheduled STA establishes membership of the R-TWT scheduled by the R-TWT scheduling AP, the R-TWT scheduled STA has a higher priority or is allowed to exchange frames with the R-TWT scheduling AP during the SP of the R-TWT. On the other hand, an R-TWT scheduled STA that is not a member of the R-TWT either has a lower priority or is not allowed to exchange frames with the R-TWT scheduled AP during the SP of the R-TWT.

Fig. 16 depicts a TWT setting frame containing the following fields: frame control, duration, multiple addresses, sequence control, and data. The data field is shown in the figure as containing the following subfields: category, action, dialog token, and TWT unit.

The frame control field indicates the type of the frame and may indicate that this is an action frame. The duration field contains NAV information that is used for CSMA/CA channel access. The address 1 field contains the address of the frame recipient. The address 2 field contains the address of the STA transmitting the frame. The address 3 field contains the BSSID of the STA that is the recipient of the frame. The sequence control field indicates the sequence number of the frame.

The category and action fields indicate that the action frame is a TWT setup frame and carries a TWT unit. The dialog token is used to identify the TWT settings frame. The TWT unit indicates TWT setting information whose format is shown in fig. 5.

FIG. 17 depicts an example of R-TWT SP communications. AP1 is an R-TWT scheduling AP that declares R-TWT1 scheduling and manages the members of R-TWT 1. STA1 and STA2 are member STAs of R-TWT 1. During R-TWT1 SP, AP1 schedules and prioritizes frame exchanges with member STAs (e.g., UL PPDUs with SCS1 of STA1 and DL PPDUs with SCS2 of STA 2). STAs that can receive and recognize the R-TWT schedule are referred to as R-TWT scheduled STAs. STA3 is an R-TWT scheduled STA, but is not a member STA of R-TWT 1. STA3 must end its TXOP before the start time of the R-TWT1 SP. STA3 may also enter silence mode or simply not contend for the channel during R-TWT1 SP. The scheduling AP may broadcast a quiet unit during the R-TWT SP to declare a quiet interval, identifying that STAs to the unit may enter a quiet mode.

2. Statement of problem

Current wireless communication systems using EDCA and R-TWT may prioritize RTA traffic transmissions, e.g., during R-TWT SP, with RTA traffic being sent preferentially. But the R-TWT SP duration is pre-scheduled and declared; in some cases, the R-TWT SP duration may be longer than the transmission time required by the R-TWT member STAs, resulting in unused channel bandwidth (lower transmission efficiency).

3. Contribution of the invention

The R-TWT schedules the AP and the member STAs of the R-TWT to negotiate which traffic is scheduled to be sent during the SP of the R-TWT. Scheduled traffic is sent preferentially during R-TWT SPs. The present disclosure identifies problems that occur when the R-TWT SP duration is longer than the transmission time required by the R-TWT member STA.

Mechanisms are described for providing an indication that an R-TWT SP terminates immediately after all RTA traffic for the R-TWT SP has been sent. One of the challenges addressed is how the R-TWT scheduling AP can identify that all RTA frames have been sent when they can be UL, DL and/or P2P.

In this protocol, a member STA may send a signal to the R-TWT scheduling AP during the R-TWT SP to indicate that it no longer has any scheduled UL and P2P to transmit during the R-TWT SP.

When all scheduled traffic is sent during the R-TWT SP, the R-TWT scheduling AP may send a signal to terminate the R-TWT SP.

After completing all scheduled traffic transmissions during the R-TWT SP, the R-TWT scheduling AP may share the remaining time of the R-TWT SP, e.g., to implement frame exchanges with STAs that are R-TWT scheduled STAs but are not member STAs of the R-TWT.

4. Examples of R-TWT termination

4.1, STA and MLD hardware configuration

Fig. 18 illustrates an exemplary embodiment 10 of STA hardware configured to execute the protocols of the present disclosure. External I/O connection 14 is preferably coupled to an internal bus 16 of circuit 12, and cpu 18 and memory (e.g., RAM) 20 are connected to internal bus 16 for executing program(s) embodying the communications protocol. The host houses at least one modem 22 to support communications coupled to at least one RF module 24, 28, the at least one RF module 24, 28 being connected to one or more antennas 29, 26a, 26b, 26c through 26n, respectively. An RF module with multiple antennas (e.g., an antenna array) allows beamforming to be implemented during transmission and reception. In this way, the STA may transmit signals using multiple sets of beam patterns.

Bus 14 allows various devices to be connected to the CPU, such as sensors, actuators, and the like. Instructions from the memory 20 are executed on the processor 18 to perform a program implementing the communication protocol that is executed to allow the STA to implement the functions of an Access Point (AP) station or a regular station (non-AP STA). It should also be appreciated that the programming is configured to operate in different modes (TXOP holders, TXOPs sharing participants, sources, intermediaries, destinations, first AP, other APs, stations associated with the first AP, stations associated with other APs, coordinator, coordinated, APs in OBSS, STAs in OBSS, etc.) depending on what role is played in the current communication context.

Thus, the STA HW is shown configured with at least one modem and associated RF circuitry for providing communication over at least one frequency band.

It should be appreciated that the present disclosure may be configured with a plurality of modems 22, each coupled to any number of RF circuits. In general, the use of a greater number of RF circuits will result in a wider coverage of the antenna beam direction. It should be appreciated that the number of RF circuits and the number of antennas utilized is determined by the hardware constraints of the particular device. When the STA determines that it is not necessary to communicate with a neighboring STA, the RF circuitry and a portion of the antenna may be disabled. In at least one embodiment, the RF circuitry includes a frequency converter, an array antenna controller, and the like, and is connected to a plurality of antennas that are controlled to implement beamforming for transmission and reception. In this way, the STA may transmit signals using multiple sets of beam patterns, each beam pattern direction being considered an antenna sector.

Further, it should be noted that multiple instances of station hardware as shown in the figures may be combined into a multi-link device (MLD) that would typically have a processor and memory for coordinated activity, not always requiring separate CPUs and memory for each STA within the MLD.

Fig. 19 shows an exemplary embodiment 40 of a multi-link device (MLD) hardware configuration. A soft AP MLD is an MLD made up of one or more dependent STAs operating as APs. Soft AP MLD should support multi-radio operation at 2.4GHz, 5GHz and 6 GHz. In multi-radio, the basic link set is a link pair satisfying Simultaneous Transmission and Reception (STR) modes, such as a basic link set (2.4 GHz and 5 GHz), a basic link set (2.4 GHz and 6 GHz).

A conditional link is a link that forms a non-simultaneous transmission and reception (NSTR) link pair with some basic link(s). For example, these link pairs may include 6GHz links that are conditional links corresponding to 5GHz when 5GHz is the base link; when 6GHz is the base link, the 5GHz link is a conditional link corresponding to the 6GHz link. Soft APs are used in different situations including Wi-Fi hotspots and splices.

Multiple STAs are affiliated with the MLD, with each STA operating on a different frequency link. The MLD has external I/O access to the application, which is connected to an MLD management entity 48 having a CPU 62 and a memory (e.g. RAM) 64 to allow execution of program(s) implementing the communication protocol of the MLD hierarchy. The MLD may assign tasks to each of the attached stations and collect information from each of the attached stations, illustrated herein as information sharing between STA 1 42, STA 2 through STA N46, and the attached STAs.

In at least one embodiment, each STA of the MLD has its own CPU 50 and memory (RAM) 52 connected to at least one modem 54 via a bus 58, the at least one modem 54 being connected to at least one RF circuit 56 having one or more antennas. In this example, the RF circuit has a plurality of antennas 60a, 60b, 60c to 60n, such as in an antenna array. The modem combines with RF circuitry and associated antenna(s) to transmit/receive data with the neighboring STAs. In at least one implementation, the RF module includes a frequency converter, an array antenna controller, and other circuitry for interfacing with its antenna.

It should be appreciated that each STA of an MLD does not necessarily need its own processor and memory, as STAs may share resources with each other and/or with the MLD management entity, depending on the particular MLD implementation. It should be appreciated that the foregoing MLD illustrations are given by way of example and not limitation, and that the present disclosure may operate with a variety of MLD implementations.

4.2 STA topology for exemplary use

Fig. 20 shows an exemplary embodiment 70 of a network topology utilized to explain the objects of the present disclosure. It should be appreciated that this topology (and any topology illustrated herein) is depicted by way of example and not limitation, and the apparatus and methods of the present disclosure are not limited to any particular network topology. Furthermore, specific MLDs, STAs, and link indexes are provided in this disclosure only to simplify understanding of operation.

If an AP station is affiliated with an MLD, the MLD is an AP MLD. If a non-AP STA is affiliated with a MLD, the MLD is a non-AP MLD.

As shown in fig. 20, this scenario depicts 6 STAs that constitute 3 MLDs within a given area, which is illustrated herein as a room. AP1 and AP2 are attached to a multi-link device (MLD) shown as MLD1, STA1 and STA4 are attached to MLD2, STA3 and STA5 are attached to MLD3.STA2 and STA6 may be non-AP STAs operating on link 1 or single link MLDs (i.e., special MLDs having only one STA and operating on one link). STA1, STA2, STA3, STA6 are associated with AP1 through link 1, and STA4 and STA5 are associated with AP2 through link 2. All STAs use EDCA for random channel access (CSMA/CA) on all links.

The R-TWT scheduling AP is capable of scheduling and asserting R-TWTs. An R-TWT scheduled STA (schedule enabled STA) is a non-AP STA capable of receiving and identifying an R-TWT declaration from an R-TWT scheduled AP and supporting R-TWT operation. The R-TWT scheduled STA is able to negotiate the membership of the R-TWT with the R-TWT scheduling AP. When an R-TWT scheduled STA becomes a member STA of an R-TWT, traffic (e.g., UL, DL, and/or P2P) of the R-TWT scheduled STA (i.e., R-TWT member STA) is scheduled and preferentially transmitted during SP of the R-TWT.

AP1 and AP2 are R-TWT scheduled APs, and STA1 through STA5 are R-TWT scheduled STAs; STA6 is not an R-TWT scheduled STA.

4.3 negotiation of R-TWT scheduling for SCS traffic

The R-TWT scheduling AP declares scheduling of R-TWT indicated by R-TWTx. An STA scheduled by R-TWT may request membership of R-TWTx. Further, during R-TWTx SP, the R-TWT scheduling AP may determine/identify which traffic flows are expected to be sent with high priority. This section explains the manner in which an R-TWT scheduled STA negotiates with an R-TWT scheduling AP as it sets membership of R-TWTx, which traffic flows should be sent with high priority during an R-TWTx SP. After the R-TWT scheduled STA becomes a member STA of R-TWTx, those traffic flows in the R-TWTx membership agreement will be sent with high priority during the R-TWTx SP and are denoted as scheduled traffic flows of R-TWTx. In at least one embodiment/mode/scenario, only frames of the scheduled traffic flow of R-TWTx are allowed to be transmitted during R-TWTx SP. For example, frames of a scheduled traffic flow not belonging to R-TWTx are either not allowed to be transmitted at R-TWTx SP or are only allowed to be transmitted with lower priority. It should be noted that traffic with higher priority means traffic that is sent earlier with a higher probability than traffic with lower priority. Furthermore, in at least one embodiment/mode/scenario, traffic with higher priority needs to be sent earlier than traffic with lower priority.

However, an exception may occur if there are frames that have the same TID as the scheduled traffic flow of R-TWTx and need to be retransmitted; but these frames may be sent during R-TWTx SP because they do not belong to any scheduled traffic flows of R-TWTx. When a STA uses block acknowledgements for TID, these frames should be sent by the STA during R-TWTx SP before sending the frames of the scheduled traffic stream for R-TWTx with the same TID. This exception occurs because the sequence numbers of these frames have been assigned and the frames are smaller than the frames of the scheduled traffic stream of R-TWTx.

FIGS. 21 and 22 illustrate exemplary embodiments of an R-TWT membership setting 110 and TWT setting frame 150.

Signaling of membership settings (negotiations) of R-TWTx using SCS traffic flow information between an R-TWT scheduled STA and an R-TWT scheduled AP is shown in fig. 21. Similar to fig. 15, a non-AP STA (R-TWT scheduled STA) transmits a TWT setup frame (i.e., R-TWT membership request frame) requesting membership of R-TWTx from an AP (R-TWT scheduled AP). The AP then sends back a TWT setup frame (i.e., an R-TWT membership response frame) to indicate the outcome of the R-TWTx membership status of the non-AP STA.

The difference here compared to fig. 15 is that the TWT setup frame may carry information of SCS traffic flows during the R-TWT membership setup procedure. The format of a TWT setup frame with SCS traffic flow information is shown in fig. 22.

To implement R-TWT settings, the non-AP STA SME 112 sends an MLME-twtsetup. Request 120 to the non-AP STA MLME114, and the non-AP STA MLME114 sends a TWT settings frame 122 with SCS traffic information to the AP MLME 116. The AP sends the TWT setup frame to its SME 118 as an MLME-twtsetup. Indication 124, the SME processes 126 the request and outputs the MLME-twtsetup. Response 128 to its MLME116, the MLME116 sends the TWT setup frame 130 with SCS traffic information to non-AP STA MLME114, and the non-AP STA MLME114 sends the MLME-twtsetup. Confirm 132 to its SME 112.

For example, if the broadcast TWT parameter set field in the TWT setup frame is for R-TWTx, the SCSID list in the broadcast TWT parameter set field carries information of the SCS traffic stream. As part of the R-TWTx membership negotiation, the non-AP STA embeds the information of SCS traffic streams in TWT setup frames, intended to request the AP to schedule the transmission of these SCS traffic streams during the R-TWTx SP. When an AP accepts R-TWTx membership requests from non-AP STAs, information for SCS traffic flows may be embedded in the corresponding R-TWT setup frames to indicate that these SCS traffic flows are scheduled traffic flows for R-TWTx. It should be noted that the AP determines whether to accept the membership request of R-TWTx based on the information of SCS traffic flow for R-TWTx. If the AP is able to meet the QoS requirements of SCS traffic flows during R-TWTx SP, then R-TWTx membership requests from non-AP STAs may be accepted. The AP may then set the SCSID list field in the corresponding broadcast TWT parameter set field in the R-TWT setup frame to indicate that the AP is capable of sending SCS traffic streams indicated in the SCSID list field during R-TWTx SP. Otherwise, the AP may reject the R-TWT membership request.

In at least one embodiment/mode/case, when an R-TWT membership request is accepted, the SCSID list field in the corresponding broadcast TWT parameter set field in the R-TWT membership response frame is copied from the corresponding R-TWT membership request.

In at least one embodiment/mode/scenario, if the AP accepts the R-TWTx membership request, it does not embed SCS traffic flow information in the response to the R-TWTx membership request. Thus, the SCS traffic flow indicated in the corresponding R-TWT membership request is the scheduled traffic flow of R-TWTx.

The SCSID list field consists of a Number (Number) identifying the Number of SCSID fields, followed by the Number of SCSID fields. Each SCSID represents an existing SCS established between a non-AP and an AP. It should be noted that the SCS setup procedure has been explained in fig. 10.

In at least one embodiment, reserved bits in the broadcast TWT parameter set field are utilized to indicate the presence of an SCSID list field. For example, in one embodiment, when the bit is set to a first state (e.g., "1"), it indicates that an SCSID list field is present in the broadcast TWT parameter set field. When the bit is set to a second state (e.g., "0"), it indicates that no SCSID list field exists in the broadcast TWT parameter set field.

When an R-TWT scheduled STA becomes a member STA of R-TWTx for a scheduled traffic flow with R-TWTx, it will send or receive those scheduled traffic flows of R-TWTx during the R-TWTx SP. The member STA of R-TWTx and the R-TWT scheduling AP will expect to describe a range of the number of scheduled traffic flows of each of its R-TWTx that will be exchanged during the R-TWTx SP. The following range types are described by way of example and not limitation.

(a) The minimum data rate field in the TSPCs element of the scheduled DL (or UL and/or P2P) SCS traffic stream of R-TWTx is set to R _min (bits per second). We mark t (seconds) as the time between the end times of two consecutive R-TWTx SPs. Thus, the minimum number of scheduled DL (or UL and/or P2P, respectively) traffic flows expected to arrive at the R-TWT scheduling AP (or R-TWTx member STAs, respectively, with the scheduled traffic flow) is R during time t _min * t (bits). Before the second R-TWTx SP ends, the R-TWT scheduling AP (or R-TWTx member STA with the scheduled traffic flow, respectively) may expect to transmit at least R _min * t (bits) of traffic.

(b) The average data rate field in the TSPCs element of the scheduled DL (or UL and/or P2P) SCS traffic stream of R-TWTx is set to R _mean (bits per second). We mark t (seconds) as the time between the end times of two consecutive R-TWTx SPs. Thus, the average number of scheduled DL (or UL and P2P, respectively) traffic flows expected to arrive at the R-TWT scheduling AP (or R-TWTx member STAs, respectively, with the scheduled traffic flow) is R during time t _mean * t (bits). Before the second R-TWTx SP ends, the R-TWT scheduling AP (or R-TWTx member STA with the scheduled traffic flow, respectively) may thus expect an average transmission R _mean * t (bits) of traffic.

(c) The peak data rate field in the TSPCC element of the scheduled DL (or UL and/or P2P) SCS traffic stream of R-TWTx is set to R _max (bits per second). We mark t (seconds) as the time between the end times of two consecutive R-TWTx SPs. Thus, the average number of scheduled DL (or UL and P2P, respectively) traffic flows expected to arrive at the R-TWT scheduling AP (or R-TWTx member STAs, respectively, with the scheduled traffic flow) is R during time t _max * t (bits). Before the second R-TWTx SP ends, the R-TWT scheduling AP (or R-TWTx member STA with the scheduled traffic flow, respectively) may expect to send no more than R _max * t (bits) of traffic.

In the broadcast TWT parameter set field of the R-TWT, a link ID field is added in at least one embodiment/mode/case to indicate the link of the SP on which the R-TWT is scheduled, in addition to those fields defined in IEEE 802.11ax (as shown in fig. 7). In at least one embodiment/mode/scenario, a reserved bit in the broadcast TWT parameter set field is utilized to indicate the presence of the link ID field. When the bit is set to a first state (e.g., "1"), it indicates that a link ID field is present in the broadcast TWT parameter set field. When the bit is set to a second state (e.g., "0"), it indicates that there is no link ID field in the broadcast TWT parameter set field, and that the SP of the R-TWT is scheduled on the link that sent the broadcast TWT parameter set field.

One TWT unit may have multiple broadcast TWT parameter set fields with the same or different R-TWT IDs (i.e., the values set in the broadcast TWT ID fields as shown in fig. 9). Multiple broadcast TWT parameter set fields with the same R-TWT ID and different link IDs may be combined into one TWT unit to indicate the R-TWT whose SPs are scheduled on multiple links. For example, one broadcast TWT parameter set field in one TWT unit with R-TWT ID equal to "4" and link ID equal to "1" and one broadcast TWT parameter set field with R-TWT ID equal to "4" and link ID equal to "2" indicate R-TWTs whose TWT IDs are "4" and whose SPs are scheduled on link 1 and link 2.

4.4. rewarding R-TWT scheduled STAs that are not R-TWT members

During an SP of an R-TWT, if a STA is an STA of the R-TWT schedule but is not a member STA of the R-TWT, the STA may sacrifice its opportunity to acquire a transmission opportunity (TXOP) or access channel due to the presence of the SP. For example, a STA ends its TXOP before the start time of the SP, or stops (interrupts) the contention channel during the SP. Thus, in at least one embodiment/mode/scenario, a reward mechanism is provided in the present disclosure for encouraging such STAs, particularly those STAs that are not members of any R-TWT of the scheduling AP by the R-TWT; encouraging it to support R-TWT operation. It should be noted that during SP of an R-TWT, those R-TWT scheduled STAs that are not member STAs of the R-TWT should wake up as they are not configured to go to sleep.

In IEEE 802.11be, the R-TWT scheduled STA is a non-AP very high throughput (EHT) STA that supports limited TWT operation, and the limited TWT support subfield in the transmitted EHT capability unit is set to a first state (e.g., "1"). If the non-AP EHT STA does not support limited TWT operation, it is not an R-TWT scheduled STA and sets the limited TWT support subfield in the transmitted EHT capability unit to a second state (e.g. "0"). It should be noted that a non-AP EHT STA transmits an EHT capability unit to its associated AP to indicate the EHT capability of the non-AP EHT STA. Thus, the R-TWT scheduling AP may identify whether an EHT STA is a limited TWT (R-TWT) scheduled STA based on a limited TWT support subfield in the transmitted EHT capability unit received from its associated EHT STA.

We denote the R-TWT (schedule) as R-TWTx scheduled by the R-TWT scheduling AP. Thus, the non-AP STA may be one of the following three types during the SP of R-TWTx.

(a) STAs that are R-TWT scheduled STAs but are not member STAs of R-TWTx. The STA ends its TXOP before the start time of the R-TWTx SP. The STA may enter a silence mode during a silence interval overlapping with the SP of the R-TWTx. In some cases, the STA may contend for channel access during the SP of R-TWTx. It should be noted that the R-TWT scheduling AP may not know whether the STA will enter silence mode during the silence interval overlapping with the SP of R-TWTx or whether the contention channel will cease during the SP of R-TWTx unless the STA sends this information to the R-TWT scheduling AP. For example, the STA may add an R-TWT silence support subfield and an R-TWT channel contention subfield in the transmitted EHT capability unit (or another unit) to transmit this information to the R-TWT scheduling AP.

(a) (i) the R-TWT silence support subfield is set to indicate whether the sender of this field will enter silence mode during a silence interval overlapping with the R-TWT SP. If the field is set to a first state (e.g., "1"), the sender of the field will enter silence mode during the silence interval overlapping with the R-TWT SP. Otherwise, the field is set to a second state (e.g., "0") and the sender of the field will not enter silence mode during the silence interval overlapping with the R-TWT SP. The R-TWT scheduling AP that receives this field may determine the expected behavior of the sender STA during the silence interval that overlaps the R-TWT SP. It should be noted that the silence interval is declared by a silence unit from the R-TWT scheduling AP.

(a) (ii) the R-TWT channel contention subfield is set to indicate whether the sender of the field will contend for the channel during the R-TWT SP if not a member of the R-TWT SP (i.e. not a member of the R-TWT that schedules the SP). If the field is set to a first state (e.g., "1"), the sender of the field will contend for the channel during the R-TWT SP if not a member of the R-TWT SP. Otherwise, the field is set to a second state (e.g., "0"), and the sender of the field will not contend for the channel during the R-TWT SP if not a member STA of the R-TWT SP. Such STAs may suspend their backoff counters during R-TWT SPs that they are not members. The R-TWT scheduling AP that receives this field may determine the expected channel contention behavior of the sender STA during the R-TWT SP, especially if it is not a member STA of the R-TWT SP. In at least one embodiment/mode/scenario, an R-TWT scheduled STA that is a member of an R-TWT scheduled by an R-TWT scheduling AP must forcedly cease (interrupt) contention channels during all R-TWT SPs for which the STA is not a member STA.

(b) STA which is a member STA of R-TWTx. During the R-TWTx membership negotiation as shown in section 4.3, the member STAs of R-TWTx may negotiate the scheduled traffic flows of R-TWTx, such as SCS traffic flows or R-TWT TID defined in IEEE 802.11 be.

(c) STAs that are not R-TWT scheduled STAs. Such STAs will not end their TXOPs before the start time of the R-TWTx SP nor will they stop contending for the channel during the SP of R-TWTx.

(c) (i) in some cases, such STAs may remain quiet during the quiet interval declared by the quiet unit. If such a STA enters a quiet mode during a quiet interval, this may be reported to the R-TWT scheduling AP by setting the R-TWT quiet support subfield to a first state (e.g., "1").

During R-TWTx SP, the R-TWT schedules AP prioritization and/or allows only transmission (i.e., frame exchange) of the scheduled traffic stream of R-TWTx. If the R-TWT scheduling AP ends transmitting all scheduled traffic flows of R-TWTx with all R-TWTx member STAs before the scheduled end time of the R-TWTx SP, the remaining SP time may be used to exchange frames with those STAs that are R-TWT scheduled STAs but are not member STAs of R-TWTx and those STAs that are not R-TWT scheduled but have their R-TWT silence support subfield set to a first state (e.g., "1").

The R-TWT scheduling AP may transmit: (a) a trigger frame to trigger TB PPDUs from those STAs; (b) DL PPDUs to those STAs; and/or (c) a trigger frame to initiate triggered TXOP sharing times that may be used by those STAs to transmit, such as the MU-RTS TXS frame defined in IEEE 802.11 be.

The R-TWT scheduling AP may send frames to those STAs only to indicate the end of the R-TWTx SP; thereby freeing those STAs from contending for the channel immediately.

During R-TWTx SP, when the R-TWT scheduling AP transmits a scheduled traffic stream of R-TWTx in the MU PPDU, a Resource Unit (RU) may be allocated to transmit frames with STAs that are R-TWT scheduled STAs but are not member STAs of R-TWTx; provided that the frames do not increase the transmission time of the MU PPDUs required for the scheduled traffic stream.

During R-TWTx SP, when the R-TWT scheduling AP transmits a trigger frame to trigger the scheduled UL traffic flow of R-TWTx, RU may be allocated to trigger frames from STAs that are STAs of the R-TWT schedule but are not member STAs of R-TWTx; provided that these frames do not increase the transmission time of the TB PPDU required for the scheduled UL traffic stream.

During R-TWTx SP, the scheduling AP may also exchange frames with STAs that are R-TWT scheduled STAs but are not member STAs of R-TWTx if there is no buffer of the scheduled traffic flow of R-TWTx.

When the R-TWT scheduling AP may send a trigger frame to trigger a TB PPDU from STAs that are STAs of the R-TWT schedule but are not member STAs of the R-TWTx; the STAs may not use MU-EDCA or reset their backoff counters after transmitting the TB PPDU to contend for the channel. The trigger frame may have RA-RU Uplink OFDMA Random Access (UORA) for a particular group of STAs to send TB PPDUs through the RA-RUs.

The AID for the user information field of the RA-RU may be within a selected range of values, e.g., between "2047" to "4094" reserved in the current IEEE 802.11ax, to represent the STA group. The STA may access the RA-RU upon receiving the AID set to its group of STAs.

There may be multiple groups of STAs, each using a different AID. STAs may belong to multiple STA groups (e.g., subgroup 1 through subgroup 6).

The trigger frame may assign the RU to one or more individual STAs. It is possible that the individual STAs may be STAs of only some of the subgroups, as described below. For example, the individual STAs may be only STAs of subgroup 1.

A group of STAs may be composed of one or more of the following sub-groups.

(1) In subgroup 1, not member STAs of any R-TWT of the R-TWT scheduled AP, and have set their R-TWT channel contention subfield equal to all R-TWT scheduled STAs of the first state (e.g., "1").

(2) In subgroup 2, not member STAs of any R-TWT of the R-TWT scheduled AP have their R-TWT channel contention subfield set equal to the second state (e.g., "0") and have their R-TWT silence support subfield set to all R-TWT scheduled STAs of the first state (e.g., "1").

(3) In subgroup 3, not member STAs of any R-TWT of the R-TWT scheduled AP have set their R-TWT channel contention subfield to the second state (e.g., "0") and have set their R-TWT silence support subfield to all R-TWT scheduled STAs of the second state (e.g., "0").

(4) In subgroup 4, all STAs that are not R-TWT scheduled and have set their R-TWT silence support subfield to a first state (e.g., "1").

(5) In subgroup 5, not member STAs of R-TWTx but member STAs of other R-TWTs of the R-TWT scheduling AP, and all R-TWT scheduled STAs whose R-TWT channel contention subfield has been set to a first state (e.g. "1").

(6) In subgroup 6, not member STAs of R-TWTx but members of other R-TWTs of the R-TWT scheduling AP, and all R-TWT scheduled STAs whose R-TWT channel contention subfield has been set to the second state (e.g. "0").

In at least one embodiment/mode/case, a priority of using R-TWTx SP time may be set between the subgroups. In general, STAs of a subgroup supporting more than one R-TWT operation will have a higher priority to use R-TWTx SP time. The priorities of STAs using the remaining R-TWTx SP time may be set in a desired priority order, for example, in a subgroup numbering order or any other desired pattern.

4.5 termination of R-TWT SP

Section 4.3 explains the manner in which an R-TWT scheduled STA coordinates its membership and scheduled traffic flows (such as SCS traffic flows) for that R-TWT. It should be noted that a member STA of an R-TWT may have multiple scheduled traffic flows for that R-TWT. The R-TWT may have a plurality of R-TWT member STAs. The R-TWT scheduling AP may assert multiple R-TWTs, such as R-TWTx, R-TWTy, R-TWTz, and the like.

This section explains how to terminate the R-TWT SP. The present disclosure allows a member STA of an R-TWT to signal to an R-TWT scheduling AP to indicate that it no longer has any frames of the scheduled traffic stream to transmit during the SP of that R-TWT. When the R-TWT scheduling AP recognizes that all scheduled traffic has been sent, it sends a signal to indicate the termination of the SP for that R-TWT.

The R-TWT scheduling AP and the R-TWT scheduled STA may embed the QoS control field as shown in fig. 27 in QoS data or QoS null frames.

FIG. 23 illustrates an exemplary embodiment 170 of an AP termination R-TWTx SP (i.e., SP of R-TWTx) scheduled by an R-TWT. For simplicity of explanation, the R-TWT is labeled as R-TWTx scheduled by the R-TWT scheduling AP. The R-TWT scheduling AP starts exchanging frames 172 of the R-TWTx scheduled traffic stream with the R-TWTx member STAs during the R-TWTx SP. It should be noted that the R-TWTx member STA may negotiate the scheduled traffic flow for R-TWTx, as explained in section 4.3.

A brief overview of the flow chart of fig. 23 is provided first. In block 172, the scheduling AP begins exchanging frames of the scheduled traffic stream of R-TWTx with the R-TWTx member STAs during the R-TWTx SP.

A check 174 determines if all scheduled traffic has been sent before the scheduled end time of the R-TWTx SP. If all traffic has not been sent, the scheduling AP may end the R-TWTx SP at the scheduled end time at block 180 and the process ends.

Otherwise, if the condition that all scheduled traffic has been sent is satisfied, the scheduling AP exchanges frames with those R-TWT scheduled STAs that are not member STAs of R-TWTx during the remaining time of the R-TWTx SP at block 176. After this, the scheduling AP sends 178 a signal to indicate the end of the R-TWTx SP, ending the process.

The next section provides additional details about the exchange shown in fig. 23 in a hierarchical form.

(a) In some cases, before an R-TWT scheduling AP and an R-TWTx member STA begin exchanging frames of a scheduled traffic stream of R-TWTx, the R-TWT scheduling AP or R-TWT member STA will need to contend for the channel to obtain a TXOP for frame exchange. In at least one embodiment or mode, an R-TWT scheduling AP or R-TWTx member STA is allowed to contend for the channel only if there are frames of the R-TWTx's scheduled traffic flow in its buffer. In some cases, an R-TWT scheduling AP may contend for a channel during an R-TWTx SP despite not having a buffer for the scheduled traffic flow for the R-TWTx.

(b) When the R-TWT schedule AP or R-TWTx member STA gains channel access, the TXOP may be reserved using an exchange of RTS/MU-RTS and CTS. In at least one embodiment/mode/case, the TXOP duration is required to be less than or equal to the scheduled R-TWTx SP time (scheduled end time of R-TWTx SP-R-TWT scheduled start time of R-TWTx SP). In at least one embodiment/mode/case, the TXOP is not allowed to reserve beyond the scheduled end time of the R-TWTx SP. During a TXOP, all scheduled traffic flows of R-TWTx may be sent as traffic from the primary AC of the TXOP.

(c) In at least one embodiment/mode/scenario, if an R-TWT scheduled STA is to obtain a TXOP that overlaps with an R-TWTx SP, it is forced to use a (MU) RTS/CTS exchange to obtain the TXOP. The R-TWT scheduling AP may not respond to the CTS upon receiving such an RTS from the R-TWT scheduled STA, thereby not allowing the R-TWT scheduled STA to obtain the TXOP. In at least one embodiment/mode/scenario, the R-TWT scheduling AP sets any NAV in the CTS frame in response to such RTS from the R-TWT scheduled STA. The R-TWT scheduled STA then only obtains a TXOP equal to the NAV in the CTS frame.

(d) In at least one embodiment/mode/scenario, the R-TWT scheduling AP transmits trigger frames for the scheduled UL traffic flows from R-TWTx of the R-TWTx member STAs during the R-TWTx SP. The trigger frame may include RA-RUs (UORA) that any STA (or one or more subgroups as explained in section 4.4) may use for its UL transmissions. The allocation of priorities of RA-RUs to STAs may follow the priorities of the subgroups as explained in section 4.4. In at least one embodiment/mode/scenario, RA-RU in the trigger frame is only allowed without increasing the transmission time of the requested TB PPDU required for the scheduled UL traffic stream of R-TWTx.

(e) In at least one embodiment/mode/scenario, the R-TWT scheduling AP and the R-TWTx member STAs use EDCA to obtain a TXOP for transmission of the scheduled traffic flow for R-TWTx during the R-TWTx SP. When the EDCA TXOP is obtained, in at least one embodiment/mode/case, all frames of the scheduled traffic flow of R-TWTx may be transmitted during the EDCA TXOP, including those from both primary and non-primary ACs. It should be noted that the primary AC represents the AC whose EDCAF obtains the TXOP. In at least one embodiment/mode/case, only the EDCAF of the AC with frames of the scheduled traffic flow of R-TWTx in its buffer is allowed to contend for the channel.

(f) In at least one embodiment/mode/scenario, when a trigger field in a request type field in a broadcast TWT parameter information field of R-TWTx is set to a first state (e.g., "1") by an R-TWT scheduling AP, only the R-TWT scheduling AP is allowed to contend for a channel during the R-TWTx SP. The R-TWTx member STA may also contend for the channel during the R-TWTx SP if the field is set to a second state (e.g., "0").

(g) In at least one embodiment/mode/scenario, if there are frames whose TID is the same as the scheduled traffic flow of R-TWTx, and these frames need to be retransmitted but do not belong to any of the scheduled traffic flows of R-TWTx, then the R-TWT scheduling AP transmits these frames during the R-TWTx SP. In at least one embodiment/mode/scenario, when block acknowledgements are used for this TID, the R-TWT scheduling AP transmits frames of the R-TWTx traffic flow with the same TID earlier during the R-TWTx SP than those frames. This is beneficial because the sequence numbers of these frames have been assigned and these frames are smaller than the frames of the scheduled traffic stream of R-TWTx.

The R-TWT schedule AP and R-TWTx member STAs continue frame exchanges of the scheduled traffic flows of R-TWTx. The scheduled traffic flows may be Uplink (UL), downlink (DL), and/or peer-to-peer (P2P) flows. The R-TWT scheduling AP needs to know (determine/identify) whether all frames of the scheduled traffic flow of the R-TWTx member STA are transmitted during the R-TWTx SP. It should be noted that the empty buffer status of the R-TWTx scheduled traffic flow at the R-TWTx member STA may not be a valid indicator of all frames for which the scheduled traffic flow has been sent during the R-TWTx SP. The frames of the scheduled traffic stream may arrive later at the R-TWTx member STA, e.g., halfway through the R-TWTx SP. Thus, the present disclosure uses signals to explicitly indicate that all frames of the scheduled traffic flow of the R-TWTx member STA have been transmitted during the R-TWTx SP without relying on using a null buffer status report. The explicit signal may take the following form.

(a) If there is a scheduled UL or P2P traffic flow for R-TWTx, the R-TWT scheduling AP expects to receive a signal during the R-TWTx SP from each R-TWTx member STA with a scheduled UL and/or P2P traffic flow for R-TWTx to indicate that it has sent all frames of the scheduled UL and P2P traffic flow for R-TWTx (i.e., that it no longer has more frames of the scheduled UL and/or P2P traffic flow for R-TWTx to send), as explained in the flowcharts of fig. 24-26. When the R-TWT scheduling AP receives such signals from all R-TWTx member STAs with the scheduled UL and P2P traffic flows of R-TWTx during the R-TWTx SP, it recognizes that all frames of the scheduled UL and P2P traffic flows of R-TWTx have been transmitted.

(b) Instead of the R-TWTx member STA transmitting a signal during the R-TWTx SP to indicate that it no longer has more frames of the R-TWTx's scheduled UL and/or P2P traffic streams to transmit, in at least one embodiment/mode/scenario, the R-TWT scheduling AP recognizes that the R-TWTx member no longer has additional frames of the R-TWTx's scheduled UL traffic or P2P traffic streams to transmit when the following two conditions are met.

(b) (i) each UL and P2P scheduled traffic flow intended for R-TWTx member STAsHas been received by the R-TWT scheduling AP. For example, the minimum data rate field in the TSPCC element of the scheduled UL SCS traffic stream for R-TWTx is set to R _min (bits per second). We mark t (seconds) as the time between the end times of two consecutive R-TWTx SPs. Thus, the minimum number of scheduled UL SCS traffic flows expected to reach R-TWTx member STAs is R during time t _min * t (bits). Before the second R-TWTx SP ends, the R-TWT scheduling AP should receive all those Rs _min * t (bits) of traffic.

(b) (ii) the buffers of all scheduled UL and/or P2P traffic flows of R-TWTx are empty. The R-TWT scheduling AP may send a BSRP to request this information. The R-TWTx member STA may report the buffer status of the scheduled traffic flow of R-TWTx to the R-TWT scheduling AP only during R-TWTx SP.

(b) (con't) the minimum number of each scheduled UL or P2P traffic flow of R-TWTx may be replaced with an average or maximum number of each scheduled DL traffic flow of R-TWTx or a similar relative metric that may be calculated as explained in section 4.3.

(c) The R-TWT scheduling AP may identify when it has no more frames of the scheduled DL traffic stream to transmit when the following two conditions are met.

(c) (i) a minimum number of each scheduled DL traffic flow intended to reach an R-TWT of an R-TWT scheduling AP has been transmitted. For example, the minimum data rate field in the TSPCC element of the scheduled DL SCS traffic stream of R-TWTx is set to R _min (bits per second). We mark t (seconds) as the time between the end times of two consecutive R-TWTx SPs. Thus, the minimum number of scheduled DL traffic flows expected to reach the R-TWT scheduled AP is R during time t _min * t (bits). Before the second R-TWTx SP ends, the R-TWT scheduling AP should send all those Rs _min * t (bits) of traffic. The R-TWT scheduling AP may have multiple scheduled DL traffic flows of R-TWTx.

(c) (ii) the buffers of all scheduled DL traffic flows of R-TWTx are empty.

(c) (con't) the average or maximum number of each scheduled DL traffic stream of R-TWTx may be replaced with a similar relative metric that may be calculated as explained in section 4.3.

(d) In check 174, if all frames of the scheduled traffic flow for R-TWTx are transmitted before the scheduled end time of the R-TWTx SP, the R-TWT scheduling AP may exchange frames 176 with those R-TWT scheduled STAs that are not R-TWTx member STAs during the remaining time of the R-TWT SP. This is to reward support for R-TWT operation for those R-TWT scheduled STAs that are not R-TWTx member STAs. Details are explained in section 4.4.

(e) The R-TWT scheduling AP may send signal 178 to indicate the end of the R-TWTx SP at any time after all frames of the scheduled traffic stream for R-TWTx are sent and before the scheduled end time of the R-TWTx SP. For example, the signal to indicate the end of the R-TWT SP may be any of the following.

(e) (i) a QoS data frame or QoS null frame with EOSP subfield set equal to the first state (e.g. "1"), wherein the QoS control field of the frame may be as depicted in fig. 27 or defined in IEEE 802.11ax (it should be noted that QoS null frames with EOSP set to "1" may have to be broadcasted).

(e) (ii) frames (including Ack or BA frames) that are neither QoS data nor QoS null frames having more data fields equal to the second state (e.g., "0") may be the same as defined in IEEE 802.11 ax. It should be noted that the more data field may be in a frame control field or an RDG/more data field in CAS control of an HT control field. In this case, when more data subfields are set to a first state (e.g., "1"), there is the same effect as when EOSP is set to a second state (e.g., "0"). When the more data subfields are set to a second state (e.g., "0"), the same effect as when EOSP is equal to a first state (e.g., "1") is achieved.

(e) (iii) a CF end frame to indicate termination of R-TWT SP.

(e) (iv) trigger frames having more TF fields equal to the second state (e.g., "0") and not addressed to any R-TWT member STA.

(e) (v) a TWT information frame as defined in IEEE 802.11ax having a TWT flow identification field equal to the R-TWT ID to indicate termination of the R-TWT SP.

(e) (vi) frames (including Ack or BA frames) that are neither QoS data nor QoS null frames, the more data field in the frame (e.g., either more data subfields in the frame control field or RDG/more data fields in CAS control of HT control field) being equal to the first state (e.g., "1") during R-TWT SP.

It should be noted that during R-TWT SP, when more data subfields are set to a first state (e.g., "1"), there is the same effect as when EOSP is equal to the first state (e.g., "1"). When the more data subfields are set to a second state (e.g., "0"), there is the same effect as when EOSP is equal to the second state (e.g., "0"). It should be noted that when outside the R-TWT SP, more data fields may be utilized in the same manner as they are in the current IEEE 802.11 ax.

(f) The STA may recognize the end of R-TWTx SP under the following conditions.

(f) (i) when it receives a frame (e.g., a broadcast frame) from the R-TWT scheduling AP that does not request an immediate response and indicates termination of the R-TWT SP.

(f) (ii) when it transmits an acknowledgement in response to a frame indicating the termination of the R-TWT SP. It should be noted that the frame indicating termination of the R-TWT SP is sent by the R-TWT scheduling AP.

(g) An STA that is not an R-TWT schedule of an R-TWTx member STA may start or continue contending for the channel immediately after identifying the end of the R-TWTx SP.

(h) When the R-TWTx member STA recognizes the end of the R-TWTx SP, it may: (i) go to sleep if in a power saving mode; or (ii) immediately begin or continue channel contention; or (iii) not allowed to contend for the channel until the scheduled end time of the R-TWTx SP.

(j) In at least one embodiment/mode/scenario, when an R-TWTx member STA starts contending for a channel after the end of an R-TWTx SP, the channel contention process of the R-TWTx member STA may be slowed down (delayed) for a period of time (e.g., MU EDCA timer field for each AC in MU-EDCA) using an EDCA parameter set (e.g., MU-EDCA unit in IEEE 802.11 ax).

(k) If all frames of the scheduled traffic stream of R-TWTx cannot be transmitted before the scheduled end time of the R-TWTx SP, the R-TWT scheduling AP or R-TWT member STA may end 180R-TWTx SP at the scheduled end time or extend the R-TWTx SP by extending its obtained TXOP.

Fig. 24 to 26 show the processing of all frames of scheduled UL and P2P traffic streams for which R-TWTx members STA have transmitted during R-TWTx SP.

A brief overview of the flow charts of fig. 24-26 is provided first. In block 192, the R-TWTx member STA waits for the R-TWTx scheduled traffic flow to reach its buffer.

A check 194 determines whether the R-TWTx member STA has any UL and/or P2P traffic streams in its buffer for transmission during the R-TWTx SP. If the condition is met, at block 196, the R-TWTx member STA transmits a frame of the R-TWTx's scheduled UL or P2P traffic flow in its buffer and execution moves to block 200 in FIG. 25.

In block 200, a check is made to determine if the R-TWTx member STA has transmitted all frames of its R-TWTx scheduled UL and P2P traffic during the R-TWTx SP. If all frames have not been transmitted, execution returns to block 192. Otherwise, since all frames have been transmitted, execution moves to block 202 where the R-TWTx member STA signals the scheduling AP that it has transmitted all frames of its R-TWTx scheduled UL and P2P traffic streams during the R-TWTx SP.

Execution reaches decision block 204 where it is determined whether the R-TWTx member STA received any signals for termination of the R-TWTx SP. If a termination signal has been received, the R-TWTx SP ends at block 206 and the R-TWTx member STA may then contend for the channel or other traffic may contend for the channel and the process ends. Otherwise, in block 208, the R-TWTx member STAs are not allowed to contend for the channel until the R-TWTx SP ends at its scheduled end time.

Returning now to block 194 of FIG. 24, if the conditions in block 194 are not met, then decision block 198 is reached where a determination is made between the two options. In option 2, return to block 192 and continue waiting for the arrival of a frame, otherwise in option 1 execution moves to block 202 in fig. 25, which has been described.

Additional details regarding the processing illustrated in fig. 24-26 are provided below.

The R-TWTx member STA first waits (192) for the scheduled UL or P2P traffic stream of R-TWTx to reach its buffer. If the R-TWTx member STA has frames of the R-TWTx scheduled UL or P2P traffic flow in its buffer during the R-TWTx SP, as determined at block 194, the R-TWTx member STA begins transmitting (196) frames of those scheduled traffic flows of R-TWTx to the R-TWT scheduling AP during the R-TWTx SP. It should be noted that R-TWTx member STAs may negotiate their R-TWTx scheduled traffic flows, as explained in section 4.3. This may be implemented in any of the following ways.

(a) In some cases, before an R-TWT scheduling AP and an R-TWTx member STA begin exchanging frames of a scheduled traffic stream of R-TWTx, the R-TWT scheduling AP or R-TWTx member STA will need to contend for the channel to obtain a TXOP for frame exchange. When the R-TWT schedule AP or R-TWT member STA gains channel access, the TXOP may be reserved using an exchange of RTS/MU-RTS and CTS. In at least one embodiment/mode/case, the TXOP duration must be less than or equal to the scheduled R-TWTx SP time. In at least one embodiment/mode/case, the TXOP cannot be reserved beyond the end time of the R-TWTx SP. During a TXOP, all scheduled traffic flows may be sent as traffic from the primary AC of the TXOP.

(b) In at least one embodiment/mode/scenario, when an R-TWT scheduled STA is to obtain a TXOP that overlaps with an R-TWT SP, it is forced to use (MU) RTS/CTS exchange to obtain the TXOP. The R-TWT scheduling AP may not respond with a CTS upon receiving such an RTS from the R-TWT scheduled STA and may not allow the R-TWT scheduled STA to obtain a TXOP. It is also possible that the R-TWT scheduling AP sets any NAV in the CTS frame in response to such an RTS from the R-TWT scheduled STA. The R-TWT scheduled STA then only obtains a TXOP equal to the NAV in the CTS frame.

(c) In at least one embodiment/mode/scenario, the R-TWT scheduling AP and the R-TWTx member STAs use EDCA to obtain a TXOP for transmission of the scheduled traffic flow for R-TWTx during the R-TWTx SP. When the EDCA TXOP is obtained, in some cases, all frames of the scheduled traffic flow for R-TWTx may be transmitted during the EDCA TXOP, including those from both primary and non-primary ACs. It should be noted that the primary AC represents the AC whose EDCAF obtains the TXOP. In at least one embodiment/mode/scenario, only the EDCAF of the AC with the scheduled traffic flow of R-TWTx in its buffer is allowed to contend for the channel.

(d) In at least one embodiment/mode/scenario, when the trigger field in the request type field in the broadcast TWT parameter information field of R-TWTx is set to a first state (e.g., "1") by the R-TWT scheduling AP, the R-TWTx member STAs are not allowed to contend for the channel during the R-TWTx SP. The R-TWTx member STA may also contend for the channel during the R-TWTx SP if the field is set to a second state (e.g., "0").

(e) It is possible that if there are frames whose TID is the same as the scheduled traffic flow of R-TWTx and which need to be retransmitted but which do not belong to any of the scheduled traffic flows of R-TWTx, then the R-TWTx member STA may transmit these frames during R-TWTx SP. When block acknowledgements are used for this TID, the R-TWTx member STA should send the frames earlier during the R-TWTx SP than the frames of the scheduled traffic stream of the R-TWTx with the same TID. This is beneficial because the sequence numbers of these frames have been assigned and the frames are smaller than the frames of the scheduled traffic stream of R-TWTx.

As determined in block 194, if the R-TWTx member STA does not have any frames of the R-TWTx's scheduled UL and/or P2P traffic streams in its buffer during the R-TWTx SP, the following options 198 may be determined: continue waiting for 192 frames to arrive or send a signal 202 to the R-TWT scheduling AP to indicate that it has sent all frames of its R-TWTx scheduled UL and P2P traffic streams during the R-TWTx SP. That is, the R-TWTx member STA does not expect more frames of scheduled UL and/or P2P traffic streams to arrive and be transmitted during the R-TWTx SP.

If the R-TWTx member STA has transmitted all frames of the scheduled UL and/or P2P traffic streams for R-TWTx in its buffer, but more frames of the scheduled UL or P2P traffic streams for R-TWTx are expected to arrive during the R-TWTx SP, then it should remain waiting 192 for these frames to arrive, as determined in block 200.

When the R-TWTx member STA transmits all frames of the UL and/or P2P traffic streams of R-TWTx during the R-TWTx SP, it transmits a signal 202 with such an indication, the processing being further summarized below.

(a) It should be noted that an R-TWTx member STA may identify that it no longer has frames of the R-TWTx's scheduled UL and/or P2P traffic stream to transmit when the following two conditions are met.

(a) (i) a minimum number of scheduled UL and P2P traffic flows intended for each of the R-TWT member STAs has been transmitted. For example, the minimum data rate field in the TSPEC element of the scheduled UL SCS traffic stream for R-TWTx is set to Rmin (bits per second). We mark t (seconds) as the time between the end times of two consecutive R-TWTx SPs. Thus, the minimum number of UL SCS traffic streams expected to reach R-TWTx member STAs is R during time t _min * t (bits). Before the second R-TWTx SP ends, the R-TWTx member STA should send all those Rs _min * t (bits) of traffic. The R-TWTx member STA may have multiple scheduled UL and/or P2P traffic flows of R-TWTx.

(a) (ii) buffers of those scheduled traffic flows of R-TWTx are empty at R-TWTx member STAs.

(a) (con't) the average or maximum number of each scheduled DL traffic flow for R-TWTx may be replaced with a similar relative metric that may be determined (e.g., calculated) as explained in section 4.3.

(b) In at least one embodiment, the signals indicating all frames of the scheduled UL and P2P traffic streams for which the R-TWT member STA has transmitted during the R-TWTx SP are selected from the following.

(b) (i) the signal may be a frame (including Ack or BA frames) that is neither QoS data nor QoS null frames with more data fields equal to the second state (e.g. "0"), which may be the same as defined in IEEE 802.11 ax. It should be noted that the more data field may be in the frame control field or RDG/more data field in CAS control of HT control field of the frame. When more data subfields are set to a first state (e.g., "1"), there is the same effect as when an EOSP is set to a second state (e.g., "0"). When more data subfields are set to a second state (e.g., "0"), there is the same effect as when an EOSP is set to a first state (e.g., "1").

(b) (ii) the signal may be QoS data or QoS null frames with EOSP subfield equal to "1", the QoS control field in which may be as shown in fig. 17.

(b) (iii) the signal may be a frame (including Ack or BA frames) that is neither QoS data nor QoS null frames, with the more data field in the frame (e.g., either more data subfield in the frame control field or RDG/more data field in CAS control of HT control field) being equal to the first state (e.g., "1") during R-TWT SP. It should be noted that during the R-TWT SP, when the RDG/more data subfield is set to the first state (e.g. "1"), it has the same effect as when the EOSP is set to the first state (e.g. "1"). When the RDG/more data subfield is set to the second state (e.g., "0"), it has the same effect as when the EOSP is set to the second state (e.g., "0"). It should be noted that when outside the R-TWT SP, more data fields are preferably used in the same way as in the current IEEE 802.11 ax.

(c) If the signal is carried by a data frame, the data frame may be the last data frame of the R-TWTx scheduled traffic stream transmitted by the R-TWTx member STA. In at least one embodiment/mode/scenario, the signal is carried by all data frames in the last PPDU transmitted by the R-TWTx member STA, e.g., all data frames in the last PPDU with the EOSP subfield set to a first state (e.g., "1"). Subsequently, the signal is successfully received by the R-TWT scheduling AP when the entire PPDU carrying the last data frame is successfully received, or when all frames of the scheduled traffic stream of the R-TWTx in the PPDU are successfully received. In at least one embodiment/mode/scenario, during R-TWTx SP, the PPDU is only allowed to carry frames of the R-TWTx scheduled traffic stream.

(d) If the signal is not successfully transmitted, the R-TWTx member STA needs to retransmit the signal to the R-TWT scheduling AP.

(e) The signal may be transmitted by the R-TWTx member STA in an unsolicited manner when it does not have any frames of the scheduled UL or P2P traffic flow of R-TWTx in its buffer, and inform the R-TWT scheduling AP that the R-TWT scheduling AP may terminate the R-TWTx SP regardless of the scheduled UL and/or P2P traffic flow of R-TWTx that should be transmitted by the R-TWTx member STA.

(f) In at least one embodiment/mode/scenario, R-TWTx member STAs that do not have any scheduled UL and/or P2P traffic flows of R-TWTx are not allowed to transmit such signals during R-TWTx SP. In alternative embodiments/modes/situations, any R-TWTx member STAs that do not have R-TWTx's scheduled UL and/or P2P traffic flows are also required to transmit such signals.

(g) If the R-TWTx member STA does not have a scheduled DL traffic flow for R-TWTx and is operating in power save mode, it is allowed to enter sleep mode (go to sleep) immediately after successfully transmitting the signal to the R-TWT scheduling AP.

Thus, as explained in fig. 24-26, the R-TWT scheduling AP may send a signal to indicate the end of the R-TWTx SP after all scheduled traffic flows are sent. When the R-TWTx member STA recognizes the end of the R-TWTx SP, it then immediately begins contending 206 for the channel, as determined in block 204. In at least one embodiment/mode/case, the R-TWTx member STAs may utilize different EDCA parameter settings for a period of time to reduce the priority of their channel contention. For example, the R-TWTx member STA uses the MU-EDCA parameters for channel contention after the R-TWTx SP ends. Instead of contending for the channel, the R-TWTx member STA may also enter sleep mode at the end of the R-TWTx SP to save power. Otherwise, the R-TWTx member STA is not allowed to contend for the channel until the R-TWTx SP ends at the scheduled end time of the R-TWTx SP after it transmits all frames 208 indicating that its R-TWTx scheduled UL and P2P traffic streams have been transmitted during the R-TWTx SP.

4.6 QoS data for R-TWT and QoS control field in null frame

Fig. 27 illustrates an exemplary embodiment 210 of QoS data for an R-TWT and QoS control fields in QoS null frames. It should be noted that in at least one embodiment, the QoS data frame also includes QoS data—cf Ack frames. QoS data and QoS null frames may be indicated by using a reserved frame type (e.g., a combination of type and subtype in a frame control field in IEEE 802.11) that is for an R-TWT, or by transmitting the frame during an R-TWT SP, or by a STA scheduled by an R-TWT scheduling AP or an R-TWT. When QoS data and QoS null frames are for R-TWTs, then the QoS control field as shown in fig. 27 is used in the frame.

The TID field is set to TID representing the data of the frame carrying the QoS control field. The TID may be set to a number between "0" to "7" or "8" to "15" or "0" to "15". This field may also be reserved when transmitted in QoS null frames.

The EOSP field is set by the STA scheduled by the R-TWT to indicate whether it has transmitted all frames of the scheduled UL and/or P2P traffic flow for the R-TWT during the SP of the R-TWT. If this field is set to a first state (e.g., "1"), then the R-TWT scheduled STA has transmitted all frames of the R-TWT's scheduled UL and P2P traffic flows during the SP of the R-TWT. Otherwise, the field is set to a second state (e.g., "0") and the R-TWT scheduled STA has more frames of the R-TWT's scheduled UL and P2P traffic flows during the SP of the R-TWT. If this field is sent in a QoS data frame, this information is acknowledged by the R-TWT scheduling AP when the R-TWT scheduling AP sends feedback indicating that all data frames of the scheduled traffic flow in the same PPDU (or the entire PPDU) of the QoS data frame were successfully received. The R-TWT scheduled STA may retransmit the information if the information is not acknowledged by the R-TWT scheduling AP. The R-TWT scheduling AP sets this field to indicate the end of the current R-TWT SP. If the field is set to a first state (e.g., "1"), the current R-TWT SP ends. Otherwise, the field is set to a second state (e.g., "0") and the current R-TWT SP does not end. The STA can recognize the end of the R-TWT SP by receiving this field.

The Ack policy indicator field may be identical to that in the QoS control field defined in IEEE 802.11. The a-MSDU present field may be identical to that in the QoS control field defined in IEEE 802.11.

The HT control present field is set to indicate whether the HT control field is present in the MAC header of the frame. When this field is set to a first state (e.g., "1"), then there is an HT control field. The HT control field may carry additional information such as BSR. When this field is set to a second state (e.g., "0"), then there is no HT control field in the MAC header.

4.7 examples of terminating R-TWT

This section describes several examples of termination of R-TWT SP. As explained in section 4.3, the R-TWT may be scheduled by the R-TWT scheduling AP. The STAs of the R-TWT schedule request membership of the R-TWT and negotiate the scheduled SCS traffic flows for the R-TWT.

In the example of this section, the R-TWT scheduling AP and R-TWT scheduled STA may embed a QoS control field as shown in FIG. 27 in QoS data or QoS null frames.

Table 1 lists five SCS traffic streams scheduled to be transmitted during SPs of different R-TWTs.

SCS1 is established between MLD2 and MLD 1. The direction of SCS1 traffic flow is uplink (i.e., traffic flow from MLD2 to MLD 1). The traffic flow is the scheduled traffic flow for R-TWT1 on link 1.

SCS2 is established between STA2 and MLD 1. The direction of the SCS2 traffic flow is downlink (i.e., traffic flow from MLD1 to STA 2). The traffic flow is the scheduled traffic flow for R-TWT1 on link 1.

SCS3 is established between STA2 and STA 1. The direction of SCS3 traffic flow is P2P (i.e., traffic flow from STA2 to STA 1). The traffic flow is the scheduled traffic flow for R-TWT2 on link 1.

SCS4 is established between MLD3 and MLD 1. The direction of SCS4 traffic flow is uplink (i.e., traffic flow from MLD3 to MLD 1). The traffic flow is the scheduled traffic flow for R-TWT4 on link 1 and link 2.

SCS5 is established between MLD3 and MLD 1. The direction of the SCS5 traffic flow is downlink (i.e., traffic flow from MLD1 to MLD 3). The traffic flow is the scheduled traffic flow for R-TWT5 on link 1 and link 2.

SCS6 is established between STA2 and MLD 1. The direction of the SCS6 traffic flow is uplink (i.e., traffic flow from STA2 to MLD 1). The traffic flow is the scheduled traffic flow for R-TWT2 on link 1.

The examples in this section follow the R-TWT schedule as shown in table 1. The network topology shown in fig. 20 is used in the example.

FIG. 28 illustrates an exemplary embodiment 230 of an R-TWT scheduling AP broadcasting QoS null frames with EOSP set to a first state (e.g., "1") to indicate termination of the R-TWT SP. The STAs shown are AP1 232 of MLD1, STA2 234, STA1 236, and other STAs 238 of MLD 2.

During R-TWT1SP 240, AP1 (R-TWT scheduling AP) exchanges frames of SCS1 and SCS2 traffic flows as listed in Table 1 with STA2 and STA1 (R-TWT 1 member STA).

As shown in the figure, to transmit an Uplink (UL) transmission of SCS1, AP1 transmits BSRP 242 to STA1 to request the buffer status of STA 1. Subsequently, STA1 reports the buffer status 244 of the SCS1 traffic stream to AP1 (e.g., STA1 reports the buffer status of the SCS1 traffic stream only in the BSR). Subsequently, AP1 may first begin transmitting Downlink (DL) transmissions 246, shown here as SCS2, to STA 2. The DL PPDU of SCS2 may have EOSP set to a second state (e.g., "0") to indicate that there are more frames of the scheduled traffic stream of R-TWT1 to be transmitted during the current R-TWT1 SP. It should be noted that AP1 can determine whether all expected frames of SCS2 have arrived at its buffer and are sent. STA2 acknowledges receipt 248.

Subsequently, AP1 triggers UL transmission of SCS 1. AP1 is illustrated as triggering two UL transmissions of SCS1, 250 and 256 as shown in the figure. The first UL PPDU 252 of SCS1 has EOSP set to a second state (e.g., "0") indicating that there are more UL PPDUs to transmit during the current R-TWT1 SP. The second UL PPDU 258 of SCS1 has EOSP set to a first state (e.g., "1") indicating that STA1 has no more frames of the scheduled UL traffic stream of R-TWT1 to transmit during the current R-TWT1 SP. AP1 acknowledges (e.g., BA) each uplink 254 and 260. Once STA1 receives the BA in response to the UL PPDU with SCS1 of EOSP set to the first state (e.g., "1"), it indicates that all UL transmissions were successfully received.

Subsequently, since all frames of the scheduled traffic flows (SCS 1 and SCS 2) of R-TWT1 are sent before the scheduled end time of R-TWT1SP, AP1 broadcasts QoS null frame 262 with EOSP set to a first state (e.g., "1") to indicate the end 264 of R-TWT1 SP. Other STAs that receive the QoS null frame may immediately begin contending for the channel.

It should be noted that the DL PPDU and UL PPDU in the figure may be required to carry QoS data or QoS null frames in the frame with the EOSP subfield in the QoS control field as shown in fig. 27. In at least one embodiment/mode/scenario, when one PPDU carries multiple QoS data or QoS null frames, only the last frame may set the EOSP subfield to a first state (e.g., "1"). The EOSP settings in the PPDUs shown in the figure represent the last EOSP subfield values in these PPDUs.

In at least one embodiment/mode/scenario, the DL PPDUs and UL PPDUs in the figure carry neither QoS data nor QoS null frames. Thus, the EOSP subfield is not set in these frames. Instead, more data subfields in the frame may be utilized instead of EOSP subfields, as explained in section 4.5.

In at least one embodiment/mode/scenario, qoS null frames for transmission by an R-TWT scheduled AP with EOSP set to a first state (e.g., "1") are replaced with CF end frames or TWT info frames to indicate the end of R-TWT1 SP.

During R-TWT SP, the R-TWT scheduling AP and the R-TWT1 member STA should use the EOSP subfield or more data subfields, but should not use both.

FIG. 29 illustrates an exemplary embodiment 270 of an R-TWT scheduling AP broadcasting QoS null frames with EOSP set to a first state (e.g., "1") to indicate termination of the R-TWT SP. The former example may occur when the trigger field in the request type field in the broadcast TWT parameter information field of R-TWT1 is set to a first state (e.g., "1") by the R-TWT scheduling AP, and this example may occur when the trigger field in the request type field in the broadcast TWT parameter information field of R-TWT1 is set to a second state (e.g., "0") by the R-TWT scheduling AP. The STAs shown are AP1 232 of MLD1, STA2 234, STA1 236, and other STAs 238 of MLD 2.

During R-TWT1SP 240, AP1 (R-TWT scheduling AP) exchanges frames of SCS1 and SCS2 traffic flows as listed in Table 1 with STA2 and STA1 (R-TWT 1 member STA).

As shown, to send an Uplink (UL) transmission of SCS1, STA1 implements a backoff 272 to contend for the channel. When it gains channel access, it begins transmitting UL PPDUs 274 and 278 carrying SCS1 frames, and AP1 acknowledges receipt 276, 280 of these frames. When STA1 sends the last frame of SCS1, it sets EOSP to a first state (e.g., "1") in that frame. When AP1 sends BA 280 to indicate that the PPDU carrying the last frame of SCS1 has been successfully received, this indicates that STA1 has sent all frames of its R-TWT1 scheduled UL and/or P2P traffic stream during R-TWT1 SP.

AP1 also contends for channel 282 to send a frame of the scheduled Downlink (DL) traffic stream 284 (i.e., SCS 2) of R-TWT1 to STA 2. The DL PPDU of SCS2 may set EOSP to a second state (e.g., "0") to indicate that R-TWT1SP does not end, even though all frames of the scheduled traffic stream of R-TWT1 will be transmitted after the PPDU is successfully received.

After STA2 transmits BA 286 to indicate that the DL PPDU of SCS2 was successfully received, all frames of the scheduled traffic streams of R-TWT1 (i.e., SCS1 and SCS 2) have been transmitted before the scheduled end of R-TWT1 SP. Subsequently, AP1 broadcasts a QoS null frame 288 with EOSP set to a first state (e.g., "1") to indicate the end of R-TWT1SP, and then the scheduled end time 264 of R-TWT SP occurs. Other STAs that receive the QoS null frame may immediately begin contending for the channel.

It should be noted that the DL PPDU and UL PPDU in the figure may be required to carry QoS data or QoS null frames in the frame with the EOSP subfield in the QoS control field as shown in fig. 27. In at least one embodiment/mode/scenario, when one PPDU carries multiple QoS data or QoS null frames, only the last frame sets the EOSP subfield to a first state (e.g., "1"). The EOSP settings in the PPDUs shown in the figure represent the last EOSP subfield values in these PPDUs.

In at least one embodiment/mode/scenario, the DL PPDUs and/or UL PPDUs in the figures carry neither QoS data nor QoS null frames. Thus, the EOSP subfield is not set in these frames. Instead, more data subfields in the frame may be used in place of the EOSP subfield, as explained in section 4.5.

In at least one embodiment/mode/case, a QoS null frame with EOSP set to a first state (e.g., "1") may be replaced with a CF end frame or TWT information frame to indicate the end of R-TWT1 SP.

During R-TWT SP, the R-TWT scheduling AP and the R-TWT1 member STA should use the EOSP subfield or more data subfields, but should not use both at the same time.

FIG. 30 illustrates an exemplary embodiment 310 of a termination indication of an R-TWT SP that is not successfully received. In this example, assume that STA2 and STA1 operate in a power save mode. The STAs shown are the same as in the previous figures, namely AP1 232 of MLD1, STA2 234, STA1236 and other STAs 238 of MLD 2.

During R-TWT1SP 240, AP1 (R-TWT scheduling AP) exchanges frames of SCS1 and SCS2 traffic flows as listed in Table 1 with STA2 and STA1 (R-TWT 1 member STA).

As shown in the figure, to check that STA1 and STA2 are awake during R-TWT1SP, AP1 transmits a trigger frame 312 to STA2 and STA 1. STA2 sends a PS poll 314 to indicate that it is awake and ready to receive its scheduled DL traffic stream of R-TWT1 from the R-TWT scheduling AP. STA1 sends a QoS null frame 316 to indicate that it is awake. The QoS null frame may carry a BSR in the HT control field to report the buffer of the scheduled traffic flow of R-TWT1 on its side. AP1 responds to the QoS null frame with BA 318.

If the QoS null frame does not carry a BSR in the HT control field, the R-TWT scheduling AP may transmit BSRP 320 to request from STA1 a BSR 322 for a buffer of scheduled traffic flow for R-TWT1 at STA1, as shown in the figure.

Subsequently, AP1 triggers 324 UL transmission 326 of SCS 1. As shown in the figure, AP1 triggers UL transmission of SCS1 twice. As shown in the figure, the first UL PPDU 326 of SCS1 has EOSP set to a first state (e.g., "1") indicating that there are no more UL PPDUs to transmit during the current R-TWT1 SP. But BA response 328 indicates that retransmission is needed and AP1 sends another trigger frame 330 for UL transmission 332 of SCS 1. This second UL PPDU 332 of SCS1 has EOSP set to a first state (e.g., "1") and its response BA 334 frame indicates that UL transmission was successful. Subsequently, STA1 ends its UL transmission of the scheduled traffic flow of R-TWT1 during the current R-TWT1 SP. STA1 may go to sleep immediately since it is operating in power save mode and only R-TWT1 scheduled UL traffic flows.

Subsequently, AP1 is shown starting a Downlink (DL) transmission 336 to SCS2 of STA 2. The DL PPDU of SCS2 may have EOSP set to a first state (e.g., "1") to indicate that there are no more scheduled traffic transmissions of R-TWT1 to send during the current R-TWT1 SP. But response BA 338 from STA2 indicates that retransmission is required and thus R-TWT1SP cannot end.

AP1 sends another DL PPDU 340 with SCS2 of EOSP set to a first state (e.g., "1") for retransmission. It should be noted that the PPDU only needs to carry frames that require retransmission. When STA2 sends back a BA 342 to indicate that the DL PPDU of SCS2 with EOSP set to the first state (e.g., "1") was successfully received, then STA2 recognizes that the current R-TWT1 SP is terminated. Since it operates in the power saving mode, STA2 may then immediately go to sleep (enter sleep mode).

AP1 may broadcast QoS null frames 344 with EOSP set to a first state (e.g., "1"). The other STAs that receive the frame may thus recognize the end 264 of the R-TWT1 SP and immediately begin contending for the channel.

It should be noted that the DL PPDU and UL PPDU in the figure may be required to carry QoS data or QoS null frames in the frame with the EOSP subfield in the QoS control field as shown in fig. 27. In at least one embodiment/mode/scenario, when one PPDU carries multiple QoS data or QoS null frames, only the last frame may set the EOSP subfield to a first state (e.g., "1"). The EOSP settings in the PPDUs shown in the figure represent the last EOSP subfield values in these PPDUs.

In at least one embodiment/mode/scenario, the DL PPDUs and UL PPDUs in the figure carry neither QoS data nor QoS null frames. Thus, the EOSP subfield is not set in these frames. Instead, more data subfields in the frame may be used in place of the EOSP subfield, as explained in section 4.5.

In at least one embodiment/mode/scenario, qoS null frames sent by the R-TWT scheduling AP with EOSP set to a first state (e.g., "1") may be replaced with CF end frames or TWT info frames to indicate the end of R-TWT1 SP.

During R-TWT SP, the R-TWT scheduling AP and the R-TWT1 member STA should use the EOSP subfield or more data subfields, but should not use both at the same time.

Fig. 31 illustrates an exemplary embodiment 370 of the STA transmitting QoS null frames with EOSP set to a second state (e.g., "0") to end the TXOP sharing time triggered during R-TWT SP. The STAs shown are the same as in the previous figures, namely AP1 232 of MLD1, STA2 234 of MLD2, STA1 236 and other STAs 238.

During R-TWT2SP 240, AP1 (R-TWT scheduling AP) exchanges frames of SCS3 and SCS6 traffic flows as listed in Table 1 with STA2 (R-TWT 2 member STA).

As shown in the figure, to send the P2P transmission of SCS3, AP1 sends BSRP 372 to STA2 to request the buffer status of STA 1. STA1 may then report the buffer status of the SCS3 traffic stream to AP1 (e.g., STA3 reports the buffer status of the SCS3 traffic stream only in BSR 374). AP1 may then begin initiating P2P transmissions of SCS 3. AP1 may send MU-RTS TXS frame 376 as defined in IEEE 802.11be to share TXOP time with STA 2. After STA2 transmits CTS frame 378 in response to the MU-RTS TXS frame, it begins transmitting SCS 3P 2P PPDUs 380 and 384 to STA1 and receiving BAs 382 and 386. After STA2 ends the P2P transmission, it sends a QoS null frame 388 with EOSP set to a second state (e.g., "0") to indicate the end of the triggered TXOP sharing; but STA2 has additional frames of the scheduled traffic flow for R-TWT2 to transmit during the current R-TWT2 SP.

AP1 sends BSRP 390 to request this BSR from STA2 to report its SCS6 UL buffer 392. AP1 then sends another MU-RTS TXS frame 394 to begin another triggered TXOP sharing of UL transmissions for SCS 6. After this, STA2 transmits a CTS 396 and a subsequent UL PPDU 398 with SCS6 of EOSP set to a first state (e.g., "1") indicating that STA2 ended all frame transmissions of its R-TWT2 scheduled UL and P2P traffic streams during the current R-TWT2 SP. The EOSP being set to a first state (e.g., "1") also indicates the end of the triggered TXOP sharing time. AP1 acknowledges receipt with BA 400.

It should be noted that AP1 uses MU-RTS TXS frames instead of trigger frames for UL PPDU transmissions because AP1 may not be able to distinguish between P2P buffers and UL buffers in the BSR. Because there is a scheduled P2P traffic flow for R-TWT2, AP1 starts triggered TXOP sharing using MU-RTS TXS frames. That is, when both P2P traffic and UL traffic are scheduled during the R-TWT SP, the R-TWT scheduling AP should use the MU-RTS TXS frame to trigger P2P traffic and UL traffic.

Subsequently, since all frames of the scheduled traffic flows (i.e., SCS3 and SCS 6) of R-TWT2 are sent before the scheduled end time of R-TWT2SP, AP1 broadcasts QoS null frame 402 with EOSP set to a first state (e.g., "1") to indicate the end 264 of R-TWT2 SP. Other STAs that receive the QoS null frame may immediately begin contending for the channel.

It should be noted that the UL PPDU in the figure may be required to carry QoS data or QoS null frames with the EOSP subfield in the QoS control field as shown in fig. 27 in the frame. In at least one embodiment/mode/scenario, when one PPDU carries multiple QoS data or QoS null frames, only the last frame may set the EOSP subfield to a first state (e.g., "1"). The EOSP settings in the PPDUs shown in the figure represent the last EOSP subfield values in these PPDUs.

In at least one embodiment/mode/scenario, the UL PPDUs in the figure do not carry QoS data or QoS null frames. Therefore, the EOSP subfield is not set in these frames. Instead, more data subfields in the frame may be utilized instead of EOSP subfields, as explained in section 4.5.

In at least one embodiment/mode/case, a QoS null frame with EOSP set to a first state (e.g., "1") may be replaced with a CF end frame or TWT information frame to indicate the end of R-TWT1 SP.

During R-TWT SP, the R-TWT scheduling AP and the R-TWT1 member STA should use the EOSP subfield or more data subfields, but should not use both.

The signal for ending the triggered TXOP sharing may be used by the STA at any time and is not limited to only the R-TWT SP. In at least one embodiment/mode/case, a QoS null frame with EOSP requests Ack/BA for feedback.

It should be noted that during the triggered TXOP sharing time triggered by one MU-RTS TXS frame, the STA that is the intended recipient of the MU-RTS TXS frame may send any desired number of PPDUs during the triggered TXOP sharing time interval.

Fig. 32 illustrates an exemplary embodiment 430 of a STA transmitting QoS null frames with EOSPs set to a first state (e.g., "1") to end the TXOP sharing time triggered during R-TWT SP. This example also shows the case where the STA sends a frame carrying a BSR reporting an empty buffer to end the TXOP sharing time triggered during the R-TWT SP. The STAs shown are the same as in the previous figures, namely AP1 232 of MLD1, STA2 234 of MLD2, STA1 236 and other STAs 238.

During R-TWT2SP 240, AP1 (R-TWT scheduling AP) exchanges frames of SCS3 and SCS6 traffic flows as listed in Table 1 with STA2 (R-TWT 2 member STA).

As shown in the figure, to send P2P and/or UL transmissions of SCS3 and SCS6, AP1 sends BSRP 432 to STA2 to request the buffer status of STA 1. STA1 may then report Buffer Status (BSR) 434 to AP1 (e.g., STA3 may report buffer status of SCS3 and SCS6 traffic flows only in BSR). AP1 may then send MU-RTS TXS frame 436 as defined in ieee802.11be to share some TXOP time with STA 2. After STA2 transmits CTS frame 438 in response to the MU-RTS TXS frame, it begins transmitting UL PPDU 440 of SCS6 to AP 1. The UL PPDU includes a BSR indicating that the buffer is empty. The UL PPDU may then be used to indicate that the triggered TXOP sharing may have ended, but STA2 has more frames of the R-TWT2 scheduled traffic flow to transmit during R-TWT2 SP. AP1 responds with BA frame 442 after successful receipt of the UL PPDU of SCS6 to end the triggered TXOP sharing.

Subsequently, AP1 sends BSRP 444 to request BSR from STA2 and STA2 reports its buffer status 446, this time with BSR frames to report more frames of its scheduled traffic flow with R-TWT2 in the buffer. AP1 then sends another MU-RTS TXS frame 448 to begin another triggered TXOP sharing and STA3 uses it to send a P2P transmission of SCS3 to STA1, as shown in the figure. STA2 transmits CTS 450 and then begins P2P transmission 452. After the P2P transmission is complete and STA2 receives the BA 454 from STA1, then STA2 sends a QoS null frame 456 with EOSP set to a first state (e.g., "1") to AP 1. The QoS null frame indicates that STA2 has completed transmission of all frames of the scheduled UL and P2P traffic flows of R-TWT2 during the current R-TWT2 SP. It should be noted that AP1 uses MU-RTS TXS frames instead of trigger frames for UL PPDU transmissions because in some cases AP1 may not be able to distinguish between P2P buffers and UL buffers in the BSR. Because there is a scheduled P2P traffic flow for R-TWT2, AP1 starts triggered TXOP sharing using MU-RTS TXS frames. That is, when both P2P traffic and UL traffic are scheduled during the R-TWT SP, the R-TWT scheduling AP should use the MU-RTS TXS frame to trigger P2P traffic and UL traffic.

Subsequently, since all frames of the scheduled traffic flows (i.e., SCS3 and SCS 6) of R-TWT2 are sent before the scheduled end time of R-TWT2SP, AP1 broadcasts QoS null frame 458 with EOSP set to a first state (e.g., "1") to indicate end 264 of R-TWT2 SP. Other STAs that receive the QoS null frame may recognize that they may immediately begin contending for the channel.

It should be noted that the UL PPDU in the figure may be required to carry QoS data or QoS null frames with the EOSP subfield in the QoS control field as shown in fig. 27 in the frame. In at least one embodiment/mode/scenario, when one PPDU carries multiple QoS data or QoS null frames, only the last frame may set the EOSP subfield to a first state (e.g., "1"). The EOSP settings in the PPDUs shown in the figure represent the last EOSP subfield values in these PPDUs.

In at least one embodiment/mode/scenario, the UL PPDUs in the figure carry neither QoS data nor QoS null frames. Thus, the EOSP subfield is not set in these frames. Instead, more data subfields in the frame may be utilized instead of EOSP subfields, as explained in section 4.5.

In at least one embodiment/mode/case, a QoS null frame with EOSP set to a first state (e.g., "1") may be replaced with a CF end frame or TWT information frame to indicate the end of R-TWT1 SP.

During R-TWT SP, the R-TWT scheduling AP and the R-TWT1 member STA should use the EOSP subfield or more data subfields, but should not use both at the same time.

The signal for ending the triggered TXOP sharing may be utilized by the STA at any time and is not limited to use in R-TWT SPs. In at least one embodiment/mode/case, qoS null frames with EOSP requests operate as Ack/BA for feedback.

It should be noted that during the triggered TXOP sharing time triggered by one MU-RTS TXS frame, the STA that is the intended recipient of that MU-RTS TXS frame may send any desired number of PPDUs to be accommodated within the triggered TXOP sharing time.

Fig. 33 illustrates an exemplary embodiment 470 of an R-TWT scheduling AP scheduling transmissions of STAs that are R-TWT schedules that are not R-TWT member STAs during an R-TWT SP. The STAs shown are the same as in the previous figures, namely AP1 232 of MLD1, STA2 234 of MLD2, STA1 236 and other STAs 238.

This example is similar to the example shown in fig. 28, except for the operations performed after UL transmission.

During R-TWT1SP 240, AP1 (R-TWT scheduling AP) exchanges frames of SCS1 and SCS2 traffic flows as listed in Table 1 with STA2 and STA1 (R-TWT 1 member STA). To send an Uplink (UL) transmission of SCS1, AP1 sends BSRP 472 to STA1 to request the buffer status of STA 1. Subsequently, STA1 reports the buffer status 474 of the SCS1 traffic stream to AP1 (e.g., STA1 reports the buffer status of the SCS1 traffic stream only in the BSR). Subsequently, AP1 may first begin transmitting Downlink (DL) transmissions 476, shown here as SCS2, to STA 2. The DL PPDU of SCS2 may have EOSP set to a second state (e.g., "0") to indicate that there are more frames of the scheduled traffic stream of R-TWT1 to be transmitted during the current R-TWT1 SP. It should be noted that AP1 can determine whether all expected frames of SCS2 have arrived at its buffer and are sent. STA2 acknowledges reception 478.

Subsequently, AP1 triggers two UL transmissions of SCS1, as shown at 480 and 486. The first UL PPDU 482 of SCS1 has EOSP set to a second state (e.g., "0") indicating that there are more UL PPDUs to transmit during the current R-TWT1 SP. The second UL PPDU 488 of SCS1 has the EOSP set to a first state (e.g., "1") indicating that STA1 has no more frames of the scheduled UL traffic stream of R-TWT1 to transmit during the current R-TWT1 SP. AP1 acknowledges (e.g., BA) each uplink 484 and 490.

The difference from fig. 28 occurs when all frames of the scheduled traffic streams (i.e., SCS1 and SCS 2) of R-TWT1 are sent before the scheduled end time of R-TWT1 SP. Instead of transmitting QoS null frames with EOSPs set to a first state (e.g., "1") as shown in fig. 28, in fig. 33, AP1 transmits a basic trigger frame 492 to STA3 to trigger UL transmissions 494 from STA3 and responds with a BA 496 at the end 264 of the scheduled R-TWT1 SP. Upon sending trigger 492, assume that AP1 has determined the buffer status of STA 3.

In at least one embodiment/mode/scenario, AP1 transmits BSRP to request the buffer status of STA3 before triggering UL transmissions from STA 3. Subsequently, under the trigger of the basic trigger frame, STA3 may transmit a UL PPDU to AP 1. It should be noted that STA3 is an R-TWT scheduled STA that is not a member of R-TWT1 SP. In at least one embodiment/mode/scenario, AP1 is only allowed to schedule transmissions for R-TWT scheduled STAs that are not members of the current R-TWT SP. That is, for example, AP1 should not trigger any transmission by STA 6.

It should be noted that the basic trigger frame sent only to the R-TWT non-member STA may indicate the end of the current R-TWT SP. To indicate the termination of the current R-TWT SP, the basic trigger frame may have to set its more TF fields equal to the second state (e.g. "0"). For example, the AP1 may transmit a plurality of basic trigger frames to non-member STAs of the R-TWT 1. The last basic trigger frame should set more TF fields to the second state (e.g., "0"), and the other basic trigger frames should set more TF fields to the first state (e.g., "1").

The frame exchange between the R-TWT scheduling AP and the R-TWT non-member STAs must complete or otherwise terminate before the scheduled end time of the R-TWT SP.

Fig. 34 illustrates an exemplary embodiment 530 of an R-TWT scheduling AP waiting for scheduled UL traffic to arrive during an R-TWT SP. During R-TWT1 SP, AP1 (R-TWT scheduling AP) exchanges frames of SCS1 and SCS2 traffic flows as listed in Table 1 with STA2 and STA1 (R-TWT 1 member STA). The STAs shown are the same as in the previous figures, namely AP1 232 of MLD1, STA2 234 of MLD2, STA1 236 and other STAs 238.

As shown in the figure, to transmit an Uplink (UL) transmission of SCS1, AP1 transmits BSRP 532 to STA1 to request the buffer status of STA1. STA1 may then report the buffer status 534 of the SCS1 traffic stream to AP1 (e.g., STA1 reports the buffer status of the SCS1 traffic stream only in BSR). But in this example STA1 reports its buffer status as empty 534. At this time, the frame of the scheduled traffic stream SCS1 has not yet arrived at STA1.

Subsequently, AP1 starts sending Downlink (DL) transmissions 536 and 540 of SCS2 to STA2 and receives BAs 538 and 542. The DL PPDU of SCS2 may have EOSP set to a second state (e.g., "0") to indicate that there are more frames of the scheduled traffic stream of R-TWT1 to be transmitted during the current R-TWT1 SP. It should be noted that AP1 may determine/identify whether all expected frames of SCS2 have arrived at its buffer and are transmitted.

Subsequently, AP1 sends another BSRP 544 to request the buffer status of STA1, and STA1 responds with a BSR frame 546 indicating that its buffer is not empty. That is, the frame of the scheduled traffic flow of SCS1 has arrived at STA1.AP1 triggers 548 UL transmission of SCS 1. As shown in the figure, AP1 only triggers UL transmission of a single (one time) SCS 1. As shown in the figure, the UL PPDU 550 of SCS1 has an EOSP set to a first state (e.g., "1") that indicates that STA1 ends the frame transmission of its R-TWT1 scheduled UL traffic stream during the current R-TWT1 SP. AP1 acknowledges receipt of UL PPDU 550 by transmitting BA 552.

After the UL transmission of SCS1 is completed, all frames of the scheduled traffic flow during R-TWT1SP have been sent. AP1 broadcasts a QoS null frame 554 with EOSP set to a first state (e.g., "1") to indicate the end 264 of R-TWT1 SP. Other STAs that receive the QoS null frame may immediately begin contending for the channel.

It should be noted that the DL PPDU and UL PPDU in the figure may be required to carry QoS data or QoS null frames in the frame with the EOSP subfield in the QoS control field as shown in fig. 27. In at least one embodiment/mode/scenario, when one PPDU carries multiple QoS data or QoS null frames, only the last frame may set the EOSP subfield to a first state (e.g., "1"). The EOSP settings in the PPDUs shown in the figure represent the last EOSP subfield values in these PPDUs.

In at least one embodiment/mode/scenario, the DL PPDUs and UL PPDUs in the figures carry neither QoS data nor QoS null frames; the EOSP subfield is not set in these frames. Instead, more data subfields in the frame may be utilized instead of EOSP subfields, as explained in section 4.5.

In at least one embodiment/mode/case, a QoS null frame with EOSP set to a first state (e.g., "1") may be replaced with a CF end frame or TWT information frame to indicate the end of R-TWT1 SP.

During R-TWT SP, the R-TWT scheduling AP and the R-TWT1 member STA should use the EOSP subfield or more data subfields, but should not use both at the same time.

FIG. 35 illustrates an exemplary embodiment 570 of an R-TWT scheduling AP terminating an R-TWT SP if there are no more frames of the scheduled traffic flow for the R-TWT to send. During R-TWT1 SP, AP1 (R-TWT scheduling AP) exchanges frames of SCS1 and SCS2 traffic flows as listed in Table 1 with STA2 and STA1 (R-TWT 1 member STA). The STAs shown are the same as in the previous figures, namely AP1 232 of MLD1, STA2 234 of MLD2, STA1 236 and other STAs 238.

As shown in the figure, to transmit an Uplink (UL) transmission of SCS1, AP1 transmits BSRP 532 to STA1 to request the buffer status of STA1. STA1 may then report the buffer status of the SCS1 traffic stream to AP1 (e.g., STA1 reports the buffer status of the SCS1 traffic stream only in the BSR). But this time STA1 reports that its buffer status 534 is empty. The frames of the scheduled traffic stream SCS1 have not yet arrived at STA1.

Subsequently, AP1 may begin sending Downlink (DL) transmissions of SCS2 to STA 2. The DL PPDU of SCS2 may have SCS2 frames with EOSP set to a second state (e.g., "0") to indicate that there are more frames of the scheduled traffic stream of R-TWT1 to be transmitted during the current R-TWT1 SP. It should be noted that AP1 determines/recognizes whether all frames of SCS2 have arrived at its buffer and are being transmitted. Accordingly, multiple DL transmissions 536 and 540 to different stations are implemented and acknowledged 538 and 574. It should be noted that DL PPDU 540 is the last DL PPDU 572 of SCS2 to be transmitted.

Subsequently, AP1 sends another BSRP 576 to request the buffer status of STA1, and STA1 responds with a BSR frame 578 indicating that its buffer is still empty.

Since there are no frames of the scheduled traffic flow for R-TWT1 to send at the buffer, AP1 broadcasts a QoS null frame 580 with EOSP set to a first state (e.g., "1") to indicate the end 264 of R-TWT1 SP. Other STAs receive the QoS null frame and recognize that they can immediately begin contending for the channel.

It should be noted that the DL PPDU in the figure may be required to carry QoS data or QoS null frames with the EOSP subfield in the QoS control field as shown in fig. 27. In at least one embodiment/mode/scenario, when one PPDU carries multiple QoS data or QoS null frames, only the last frame will set the EOSP subfield to a first state (e.g., "1"). The EOSP settings in the PPDUs shown in the figure represent the last EOSP subfield values in these PPDUs.

In at least one embodiment/mode/scenario, the DL PPDUs in the figure carry neither QoS data nor QoS null frames; the EOSP subfield is not set in these frames. Instead, more data subfields in the frame may be used in place of the EOSP subfield, as explained in section 4.5.

In at least one embodiment/mode/case, a QoS null frame with EOSP set to a first state (e.g., "1") may be replaced with a CF end frame or TWT information frame to indicate the end of R-TWT1 SP.

During R-TWT SP, the R-TWT scheduling AP and R-TWT1 member STA should use the EOSP subfield or more data subfields; but not both should be used.

Fig. 36 illustrates an exemplary embodiment 630 of an R-TWT scheduling AP exchanging frames with an R-TWT non-member STA while waiting for the arrival of scheduled traffic. During R-TWT1 SP, AP1 (R-TWT scheduling AP) exchanges frames of SCS1 and SCS2 traffic flows as listed in Table 1 with STA2 and STA1 (R-TWT 1 member STA). The STAs shown are the same as in the previous figures, namely AP1 232 of MLD1, STA2 234 of MLD2, STA1 236 and other STAs 238.

As shown in the figure, to transmit an Uplink (UL) transmission of SCS1, AP1 transmits BSRP 532 to STA1 to request the buffer status of STA1. STA1 may then report the buffer status of the SCS1 traffic stream to AP1 (e.g., STA1 reports the buffer status of the SCS1 traffic stream only in the BSR). But in this example STA1 reports that its buffer status 534 is empty. The frames of the scheduled traffic stream SCS1 have not yet arrived at STA1.

Subsequently, AP1 begins sending Downlink (DL) transmissions 536 and 540 of SCS2 to STA2 and receives acknowledgements (BAs) 538 and 632 as seen in the figure. It should be noted that DL PPDU540 is the last (572) DL PPDU of SCS2 to be transmitted. The DL PPDU of SCS2 may have EOSP set to a second state (e.g., "0") to indicate that there are more frames of the scheduled traffic stream of R-TWT1 to be transmitted during the current R-TWT1 SP. It should be noted that AP1 determines/recognizes whether all expected frames of SCS2 have arrived at its buffer and are being transmitted.

AP1 then sends another BSRP 634 to request the buffer status of STA1, STA1 responding with a BSR frame 636 indicating that its buffer is still empty.

Since there are no more frames of the scheduled traffic stream for R-TWT1 to transmit at the buffer, AP1 transmits DL PPDU 638 to STA3, which is an R-TWT scheduled STA but is not an R-TWT1 member STA. After ending DL transmission to STA3 and receiving BA 640, AP1 then sends another BSRP 642 for the buffer report to STA 1. This time, STA1 reports (BSR 644) the buffer of SCS1 and AP1 immediately sends a basic trigger 646 to trigger UL transmission 648 of SCS 1. There is only one UL PPDU of SCS1, and STA1 sets the EOSP field to a first state (e.g., "1") in the last MPDU in the UL PPDU. When AP1 transmits BA 650 to indicate that UL PPDU of SCS1 has been successfully transmitted, R-TWT1SP ends, it should be noted that the BA is transmitted after scheduled end time 264 of R-TWT1 SP.

This example also shows the following possibilities: the R-TWT SP may be extended if all frames of the R-TWT's scheduled traffic flow cannot be transmitted before the scheduled end time of the R-TWT SP. For example, as shown in the figure, the end of R-TWT1 SP is later than its scheduled end time. The R-TWT SP may be extended by the TXOP holder, thereby extending the current TXOP. For example, as shown in the figure, the last trigger frame sent by AP1 may extend the TXOP.

It should be noted that the DL PPDU and UL PPDU in the figure may be required to carry QoS data or QoS null frames in the frame with the EOSP subfield in the QoS control field as shown in fig. 27. In at least one embodiment/mode/scenario, when one PPDU carries multiple QoS data or QoS null frames, only the last frame may set the EOSP subfield to a first state (e.g., "1"). The EOSP settings in the PPDUs shown in the figure represent the last EOSP subfield values in these PPDUs.

In at least one embodiment/mode/scenario, the DL PPDUs and UL PPDUs in the figures carry neither QoS data nor QoS null frames; there is no associated EOSP subfield to set in these frames. Instead, more data subfields in the frame may be utilized instead of EOSP subfields, as explained in section 4.5.

In at least one embodiment/mode/case, a QoS null frame with EOSP set to a first state (e.g., "1") may be replaced with a CF end frame or TWT information frame to indicate the end of R-TWT1 SP.

During R-TWT SP, the R-TWT scheduling AP and R-TWT1 member STA should use the EOSP subfield or more data subfields; but not both should be used simultaneously.

Fig. 37 illustrates an exemplary embodiment 670 of separate termination of a multi-link R-TWT SP on each link. In this example, the R-TWT schedules the AP to send a signal on one link to terminate the SP of the multilink R-TWT on that link. Exemplary STAs are shown as STA3 676 and STA5 678 of MLD3 672, and AP1 680 and AP2 682 of MLD1 674.

As shown, R-TWT4 684 is declared by R-TWT scheduling AP MLD1 and R-TWT4SP is scheduled on both link 1 and link 2. As explained in section 4.3, R-TWTs on multiple links may be indicated by multiple broadcast TWT parameter set fields in one TWT unit with the same R-TWT ID and different link IDs. For example, by having an R-TWT ID set to R-TWT4 and a link ID set to one broadcast TWT parameter set field of link 1 and an R-TWT ID set to R-TWT4 and a link ID set to another broadcast TWT parameter set field of link 2 in the TWT unit in its beacon frame, AP MLD1 may assert R-TWT4SP on link 1 and link 2. By transmitting a TWT setup frame on link 1 or link 2, a STA of R-TWT scheduling may request membership of R-TWT4 SPs on link 1 and link 2, with the TWT unit of the TWT setup frame having R-TWT ID set to R-TWT4 and link ID set to one broadcast TWT parameter set field of link 1 and R-TWT ID set to R-TWT4 and link ID set to the other broadcast TWT parameter set field of link 2.

The STA of the R-TWT schedule may respond to the membership request of the R-TWT4 SP on link 1 and link 2 by sending a TWT setup frame on link 1 or link 2 with the TWT unit of the TWT setup frame having the R-TWT ID set to R-TWT4 and the link ID set to one broadcast TWT parameter set field of link 1 and the R-TWT ID set to R-TWT4 and the link ID set to the other broadcast TWT parameter set field of link 2. In at least one embodiment/mode/scenario, a TWT setting frame requesting membership of an R-TWT and a TWT setting frame responding to a membership request may be sent over different links.

In addition, when the non-AP MLD3 requests membership of R-TWT4, it may indicate that SCS5 and SCS4 are scheduled traffic flows of R-TWT 4. During R-TWT4 SP, AP1 and AP2 attached to MLD1 (R-TWT scheduled AP) exchange frames of SCS4 and SCS5 traffic streams as listed in table 1 with STA3 and STA5 attached to MLD3 (R-TWT 4 member STA).

As shown in the figure, to transmit Uplink (UL) transmission of SCS4, AP1 and AP2 transmit BSRP 686 and 688 to STA3 and STA5, respectively, to request buffer status information. STA3 and STA5 may report buffers indicating that they request AP1 and AP2 trigger buffers for transmissions on link 1 and link 2, respectively. Although SCS4 may be transmitted over link 1 and link 2, in some cases STA3 may report buffer status 690 of SCS 4; STA5 may report a null buffer in QoS null frame 692 with EOSP set to a first state (e.g., "1").

AP1 may transmit according to a buffer report trigger (basic trigger 694) received from STA3, shown as UL transmission 698 of SCS4 on link 1. AP2 determines/recognizes that STA5 does not have UL transmissions during R-TWT4 SP on link 2. It should be noted that the MLD3 can make a decision on how to report the buffer on both links.

STA3 transmits UL PPDU 698 with SCS4 set to the EOSP of the first state (e.g., "1") to indicate that this is all frames of the scheduled UL traffic flow for R-TWT4 during the current R-TWT4 SP on STA3 end link 1.

Subsequently, after receiving BA 702 from STA3, AP1 may begin DL transmission 706 of SCS5 on link 1. After AP1 sends all DL transmissions of SCS5 on link 1 and receives BA 712, it broadcasts QoS null frame 714 with EOSP set to a first state (e.g., "1") to indicate termination 716 of R-TWT4 on link 1.

Returning now to link 2, as seen in the figure, after receiving the basic trigger 694, AP2 does not trigger UL transmissions of SCS5 on link 2 according to the buffer report from STA 5. STA5 transmits DL PPDUs 696 and 704 of SCS5, which may have EOSPs set to a second state (e.g., "0"), to indicate that there are more frames of the R-TWT4 scheduled traffic stream to transmit during the current R-TWT4 SP on link 2 and receives BAs 700 and 708 from AP2 (682). Subsequently, AP2 broadcasts a QoS null frame 710 with the EOSP set to a first state (e.g., "1") to indicate the end of the R-TWT4 SP on Link 2.

It should be noted that the DL PPDU and UL PPDU in the figure may be required to carry QoS data or QoS null frames with EOSP subfields in the QoS control field as shown in fig. 27. In at least one embodiment/mode/scenario, when one PPDU carries multiple QoS data or QoS null frames, only the last frame may set the EOSP subfield to a first state (e.g., "1"). The EOSP settings in the PPDUs shown in the figure represent the last EOSP subfield values in these PPDUs.

In at least one embodiment/mode/scenario, DL PPDUs and UL PPDUs, such as seen in the figures, carry neither QoS data nor QoS null frames; there is no EOSP subfield to set in these frames. Instead, more data subfields in the frame may be used in place of the EOSP subfield, as explained in section 4.5.

In at least one embodiment/mode/case, a QoS null frame with EOSP set to a first state (e.g., "1") may be replaced with a CF end frame or TWT information frame to indicate the end of R-TWT1 SP.

During R-TWT SP, the R-TWT scheduling AP and R-TWT1 member STA should use the EOSP subfield or more data subfields; but not both should be used simultaneously.

FIG. 38 illustrates an exemplary embodiment 770 of termination of ML R-TWT SP over a link. In this example, the R-TWT schedules the AP to send a signal on one link to terminate SPs of the same R-TWT scheduled on a different link.

The STAs shown are the same as in the previous figures, namely STA3 676 and STA5678 of MLD3 672, and AP1 680 and AP2 682 of MLD1 674.

As shown, R-TWT4 is declared 684 by R-TWT scheduling AP MLD1 and R-TWT4SP is scheduled on both link 1 and link 2. As explained in section 4.3, R-TWTs on multiple links may be indicated by multiple broadcast TWT parameter set fields in one TWT unit with the same R-TWT ID and different link IDs. For example, by having an R-TWT ID set to R-TWT4 and a link ID set to one broadcast TWT parameter set field of link 1 and an R-TWT ID set to R-TWT4 and a link ID set to another broadcast TWT parameter set field of link 2 in the TWT unit in its beacon frame, AP MLD1 may assert R-TWT4SP on link 1 and link 2. By transmitting a TWT setup frame on link 1 or link 2, a STA of R-TWT scheduling may request membership of R-TWT4 SPs on link 1 and link 2, with the TWT unit of the TWT setup frame having R-TWT ID set to R-TWT4 and link ID set to one broadcast TWT parameter set field of link 1 and R-TWT ID set to R-TWT4 and link ID set to the other broadcast TWT parameter set field of link 2. The STA of the R-TWT schedule may respond to the membership request of the R-TWT4SP on link 1 and link 2 by sending a TWT setup frame on link 1 or link 2 with the TWT unit of the TWT setup frame having the R-TWT ID set to R-TWT4 and the link ID set to one broadcast TWT parameter set field of link 1 and the R-TWT ID set to R-TWT4 and the link ID set to the other broadcast TWT parameter set field of link 2. In at least one embodiment/mode/scenario, a TWT setting frame requesting membership of an R-TWT and a TWT setting frame responding to a membership request may be sent over different links.

In addition, when the non-AP MLD3 requests membership of R-TWT4, it may indicate that SCS5 and SCS4 are scheduled traffic flows of R-TWT 4. During R-TWT4 SP, AP1 and AP2 attached to MLD1 (R-TWT scheduled AP) exchange frames of SCS4 and SCS5 traffic streams as listed in table 1 with STA3 and STA5 attached to MLD3 (R-TWT 4 member STA).

As shown in the figure, to transmit Uplink (UL) transmission of SCS4, AP1 and AP2 transmit BSRP 772 and 774 to STA3 and STA5, respectively, to request buffer status, and STA3 and STA5 may report their buffer status 776 and 778. It should be noted that in this example, STA3 and STA5 report the same buffer status (e.g., STA3 and STA5 report the buffer status of SCS4 traffic stream only in BSR).

Subsequently, AP1 sends a basic trigger frame 780 on link 1 to trigger UL transmission of SCS4 on link 1. STA3 transmits an UL PPDU 784 of SCS4 with EOSP set to a first state (e.g., "1") to indicate that STA3 ends all frame transmissions of the scheduled UL traffic stream for R-TWT4 during the current R-TWT4 SP on link 1 and link 2. Subsequently, after receiving BA 788, AP1 may begin DL transmission 792 of SCS5 on link 1 and receive BA 798 for it.

Returning to the description, based on the buffer report from STA5, AP2 decides not to trigger UL transmission of SCS5 on link 2. That is, one UL PPDU of SCS4 on link 1 is considered to be sufficient. AP2 starts Downlink (DL) transmissions 782, 790 and 796 to SCS5 of STA5 and receives acknowledgements (BAs) 786, 794 and 804.

When AP2 transmits all DL PPDUs of SCS5 on link 2, it cannot terminate R-TWT4 SP because the DL PPDUs of SCS5 are being transmitted on link 1. AP2 may begin some transmissions with STAs that are scheduled R-TWT STAs (such as STA 4), as explained in section 4.4.

After AP1 receives BA frame 798 in response to the last DL PPDU of SCS5 on link 1, indicating that all DL PPDUs of SCS5 were successfully received, AP1 may broadcast QoS null frame 800 with EOSP set to a first state (e.g., "1") to terminate 802R-TWT 4 on link 1 and link 2. AP2 may then also broadcast a QoS null frame 806 with EOSP set to a first state (e.g., "1") on link 2 to terminate 808R-TWT 4 on link 1 and link 2.

It should be noted that the DL PPDU and UL PPDU in the figure may be required to carry QoS data or QoS null frames in the frame with the EOSP subfield in the QoS control field as shown in fig. 27. In at least one embodiment/mode/scenario, when one PPDU carries multiple QoS data or QoS null frames, only the last frame should have the EOSP subfield set to a first state (e.g., "1"). The EOSP settings in the PPDUs shown in the figure represent the last EOSP subfield values in these PPDUs.

In at least one embodiment/mode/scenario, the DL PPDUs and UL PPDUs in the figures carry neither QoS data nor QoS null frames; there is no EOSP subfield to set in these frames. Instead, more data subfields in the frame may be utilized instead of EOSP subfields, as explained in section 4.5.

In at least one embodiment/mode/case, a QoS null frame with EOSP set to a first state (e.g., "1") may be replaced with a CF end frame or TWT information frame to indicate the end of R-TWT1 SP.

During R-TWT SP, the R-TWT scheduling AP and R-TWT1 member STA should use the EOSP subfield or more data subfields; but not both should be used simultaneously.

5. General scope of the examples

Embodiments of the present technology may be described herein with reference to flowchart illustrations of methods and systems according to embodiments of the technology and/or procedures, algorithms, steps, operations, formulas, or other computational depictions that may also be implemented as a computer program product. In this regard, each block or step of the flowcharts, and combinations of blocks (and/or steps) in the flowcharts, and any procedure, algorithm, step, operation, formula, or computational depiction, may be implemented by various means, such as hardware, firmware, and/or software including one or more computer program instructions embodied in computer readable program code. It should be appreciated that any such computer program instructions may be executed by one or more computer processors, including without limitation a general-purpose computer or special-purpose computer, or other programmable processing apparatus to produce a machine, such that the computer program instructions, which execute on the computer processor(s) or other programmable processing apparatus, create means for implementing the specified function(s).

Accordingly, blocks of the flowchart, and combinations of means for performing the specified function(s), combinations of steps for performing the specified function(s), and computer program instructions, such as embodied in computer readable program code logic means, for performing the specified function(s), are described herein as block diagrams. It will also be understood that each block of the flowchart illustrations, and any procedures, algorithms, steps, operations, formulas or computational depictions, and combinations thereof described herein, can be implemented by special purpose hardware-based computer systems which perform the specified function(s) or step(s), or combinations of special purpose hardware and computer readable program code.

Furthermore, such computer program instructions, which are embodied in computer-readable program code, may also be stored in one or more computer-readable memories or memory devices that can direct a computer processor or other programmable processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memories or memory devices produce an article of manufacture including instruction means which implement the function specified in the flowchart block(s). The computer program instructions may also be executed by a computer processor or other programmable processing apparatus to cause a series of operational steps to be performed on the computer processor or other programmable processing apparatus to produce a computer implemented process such that the instructions which execute on the computer processor or other programmable processing apparatus provide steps for implementing the functions specified in the block(s) of the flowchart(s), algorithm(s), step(s), operation(s), formula(s), or computational depiction(s).

It will also be appreciated that the term "program" or "executable program" as used herein refers to one or more instructions that can be executed 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 in a non-transitory medium local to the device, or may be stored remotely, such as on a server, or all or a portion of the instructions may be stored locally and remotely. The remotely stored instructions may be downloaded (pushed) to the device by user initiation or may be automatically downloaded (pushed) to the device based on one or more factors.

It should also be appreciated that the terms processor, hardware processor, computer processor, central Processing Unit (CPU), and computer as used herein are synonymously used to denote a device capable of executing instructions and communicating with input/output interfaces and/or peripheral devices, and that the terms processor, hardware processor, computer processor, CPU, and computer are intended to encompass single or multiple devices, single or multi-core devices, and variations thereof.

As will be appreciated from the description herein, the present disclosure encompasses a variety of implementations of the technology, including but not limited to the following implementations:

an apparatus for wireless communication in a network, the apparatus comprising: (a) Wireless communication circuitry as a Station (STA) separate from or associated with a multi-link device (MLD), wherein the station is configured to wirelessly communicate over a channel with other wireless Stations (STAs) that conduct transmission of frames using carrier sense multiple access/collision avoidance (CSMA/CA) with their packets over a Wireless Local Area Network (WLAN) under the IEEE 802 protocol for a scheduled Service Period (SP) of a limited target wake-up time (R-TWT); (b) A processor coupled to the STA for operation over a WLAN; (c) A non-transitory memory storing instructions executable by the processor for communicating with other STAs in a communication protocol; and (d) wherein the instructions, when executed by the processor, perform one or more steps of declaring an R-TWT schedule to exchange frames with a member STA of the R-TWT, comprising: (d) (i) wherein an Access Point (AP) operative to be configured for implementing R-TWT scheduling, said station being an R-TWT scheduling AP declares R-TWT scheduling and exchanges frames with member STAs of the R-TWT after entering the R-TWT SP; (d) (ii) wherein a termination condition is detected; and (d) (iii) wherein after all frame exchanges are completed during the R-TWT SP, the R-TWT scheduling AP signals in a termination declaration to indicate termination of the R-TWT SP.

An apparatus for wireless communication in a network, the apparatus comprising: (a) Wireless communication circuitry as a Station (STA) separate from or associated with a multi-link device (MLD), wherein the station is configured to wirelessly communicate over a channel with other wireless Stations (STAs) that conduct transmission of frames using carrier sense multiple access/collision avoidance (CSMA/CA) with their packets over a Wireless Local Area Network (WLAN) under the IEEE 802 protocol for a scheduled Service Period (SP) of a limited target wake-up time (R-TWT); (b) A processor coupled to the STA for operation over a WLAN; (c) A non-transitory memory storing instructions executable by the processor for communicating with other STAs; and (d) wherein the instructions, when executed by the processor, perform one or more steps of declaring an R-TWT schedule to exchange frames with a member STA of the R-TWT, comprising: (d) (i) wherein the station operating as an Access Point (AP) configured for implementing R-TWT scheduling schedules the AP as an R-TWT scheduling AP; and wherein the R-TWT schedules the AP and R-TWT member STA to enter the R-TWT SP; (d) (ii) terminating, by the R-TWT scheduling AP, the R-TWT SP before the scheduled end time of the R-TWT SP, and sending a termination declaration on the channel; and (d) (iii) wherein other STAs on the network that are not member STAs of the R-TWT may immediately contend for the channel in response to receiving the termination statement.

An apparatus for wireless communication in a network, the apparatus comprising: (a) Wireless communication circuitry as a Station (STA) separate from or associated with a multi-link device (MLD), wherein the station is configured to wirelessly communicate over a channel with other wireless Stations (STAs) that conduct transmission of frames using carrier sense multiple access/collision avoidance (CSMA/CA) with their packets over a Wireless Local Area Network (WLAN) under the IEEE 802 protocol for a scheduled Service Period (SP) of a limited target wake-up time (R-TWT); (b) A processor coupled to the STA for operation over a WLAN; (c) A non-transitory memory storing instructions executable by the processor for communicating with other STAs; and (d) wherein the instructions, when executed by the processor, perform one or more steps of declaring an R-TWT schedule to exchange frames with a member STA of the R-TWT, comprising: (d) (i) wherein the station operating as an Access Point (AP) configured for implementing R-TWT scheduling is an R-TWT scheduling AP, and the R-TWT member STA enters an R-TWT SP; (d) (ii) exchanging frames between the R-TWT scheduling AP and R-TWT member STAs during the R-TWT SP; and (d) (iii) exchanging frames between the R-TWT scheduling AP and a STA having R-TWT characteristics but not R-TWT member STA after the R-TWT scheduling AP completes the frame exchange with the R-TWT member STA during the R-TWT SP.

A wireless communication system/apparatus that implements transmission of packets, wherein CSMA/CA is applied in the system/apparatus, an R-TWT scheduling AP declares R-TWT scheduling to exchange frames with member STAs of the R-TWT during the R-TWT SP, comprising: (a) The R-TWT schedules the AP and the R-TWT member STA to start the R-TWT SP for frame exchange therebetween; (b) Transmitting a signal to the R-TWT scheduling AP when the R-TWT member STA has no more frames to transmit during the R-TWT SP; and (d) when all frame exchanges during the R-TWT SP end, the R-TWT schedules the AP to send a signal to indicate termination of the R-TWT SP.

The apparatus or method or system of any preceding implementation, wherein the termination condition occurs when the STA operating as an R-TWT member STA sends a signal to the R-TWT scheduling AP after determining that it has no more frames to transmit to indicate that it has no more frames to transmit during an R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the termination condition occurs before a scheduled end time for a R-TWT SP of the R-TWT SP to be terminated by the R-TWT scheduling AP.

The apparatus or method or system of any preceding implementation, further comprising exchanging frames between the R-TWT scheduling AP and R-TWT member STAs during the R-TWT SP.

The apparatus or method or system of any of the previous implementations, further comprising exchanging frames between the R-TWT scheduling AP and STAs that have R-TWT characteristics but are not R-TWT member STAs after the R-TWT scheduling AP completes frame exchanges with the R-TWT member STAs during the R-TWT SP.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: when an R-TWT member STA does not have any Uplink (UL) or peer-to-peer (P2P) frames to transmit during an R-TWT SP, a signal is sent to the R-TWT scheduling AP.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: the R-TWT member STA transmits a frame indicating that it has no frame to transmit during the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the frame indicating that it has no frame to send during the R-TWT SP includes: (a) Frames that are neither quality of service (QoS) data frames nor QoS null frames; and (b) a frame containing a field indicating whether it has more data as a more data field in a state indicating that the R-TWT member STA does not have more frames to transmit during the R-TWT SP.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: the R-TWT member STA transmits QoS data or QoS null frames with an EOSP subfield set to a state indicating that the R-TWT member STA has no UL and/or P2P frames to transmit during the R-TWT SP.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: the R-TWT scheduling AP transmits a QoS data frame or QoS null frame with the EOSP subfield set to a state indicating termination of the R-TWT SP.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: the R-TWT schedules the AP to transmit frames that are neither QoS data frames nor QoS null frames, the frames have a field as a more data field to indicate whether there is more data to transmit, and the more data field is set to a value indicating termination of the R-TWT SP.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: the R-TWT schedules the AP to send a Contention Free (CF) end frame to indicate termination of the R-TWT SP.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: the R-TWT scheduling AP transmits a trigger frame that is not addressed to any particular R-TWT member STA, the trigger frame having a field indicating whether there are more trigger frames, and the field is set to indicate termination of the R-TWT SP.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: the R-TWT scheduling AP transmits TWT information frames with TWT flow identification field set equal to the R-TWT identification to indicate termination of the R-TWT SP.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: in response to receiving a frame from the R-TWT scheduling AP containing an indication that the R-TWT SP has terminated, the member STA identifies that the R-TWT SP has terminated.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: in response to receiving an acknowledgement from the R-TWT scheduling AP indicating that the R-TWT SP has terminated, the member STA identifies that the R-TWT SP has terminated.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: the R-TWT scheduling AP signals over the channel to indicate termination of the R-TWT SP.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: the R-TWT member STA is not allowed to contend for the channel after the R-TWT SP terminates until the scheduled end time of the R-TWT SP arrives.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: the R-TWT member STAs are allowed to contend for the channel at a lower priority than the conventional EDCA parameters set for those R-TWT member STAs until the scheduled end time of the R-TWT SP after the termination of the R-TWT SP.

The apparatus or method or system of any preceding implementation, wherein the instructions, when executed by the processor, further implement the steps of: the R-TWT scheduling AP extends a transmission opportunity (TXOP) for frame exchanges with R-TWT member STAs beyond the scheduled end time of the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the signal may be sent to the R-TWT scheduling AP when the R-TWT member STA does not have any UL or P2P frames to send during the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the R-TWT member STA may send a frame that is neither QoS data nor QoS null frame with a more data field equal to 0 to indicate that it has no frame to send during the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the R-TWT member STA may send QoS data or QoS null frames with an EOSP subfield equal to 1 to indicate that it has no UL and P2P frames to send during the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the R-TWT scheduling AP may send QoS data or QoS null frames with an EOSP subfield equal to 1 to indicate termination of the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the R-TWT scheduling AP may send a frame that is neither QoS data nor QoS null frame with a further data field equal to 0 to indicate termination of the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the R-TWT scheduling AP may send a CF end frame to indicate termination of the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the R-TWT scheduling AP may send a trigger frame having more TF fields equal to 0 and not addressed to any R-TWT member STAs to indicate termination of the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the R-TWT scheduling AP may send a TWT information frame with a TWT flow identification field equal to the R-TWT ID to indicate termination of the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the STA may identify termination of the R-TWT SP when a frame is received from the R-TWT scheduling AP that does not require an immediate response and indicates termination of the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the STA may identify termination of the R-TWT SP when receiving an acknowledgement in response to a frame sent by the R-TWT scheduling AP and indicating termination of the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the R-TWT scheduling AP may send a signal to indicate termination of the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the R-TWT member STAs may not be allowed to contend for the channel after termination of the R-TWT SP until a scheduled end time of the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the R-TWT member STAs may be allowed to contend for the channel with a lower priority after termination of the R-TWT SP until a scheduled end time of the R-TWT SP.

The apparatus or method or system of any of the previous implementations, wherein the R-TWT scheduling AP may extend the TXOP of the frame exchange with the R-TWT member STAs beyond the scheduled end time of the R-TWT SP.

The term "implementation" as used herein is intended to include, without limitation, embodiments, examples, or other forms of practicing the techniques described herein.

As used herein, the singular terms "a," "an," and "the" may include plural referents unless the context clearly dictates otherwise. Unless explicitly stated as such, reference to the singular is not intended to mean "one and only one" but rather "one or more".

Phrase structure descriptions in this disclosure such as "A, B and/or C" may exist for the case of A, B or C or any combination of items A, B and C. For example, a phrase structure in which a group of elements is listed followed by "at least one of" indicates the presence of at least one of those group elements, including any applicable possible combinations of the listed elements.

Reference in the present disclosure to "an embodiment," "at least one embodiment," or similar embodiment language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the various embodiment phrases are not necessarily all referring to the same embodiment or to a particular embodiment different from all other embodiments described. The embodiment phrases should be construed to mean that a particular feature, structure, or characteristic of a given embodiment may be combined in any suitable manner in one or more embodiments of the disclosed apparatus, system, or method.

The term "collection" as used herein refers to a collection of one or more objects. Thus, a collection of objects may comprise, for example, a single object or multiple objects.

Relational terms such as first and second, top and bottom, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.

The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, or comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further constraints, the terms "comprising," "having," "including," and "containing" preceding an element do not exclude the presence of additional identical elements in a process, method, article, or apparatus that comprises, has, contains the element.

The terms "approximately," "substantially," and "approximately" or any other version thereof as used herein are used to describe and explain within a context of a minor variation. When used in connection with an event or circumstance, the term can refer to instances where the event or circumstance occurs precisely and instances where it occurs approximately. When used in conjunction with a numerical value, the term may refer to a range of variation of less than or equal to ±10% of the numerical value, such as less than or equal to ±5%, less than or equal to ±4%, less than or equal to ±3%, less than or equal to ±2%, less than or equal to ±1%, less than or equal to ±0.5%, less than or equal to ±0.1%, or less than or equal to ±0.05%. For example, "substantially" aligned may refer to a range of angular variation of less than or equal to ±10°, such as less than or equal to ±5°, less than or equal to ±4°, less than or equal to ±3°, less than or equal to ±2°, less than or equal to ±1°, less than or equal to ±0.5°, less than or equal to ±0.1°, or less than or equal to ±0.05°.

Furthermore, amounts, ratios, and other numerical values may sometimes be presented herein in a range format. It is to be understood that such range format is used for convenience and brevity and should be interpreted flexibly to include the numerical values explicitly recited as the limits of the range, as well as to include all the individual numerical values or sub-ranges encompassed within that range as if each numerical value and sub-range is explicitly recited. For example, ratios in the range of about 1 to about 200 should be understood to include the explicitly recited boundaries of about 1 and about 200, but also include individual ratios such as about 2, about 3, and about 4, and subranges such as about 10 to about 50, about 20 to about 100, and the like.

The term coupled, as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically. A device or structure that is "configured" in a particular manner is configured in at least that manner, but may also be configured in ways that are not listed.

The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature or element of the techniques described herein or any or all the claims.

Furthermore, 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 lie in less than all features of a single disclosed embodiment.

The Abstract of the disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. Applicant's understanding at the time of filing this abstract, it will not be used to interpret or limit the scope or meaning of the claims.

It should be appreciated that the practice of some jurisdictions may require that one or more portions of the disclosure be deleted after the application is filed. Accordingly, the reader should consult the filed application for the original content of the present disclosure. Any deletion of content from the disclosure should not be construed as disclaimer, or donation to the public of any subject matter of the originally filed application.

The following claims are hereby incorporated into the disclosure, with each claim standing on its own as a separate claimed subject matter.

While the description herein contains many specifics, these should not be construed as limiting the scope of the present disclosure, but merely as providing illustrations of some of the presently preferred embodiments. It should therefore be appreciated that the scope of the present disclosure fully encompasses other embodiments that may become obvious to those skilled in the art.

All structural and functional equivalents to the elements of the disclosed embodiments that are known to those skilled in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. The phrase "means for …" should not be construed as "means plus function" elements unless the claim elements herein are explicitly recited. Unless the phrase "step for …" is used explicitly to enumerate the claim elements herein, the elements should not be interpreted as "step plus function" elements.

TABLE 1 SCS traffic flows scheduled to be sent during R-TWT SP

/>

Claims (22)

1. An apparatus for wireless communication in a network, the apparatus comprising:

(a) Wireless communication circuitry as a Station (STA) separate from or associated with a multi-link device (MLD), wherein the station is configured to wirelessly communicate over a channel with other wireless Stations (STAs) that conduct transmission of frames using carrier sense multiple access/collision avoidance (CSMA/CA) with their packets over a Wireless Local Area Network (WLAN) under the IEEE 802 protocol for a scheduled Service Period (SP) of a limited target wake-up time (R-TWT);

(b) A processor coupled to the STA for operation over a WLAN;

(c) A non-transitory memory storing instructions executable by the processor for communicating with other STAs in a communication protocol; and

(d) Wherein the instructions, when executed by the processor, perform one or more steps of declaring an R-TWT schedule to exchange frames with a member STA of the R-TWT, comprising:

(i) Wherein an Access Point (AP) operative to be configured to implement R-TWT scheduling, said station being an R-TWT scheduling AP declares R-TWT scheduling and exchanges frames with member STAs of the R-TWT after entering the R-TWT SP;

(ii) Wherein a termination condition is detected; and

(iii) Wherein after all frame exchanges have been completed during the R-TWT SP, the R-TWT scheduling AP signals in a termination declaration to indicate termination of the R-TWT SP.

2. The apparatus of claim 1, wherein the termination condition occurs when the STA operating as an R-TWT member STA sends a signal to the R-TWT scheduling AP after determining that it has no more frames to transmit to indicate that it has no more frames to transmit during an R-TWT SP.

3. The apparatus of claim 1, wherein the termination condition occurs before a scheduled end time of an R-TWT SP for terminating the R-TWT SP by the R-TWT scheduling AP.

4. The apparatus of claim 1, further comprising exchanging frames between the R-TWT scheduling AP and R-TWT member STAs during the R-TWT SP.

5. The apparatus of claim 4, further comprising exchanging frames between the R-TWT scheduling AP and STAs that have R-TWT characteristics but are not R-TWT member STAs after the R-TWT scheduling AP completes frame exchanges with R-TWT member STAs during R-TWT SP.

6. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform the steps of: when an R-TWT member STA does not have any Uplink (UL) or peer-to-peer (P2P) frames to transmit during an R-TWT SP, a signal is sent to the R-TWT scheduling AP.

7. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform the steps of: the R-TWT member STA transmits a frame indicating that it has no frame to transmit during the R-TWT SP.

8. The apparatus of claim 3, wherein the frame indicating that it has no frame to send during R-TWT SP comprises: (a) Frames that are neither quality of service (QoS) data frames nor QoS null frames; and (b) a frame containing a field indicating whether it has more data as a more data field in a state indicating that the R-TWT member STA does not have more frames to transmit during the R-TWT SP.

9. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform the steps of: the R-TWT member STA transmits QoS data or QoS null frames with an EOSP subfield set to a state indicating that the R-TWT member STA has no UL and/or P2P frames to transmit during the R-TWT SP.

10. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform the steps of: the R-TWT scheduling AP transmits a QoS data frame or QoS null frame with the EOSP subfield set to a state indicating termination of the R-TWT SP.

11. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform the steps of: the R-TWT schedules the AP to transmit frames that are neither QoS data frames nor QoS null frames, the frames have a field as a more data field to indicate whether there is more data to transmit, and the more data field is set to a value indicating termination of the R-TWT SP.

12. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform the steps of: the R-TWT schedules the AP to send a Contention Free (CF) end frame to indicate termination of the R-TWT SP.

13. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform the steps of: the R-TWT scheduling AP transmits a trigger frame that is not addressed to any particular R-TWT member STA, the trigger frame having a field indicating whether there are more trigger frames, and the field is set to indicate termination of the R-TWT SP.

14. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform the steps of: the R-TWT scheduling AP transmits TWT information frames with TWT flow identification field set equal to the R-TWT identification to indicate termination of the R-TWT SP.

15. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform the steps of: in response to receiving a frame from the R-TWT scheduling AP containing an indication that the R-TWT SP has terminated, the member STA identifies that the R-TWT SP has terminated.

16. The apparatus of claim 1, wherein the instructions, when executed by the processor, further perform the steps of: in response to receiving an acknowledgement from the R-TWT scheduling AP indicating that the R-TWT SP has terminated, the member STA identifies that the R-TWT SP has terminated.

17. An apparatus for wireless communication in a network, the apparatus comprising:

(a) Wireless communication circuitry as a Station (STA) separate from or associated with a multi-link device (MLD), wherein the station is configured to wirelessly communicate over a channel with other wireless Stations (STAs) that conduct transmission of frames using carrier sense multiple access/collision avoidance (CSMA/CA) with their packets over a Wireless Local Area Network (WLAN) under the IEEE 802 protocol for a scheduled Service Period (SP) of a limited target wake-up time (R-TWT);

(b) A processor coupled to the STA for operation over a WLAN;

(c) A non-transitory memory storing instructions executable by the processor for communicating with other STAs; and

(d) Wherein the instructions, when executed by the processor, perform one or more steps of declaring an R-TWT schedule to exchange frames with a member STA of the R-TWT, comprising:

(i) Wherein the station operating as an Access Point (AP) configured for implementing R-TWT scheduling is configured to schedule the AP as R-TWT; and wherein the R-TWT schedules the AP and R-TWT member STA to enter the R-TWT SP;

(ii) Terminating, by the R-TWT scheduling AP, the R-TWT SP before a scheduled end time of the R-TWT SP and sending a termination declaration over the channel; and

(iii) Wherein other STAs on the network that are not member STAs of the R-TWT are able to contend for the channel immediately in response to receiving the termination declaration.

18. The apparatus of claim 17, wherein the instructions, when executed by a processor, further perform the steps of: the R-TWT scheduling AP signals over the channel to indicate termination of the R-TWT SP.

19. The apparatus of claim 17, wherein the instructions, when executed by a processor, further perform the steps of: the R-TWT member STA is not allowed to contend for the channel after the R-TWT SP terminates until the scheduled end time of the R-TWT SP arrives.

20. The apparatus of claim 17, wherein the instructions, when executed by a processor, further perform the steps of: the R-TWT member STAs are allowed to contend for the channel at a lower priority than the conventional EDCA parameters set for those R-TWT member STAs until the scheduled end time of the R-TWT SP after the termination of the R-TWT SP.

21. An apparatus for wireless communication in a network, the apparatus comprising:

(a) Wireless communication circuitry as a Station (STA) separate from or associated with a multi-link device (MLD), wherein the station is configured to wirelessly communicate over a channel with other wireless Stations (STAs) that conduct transmission of frames using carrier sense multiple access/collision avoidance (CSMA/CA) with their packets over a Wireless Local Area Network (WLAN) under the IEEE 802 protocol for a scheduled Service Period (SP) of a limited target wake-up time (R-TWT);

(b) A processor coupled to the STA for operation over a WLAN;

(c) A non-transitory memory storing instructions executable by the processor for communicating with other STAs; and

(d) Wherein the instructions, when executed by the processor, perform one or more steps of declaring an R-TWT schedule to exchange frames with a member STA of the R-TWT, comprising:

(i) Wherein the station operating as an Access Point (AP) configured for implementing R-TWT scheduling is an R-TWT scheduling AP, and the R-TWT member STA enters an R-TWT SP;

(ii) Exchanging frames between the R-TWT scheduling AP and R-TWT member STAs during the R-TWT SP; and

(iii) After the R-TWT scheduling AP completes frame exchanges with the R-TWT member STAs during the R-TWT SP, frames are exchanged between the R-TWT scheduling AP and STAs that have R-TWT characteristics but are not R-TWT member STAs.

22. The apparatus of claim 21, wherein the instructions, when executed by a processor, further perform the steps of: the R-TWT scheduling AP extends a transmission opportunity (TXOP) for frame exchanges with R-TWT member STAs beyond the scheduled end time of the R-TWT SP.