Stream classification service (SCS) with restricted target latency (R-TWT) setup

Abstract

This is an IEEE 802.11 protocol in which the necessity and problems surrounding setting up the SCS separately and reserving the target wait time (R-TWT) are eliminated. In this disclosure, new data structures and processes are performed in which a station (STA) can request the scheduling of R-TWTs for the transmission of traffic of the stream classification service (SCS) during the setup procedure of its SCS. In utilizing the teachings of this disclosure, the STA can schedule R-TWTs on multiple links by exchanging TWT setup frames on a single link.

Description

Technology Field

[0001] Cross-reference regarding related applications

[0002] This application claims priority and the benefit thereof for U.S. Patent Application No. 17 / 814,166, filed July 21, 2022, the entirety of which is incorporated herein by reference. This application claims priority and the benefit thereof for U.S. Provisional Patent Application No. 63 / 267,397, filed February 1, 2022, the entirety of which is incorporated herein by reference. This application claims priority and the benefit thereof for U.S. Provisional Patent Application No. 63 / 263,862, filed November 10, 2021, the entirety of which is incorporated herein by reference. This application claims priority and the benefit thereof for U.S. Provisional Patent Application No. 63 / 260,173, filed August 11, 2021, the entirety of which is incorporated herein by reference.

[0003] Statements regarding federally sponsored research or development

[0004] Not applicable

[0005] Notice regarding copyrighted materials

[0006] Parts of the material of this patent document may be protected by copyright under the copyright laws of the United States and other countries. The copyright owner has no objection to anyone copying this patent document or the patent disclosure as they appear in publicly available files or records of the United States Patent and Trademark Office, but otherwise retains all copyrights. The copyright owner does not waive any right to keep this patent document secret, including but not limited to rights under 37 CFR §1.14.

[0007] Technology field

[0008] The technology of the present disclosure generally relates to wireless local area networks operating under 802.11, and more specifically to a CSMA / CA protocol that allows a Restricted Target Wait Time (R-TWT) scheduling request for traffic transmission of the Stream Classification Service (SCS) during SCS setup. Background Technology

[0009] Current wireless technologies, such as IEEE 802.11be utilizing CSMA / CA, focus on high network throughput performance but do not provide high levels of low-latency performance. However, many applications, such as real-time applications (RTA), require low-latency capabilities, and thus a technology gap exists.

[0010] Real-time applications (RTAs) require low-latency communication and rely on best-effort communication. Data generated from RTAs is called RTA traffic and will be packetized as RTA packets at the transmitter STA. Additionally, data generated from non-time-sensitive applications is called non-RTA traffic and will be packetized as non-RTA packets at the transmitter STA.

[0011] RTA packets require low latency due to their high timeliness requirements for packet delivery. RTA packets are valid when delivered within a specific time period.

[0012] Accordingly, there is a need for enhanced CSMA / CA WLAN protocols capable of providing low latency for RTA packets and high throughput for non-RTA packet traffic. The present disclosure satisfies this need and provides additional advantages.

[0013] The protocol of the present disclosure for a CSMA / CA WLAN enables a station (STA) to request the scheduling of a limited target wait time (R-TWT) for the transmission of traffic of a stream classification service (SCS) during the setup procedure of its SCS. Accordingly, the STA can schedule R-TWTs on multiple links by exchanging TWT setup frames on one link.

[0014] Additional aspects of the technology described herein will be derived from the following parts of this specification, and the detailed description provided herein is intended to fully disclose preferred embodiments of the technology without limitation. Brief explanation of the drawing

[0015] The technology described in this specification will be more fully understood by referring to the following drawings, which are for exemplary purposes only. Figure 1 is a data field diagram of a conventional TSPEC element defined in IEEE 802.11. Figure 2 is a data field diagram of the TS information field of the TSPEC element of Figure 1. Figure 3 is a diagram of the data fields of a TCLAS element defined in IEEE 802.11. Figure 4 is a diagram of the data fields of a TCLAS process element defined in IEEE 802.11. Figure 5 is a diagram of the data fields of a TWT element defined in IEEE 802.11. Figure 6 is a data field diagram of the control field of the TWT element of Figure 5. Figure 7 is a diagram of the data field of the broadcast TWT parameter information field of Figure 5. Figure 8 is a diagram of the data field of the request type field within the broadcast TWT parameter information field shown in Figure 7. Figure 9 is a diagram of the data field of the broadcast TWT information field within the broadcast TWT parameter information field shown in Figure 7. Figure 10 is a communication diagram between levels of the SCS setup procedure defined in IEEE 802.11be. Figure 11 is a diagram of the data fields of an SCS request frame. Figure 12 is a diagram of the data fields of the SCS descriptor element format. Figure 13 is a diagram of the data fields of an SCS response frame. Figure 14 is a diagram of the data field of the SCS status field. Figure 15 is a communication diagram between levels of TWT setup signaling. FIG. 16 is a data field drawing of a TWT setup frame carrying TWT elements as illustrated in FIG. 5. FIG. 17 is a hardware block diagram of radio station (STA) hardware according to at least one embodiment of the present disclosure. FIG. 18 is a hardware block diagram of a station configuration included, for example, in multi-link device (MLD) hardware according to at least one embodiment of the present disclosure. FIG. 19 is a station topology for consideration according to at least one embodiment of the present disclosure. FIGS. 20 and 21 are flowcharts of a non-AP transmitting an SCS request frame containing R-TWT membership request information according to at least one embodiment of the present disclosure. FIG. 22 is a flowchart of an AP responding to an SCS response frame including an R-TWT membership response according to at least one embodiment of the present disclosure. FIG. 23 is a data field diagram of a modified SCS descriptor element including an R-TWT setup request according to at least one embodiment of the present disclosure. FIG. 24 is a data field diagram of an RTA-TSPEC element according to at least one embodiment of the present disclosure. FIG. 25 is a data field diagram of a modified TS information field format in an RTA-TSPEC element according to at least one embodiment of the present disclosure. FIG. 26 is a data field diagram of an exemplary RTA-TSPEC element format when setting a basic use case according to at least one embodiment of the present disclosure. FIG. 27 is a data field diagram of a modified SCS state according to at least one embodiment of the present disclosure. FIG. 28 is a data field diagram of a modified TWT element according to at least one embodiment of the present disclosure. FIG. 29 is a communication diagram of an SCS setup with an R-TWT according to at least one embodiment of the present disclosure. FIG. 30 is a communication diagram in which an R-TWT for an SCS traffic stream is not scheduled during the SCS setup procedure according to at least one embodiment of the present disclosure. FIG. 31 is a communication diagram for scheduling a plurality of R-TWTs for a single SCS traffic stream according to at least one embodiment of the present disclosure. FIG. 32 is a communication diagram of an SCS setup with R-TWTs for other links according to at least one embodiment of the present disclosure. FIG. 33 is a communication diagram of an R-TWT setup using a modified TWT element according to at least one embodiment of the present disclosure. FIG. 34 is a communication diagram of a broadcast TWT setup using a modified TWT element according to at least one embodiment of the present disclosure. FIG. 35 is a communication diagram of a wake TBTT negotiation using a modified TWT element according to at least one embodiment of the present disclosure. FIG. 36 is a communication diagram of individual negotiations using modified TWT elements according to at least one embodiment of the present disclosure. FIGS. 37 and 38 are flowcharts of a non-AP MLD initiating an SCS setup procedure requesting R-TWT scheduling for an SCS according to at least one embodiment of the present disclosure. FIG. 39 is a flowchart of an AP MLD that transmits an SCS response frame and assigns membership to an SCS according to at least one embodiment of the present disclosure. FIG. 40 is a data field diagram of an SCS descriptor element having an R-TWT request field within a QoS characteristic element according to at least one embodiment of the present disclosure. FIG. 41 is a data field diagram of a modified broadcast TWT parameter set field having an SCSID subfield according to at least one embodiment of the present disclosure. FIG. 42 is a communication diagram of AP1 scheduling R-TWT SPs for an SCSx traffic stream on Link 1 according to at least one embodiment of the present disclosure. FIG. 43 is a communication diagram of AP1 scheduling R-TWT SPs for SCSx traffic streams on different links according to at least one embodiment of the present disclosure. FIG. 44 is a communication diagram of MLD1 scheduling R-TWT SPs for SCSx traffic streams on a plurality of links according to at least one embodiment of the present disclosure. FIG. 45 is a communication diagram of MLD3 that does not receive R-TWT membership for SCSx before a timeout, according to at least one embodiment of the present disclosure. Specific details for implementing the invention

[0016] 1. Introduction of IEEE 802.11 Data Elements

[0017] 1.1. Traffic Specification (TSPEC) Elements

[0018] FIG. 1 illustrates the contents of a TSPEC element defined in IEEE 802.11, having the following fields. The element ID field indicates the type of element, such as the TSPEC element in this case. The length field indicates the length of the TSPEC element. The TS info field provides traffic stream information as discussed in FIG. 2 below.

[0019] The Nominal MSDU Size field indicates the nominal size of the MSDUs or A-MSDUs belonging to the TS under this TSPEC. The Max MSDU Size field indicates the maximum size of the MSDUs or A-MSDUs belonging to the TS under this TSPEC. The Minimum Service Interval field indicates the minimum time between the start times of two consecutive Service Periods (SPs). The Max Service Interval field indicates the maximum time between the start times of two consecutive SPs. The Inactivity Interval field indicates the maximum time interval before the transmission of MSDUs belonging to the TS arrives before the TS is deleted. The Pause Interval field indicates the maximum interval of time without arrivals or transmissions of MSDUs belonging to the TS before the generation of consecutive QoS(+)CF-Polls for this TS is stopped.

[0020] 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 MSDUs or A-MSDUs 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 belonging to the TS under this TSPEC at the peak data rate. The Delay Limit field is the maximum time allowed to transmit MSDUs or A-MSDUs belonging to the TS under this TSPEC.

[0021] The Minimum PHY Rate field indicates the minimum PHY rate for transmitting MSDUs or A-MSDUs belonging to the TS under this TSPEC. The Allowed Redundancy Bandwidth field indicates the bandwidth used to transmit MSDUs or A-MSDUs belonging to the TS under this TSPEC and the ratio of retransmissions to the bandwidth used to transmit those MSDUs or A-MSDUs once at the minimum PHY rate. The Medium Time field (Time per Second) indicates the time allowed to access the medium. The DMG Attribute field is presented when the TSPEC is applied to a Directional Multi-Gigabit (DMG) BSS.

[0022] Figure 2 illustrates the contents within the TS Information field of the TSPEC element of Figure 1 as defined in IEEE 802.11. This element has the following subfields. The Traffic Type subfield specifies whether the traffic is periodic. TSID represents an ID number for identifying the TS. The Direction subfield specifies the direction of data transmission. The Access Policy subfield specifies the method for obtaining channel access. The Aggregation subfield specifies whether an aggregation schedule is required. The APSD subfield indicates whether automatic PS delivery is utilized. The User Priority subfield indicates the user priority of MSDUs or A-MSDUs belonging to the TS. The TSInfo Ack Policy subfield indicates whether an Acknowledgement (ACK) is required and what type of ACK should be used. The Schedule subfield indicates the type of schedule.

[0023] 1.2. Traffic Classification (TCLAS) Elements

[0024] FIG. 3 illustrates the contents of a TCLAS element defined in IEEE 802.11 and having the following fields. The element ID field indicates the type of element, in this case, as a TCLAS element. The length field indicates the length of the TCLAS element. The user priority field indicates the user priority from the upper layer. The frame classifier field indicates the method for classifying frames from the upper layer.

[0025] 1.3. Traffic Classification (TCLAS) Processing Elements

[0026] Figure 4 shows the contents within a TCLAS processing element defined in IEEE 802.11 and having the following fields. The element ID field indicates the type of element, which is a TCLAS processing element in this case. The length field indicates the length of the TCLAS processing element. The processing field indicates the method for classifying traffic from the upper layer when multiple TCLAS elements exist.

[0027] 1.4. TWT Elements

[0028] FIG. 5 illustrates the format of a TWT element defined in IEEE 802.11ax and having the following fields. The element ID and length serve the same purpose as previously described. The control field provides control information. When the negotiation type field within the control field in the TWT element is set to a value of "2" or "3", the TWT parameter information field within the TWT element carries the broadcast TWT parameter information field as shown in FIG. 7.

[0029] It should be noted that IEEE 802.11be (draft P802.11be_D1.01) has updates related to this element. When the Broadcast TWT Recommendation field within the Request Type field in the Broadcast TWT Parameter Information field is set to a value of "4", this indicates that the Broadcast TWT (B-TWT) displayed in the Broadcast TWT Parameter Information field is a Restricted TWT (R-TWT).

[0030] FIG. 6 illustrates a control field of a TWT element having subfields of an NDP paging indicator, responder PM mode, negotiation type, TWT information frame disable, wake duration unit, and reserve field.

[0031] FIG. 7 illustrates the broadcast TWT parameter information field (the TWT parameter information field in the TWT element when the negotiation type is 2 or 3). The subfields include the request type, target wake time, nominal minimum TWT wake duration, TWT wake interval mantissa, and broadcast TWT information.

[0032] FIG. 8 illustrates the request type field within the broadcast TWT parameter information field illustrated in FIG. 7. The subfields include TWT request, TWT setup command, trigger, last broadcast parameter set, flow type, broadcast TWT recommendation, TWT wake interval index, and reserve subfields.

[0033] FIG. 9 illustrates the broadcast TWT information subfields within the broadcast TWT parameter information field illustrated in FIG. 7. The subfields include the broadcast TWT ID subfield and the broadcast TWT persistence subfield, as well as the reserve subfield.

[0034] 1.5. Stream Classification Service (SCS) Signaling

[0035] Figure 10 illustrates an example of a stream classification service (SCS) setup defined in IEEE 802.11be (draft P802.11be_D1.01). The interoperability model of the STAs may be the same as that defined in the IEEE 802.11 standard.

[0036] The non-AP STA decides to initiate the SCS setup procedure for the AP. The Station Management Entity (SME) of the non-AP STA sends an MLME-SCS.request message to its MAC Lower Layer Management Entity (MLME). When the MLME of the non-AP STA receives the MLME-SCS.request message, it collects the information within 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 the SME that processes the request.

[0037] Next, the AP's SME sends an MLME-SCS.response message containing the SCS setup result to that MLME. Then, the AP's MLME sends the SCS response frame to the non-AP STA. The non-AP STA's MLME receives the frame and sends an MLME-SCS.confirm message to its SME. Then, at this point, the non-AP can determine whether the SCS setup was successful.

[0038] FIGS. 11 to 14 illustrate SCS request frames and related data.

[0039] FIG. 11 illustrates an SCS request frame having fields of frame control, address field (1-3), sequence control, action, and frame check sequence (FCS). The action field is illustrated as including the following subfields: category, robust action, conversation token, and SCS descriptor list, each of which includes the fields illustrated in FIG. 12. It should be understood that the SCS descriptor list field can carry multiple SCS descriptor elements.

[0040] In FIG. 12, each descriptor element is shown to have fields for element ID, length, SCSID, request type, access category priority, TCLAS, TCLAS processing (optional), TSPEC, and optional sub-elements.

[0041] FIG. 13 illustrates an SCS response frame having subfields of frame control duration, address (1-3), sequence control, action, and FCS. The action subfield is illustrated as having subfields of category, robust action, conversation token, and SCS state list. The SCS state list subfield may carry multiple SCS state subfields as illustrated in FIG. 14.

[0042] Figure 14 illustrates an SCS status field including an SCSID and a status subfield. This status indicates the SCS setup result of the SCS displayed in the SCSID field (e.g., acceptance, rejection, rejection for a reason, termination, etc.).

[0043] 1.6. TWT Signaling

[0044] Figure 15 illustrates an example of TWT setup signaling defined in IEEE 802.11ax. The interoperability model of the STAs may be the same as that defined in the IEEE 802.11 standard.

[0045] The non-AP STA decides to initiate the TWT setup procedure with the AP. The non-AP STA's Station Management Entity (SME) sends the MLME-TWTSETUP.request message to its MAC sub-layer management entity (MLME). When the non-AP STA's MLME receives the MLME-TWTSETUP.request message, it collects the information within the MLME-TWTSETUP.request message and sends a TWT setup frame (i.e., a TWT request frame) to the AP. The AP's MLME receives the frame and generates an MLME-TWTSETUP.indication message for the SME that handles the request.

[0046] Next, the AP's SME sends an MLME-TWTSETUP.response message containing the TWT setup result to that MLME. Then, the AP's MLME sends a TWT setup frame (i.e., a TWT response frame) to the non-AP STA. The non-AP STA's MLME receives the frame and sends an MLME-TWTSETUP.confirm message to its SME. After that, the non-AP STA can recognize (determine) whether the TWT setup was successful.

[0047] FIG. 16 illustrates a TWT setup frame carrying TWT elements within the frame illustrated in FIG. 5. The subfields of the TWT setup are frame control, duration, address (1-3), sequence control, data, and FCS. Then, the data field is illustrated with subfields of category, action, conversation token, and TWT element.

[0048] 2. Statement of the Problem and Contribution of the Present Disclosure

[0049] Current IEEE 802.11 protocols support SCS setup and R-TWT setup separately. However, this can cause problems, such as when the SCS is successfully set up but the R-TWT cannot be scheduled for the traffic transmission of that SCS, and consequently, the QoS requirements of the SCS may not be satisfied.

[0050] Trade-offs are often required between high throughput performance and low latency performance because they may not be achieved simultaneously across all traffic. To satisfy the different requirements of Real-Time Application (RTA) packet traffic and non-RTA packet traffic, networks can utilize certain features to improve low latency performance when transmitting RTA packets, while utilizing other features to maximize throughput when transmitting non-RTA packets.

[0051] Therefore, to this end, RTA traffic and non-RTA traffic must be identified by the transmitter STA, while sometimes the receiver STA also benefits from the distinction between RTA packets and non-RTA packets. Then, the network may choose to use different features to individually satisfy the requirements of RTA and non-RTA traffic.

[0052] Often, RTA traffic is generated periodically in the form of connection-oriented communication. RTA connection-oriented communication established by applications between STAs is called an RTA session. In some cases, an STA may have multiple RTA sessions within the network that the STA must be able to manage.

[0053] To manage these RTA sessions in WLAN networks, the present disclosure is configured to treat an RTA session as a Stream Classification Service (SCS) traffic stream in IEEE 802.11. Subsequently, the RTA traffic of the SCS traffic stream can be separated from other traffic. Meanwhile, a limited target wait time (R-TWT) can be used to schedule and reserve channel resources for the transmission of RTA traffic. The present disclosure includes an R-TWT setup within an SCS setup procedure. Once the SCS traffic stream is established for the RTA session, channel resources are also reserved to ensure QoS quality, such as latency, jitter, and packet loss, of the RTA traffic stream through the R-TWT.

[0054] The present disclosure provides a protocol that allows an STA to request R-TWT scheduling for traffic transmission of an SCS during the setup procedure of the SCS. By using this configuration, the STA can schedule R-TWTs on multiple links by exchanging TWT setup frames on one link.

[0055] 3. Examples of the present disclosure

[0056] 3.1. Station (STA and MLD) Hardware

[0057] FIG. 17 illustrates an exemplary embodiment (10) of STA hardware configured to execute the protocol of the present disclosure. An external I / O connection (14) is preferably coupled to an internal bus (16) of a circuit (12) to which a CPU (18) and memory (e.g., RAM) (20) are connected to execute program(s) that implement the communication protocol. The host machine accommodates at least one modem (22) for supporting communication coupled to at least one RF module (24, 28) each connected to one or more antennas (29, 26a, 26b, 26c to 26n). An RF module having multiple antennas (e.g., an antenna array) allows beamforming to be performed during transmission and reception. In this way, the STA can transmit signals using multiple sets of beam patterns.

[0058] The bus (14) allows various devices to be connected to the CPU, such as sensors, actuators, etc. Instructions from memory (20) are executed on the processor (18) to execute a program that implements a communication protocol, which is executed to allow the STA to perform the functions of an access point (AP) station or a regular station (non-AP STA). It should also be understood that the programming is configured to operate in different modes (TXOP holder, TXOP shared participant, source, intermediate, destination, first AP, other AP, stations associated with the first AP, stations associated with other AP, coordinator, coordinator, AP in OBSS, STA in OBSS, etc.) depending on what role it plays in the current communication context.

[0059] Accordingly, the STA HW is depicted as comprising at least one modem and an associated RF circuit for providing communication over at least one band. The present disclosure is primarily related to bands below 6 GHz.

[0060] It should be noted that the present disclosure may consist of a plurality of modems (22), and each modem is coupled to any number of RF circuits. Generally, using a larger number of RF circuits will result in wider coverage of the antenna beam direction. It should be noted that the number of RF circuits and antennas used is determined by the hardware constraints of the specific device. Some of the RF circuits and antennas may be disabled when the STA determines that it is unnecessary to communicate with neighboring STAs. In at least one embodiment, the RF circuits include a frequency converter, an array antenna controller, etc., and are connected to a plurality of antennas controlled to perform beamforming for transmission and reception. In this way, the STA can transmit signals using a plurality of sets of beam patterns, and each beam pattern direction is considered as an antenna sector.

[0061] Additionally, it should be noted that multiple instances of station hardware as illustrated in the drawing may be combined into a multi-link device (MLD), which will typically have a processor and memory for coordinating activities, but there is not always a need for a separate CPU and memory for each STA within the MLD.

[0062] FIG. 18 illustrates a multi-link device (MLD) hardware configuration and illustrates an exemplary embodiment (40) of a multi-link device (MLD) hardware configuration. A soft AP MLD is an MLD composed of one or more associated STAs operating as APs. The soft AP MLD must support multiple radio operations at 2.4 GHz, 5 GHz, and 6 GHz. Among the multiple radios, the basic link sets are link pairs satisfying the simultaneous transmit and receive (STR) mode, e.g., basic link set (2.4 GHz and 5 GHz), basic link set (2.4 GHz and 6 GHz).

[0063] A conditional link is a link that forms an asynchronous transmit and receive (NSTR) link pair with some base link(s). For example, these link pairs may include a 6GHz link as a conditional link corresponding to the 5GHz link when 5GHz is the base link; and the 5GHz link is a conditional link corresponding to the 6GHz link when 6GHz is the base link. Soft APs are used in different scenarios, including Wi-Fi hotspots and tethering.

[0064] A number of STAs are associated with an MLD, and each STA operates on a link of a different frequency. The MLD has external I / O access to applications, and this access is connected to an MLD management entity (48) having a CPU (62) and memory (e.g., RAM) (64), enabling the execution of program(s) that implement communication protocols at the MLD level. The MLD can distribute tasks to each associated station to which it is connected and collect information therefrom, which is exemplified here as the sharing of information between STA 1 (42), STA 2 (44) through STA N (46) and the associated STAs.

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

[0066] It should be understood that, depending on the specific MLD implementation, STAs may share resources with each other and / or with the MLD management entity, so each STA of the MLD does not necessarily require its own processor and memory. While the MLD diagram above is given as an example rather than a limitation, it should be understood that the present disclosure may operate with a wide range of MLD implementations.

[0067] 3.2. Network Topology for Consideration

[0068] FIG. 19 illustrates an exemplary STA topology for consideration in the examples of the present disclosure. The figure is provided to aid in the discussion of related technologies and to enable an improved understanding of the proposed technology. It should be recognized that the present disclosure is by no means limited to the topology of this example, as the protocol can be used on communications between WLAN STAs and MLDs of any desired topology.

[0069] An MLD is a device that has more than one associated STA and one MAC service access point (SAP) to logical link control (LLC) that includes one MAC data service.

[0070] If APs are linked to that MLD, the MLD is an AP MLD. If non-AP STAs are linked to that MLD, the MLD is a non-AP MLD.

[0071] As illustrated in FIG. 19, the scenario is exemplified with a total of 7 stations, 6 of which are located within the MLDs (72, 74, and 76) in the conference room. AP1 (78) and AP2 (80) are associated with the multi-link device (72) (MLD #1), STA1 (82) and STA4 (88) are associated with MLD #2 (74), and STA3 (86) and STA5 (90) are associated with MLD #3 (76). STA2 (84) may include a non-AP STA operating on Link 1 (92), or a single-link MLD (i.e., a special MLD having only one STA and operating on one link). STA1, STA2, and STA3 are associated with AP1 via Link 1 (94, 98), and STA4 and STA5 are associated with AP2 via Link 2 (96 and 100). All STAs use EDCA for random channel access on all links.

[0072] 3.3. SCS Setup Procedure with R-TWT Membership Exchange

[0073] The SCS setup process is described in this section, including the R-TWT membership exchange for the traffic of the SCS. The purpose of including the R-TWT membership exchange in the SCS setup procedure is to schedule an R-TWT SP to transmit the traffic of the SCS, satisfy its QoS requirements such as throughput, latency, jitter, and packet loss, and then establish the SCS. If an R-TWT Service Term (SP) cannot be scheduled to transmit the traffic of the SCS, the SCS setup request may be rejected.

[0074] Note that the SCS setup procedure and the R-TWT setup procedure can be separated if desired, and R-TWT SPs are scheduled to satisfy the QoS requirements of the SCS traffic stream.

[0075] In the present disclosure, the following is performed when a non-AP STA and its associated AP initiate an SCS setup procedure. (a) An R-TWT membership request may be included in an SCS description element of an SCS, denoted as SCSx, within a TWT element of an SCS request frame transmitted by the non-AP STA. In this case, the R-TWT membership request indicates an R-TWT parameter request for the transmission of traffic of SCSx.

[0076] (b) An R-TWT membership response may be included in the SCS state element of SCSx within the TWT element of the corresponding SCS response frame transmitted by the AP. In this case, the R-TWT membership response indicates one of the following responses.

[0077] (b)(i) An R-TWT membership request is accepted, and a non-AP STA follows the accepted R-TWT scheduling to transmit traffic for SCSx. Traffic for SCSx will be scheduled to be transmitted during the accepted R-TWT SPs. For example, if it is a trigger-based R-TWT, the AP will schedule trigger-based transmission for that SCSx traffic stream. The non-AP STA becomes a member STA of the accepted R-TWT. SCSx is represented as a member SCS of the accepted R-TWTs. In at least one embodiment / mode / case, traffic that does not belong to the member SCS of the R-TWT is not allowed to be transmitted during the SPs of that R-TWT, or is transmitted during the SPs of that R-TWT with a lower priority than the traffic of the member SCSs of that R-TWT. In at least one embodiment / mode / case, if there are frames that have the same TID as a member SCS of the R-TWT and need to be retransmitted but do not belong to any member SCS of the R-TWT, the AP may transmit these frames during the SP of that R-TWT. The AP must transmit these frames earlier than the frames of the member SCSs of the R-TWT having the same TID during the SP of that R-TWT when a block acknowledgment is used for that TID. This is because the sequence numbers of these frames have been assigned and are smaller than those of the frames of the member SCSs of the R-TWT having the same TID.

[0078] (b)(ii) An R-TWT membership request is not accepted, but proposed R-TWT parameters are given by the AP. A non-AP STA may re-request membership based on the proposed R-TWT parameters. In certain cases, the proposed R-TWT parameters may not be related to the R-TWTs to which the non-AP STA is a member, or the proposed R-TWT parameters related to the R-TWT to which the non-AP STA is a member do not affect the membership of that R-TWT in the non-AP STA.

[0079] (b)(iii) If an R-TWT membership request is denied, the non-AP must not re-request membership in that R-TWT.

[0080] In this section, the proposed techniques consider R-TWT scheduling for the SCS during the SCS setup procedure. It is also permissible for other types of TWTs, such as individual TWTs and broadcast TWTs, to be set up during the SCS setup procedure. Since setup signaling information for all types of TWTs is carried by the TWT elements, the setup signaling exchange for other types of TWTs may be identical to the R-TWT membership exchange in the SCS setup procedure. The TWT setup procedure for other types of TWTs during the SCS procedure may be identical to that described in Section 1.6.

[0081] It should be noted that the SCS setup procedure may be the same as that illustrated in FIG. 10, except that the formats of the SCS request frame and SCS response frame are modified to include TWT membership request / response. Changes to the frames will be described later.

[0082] 3.3.1. Non-AP transported SCS request frame containing R-TWT membership request information

[0083] This section describes the setup procedure for an SCS including an R-TWT setup request from the non-AP STA side. This section details the following operations.

[0084] (a) The process for a non-AP STA to transmit an SCS setup request carrying an R-TWT setup request for the SCS is as follows. In at least one embodiment, the SCS request containing the R-TWT setup request may be carried in a modified SCS descriptor element as illustrated in FIG. 23. The non-AP STA may transmit an SCS request frame as illustrated in FIG. 12, thereby allowing the SCS descriptor list field to carry one or more modified SCS descriptor elements to the AP. Each modified SCS descriptor element represents an SCS setup request for a single SCS indicated in the SCS ID field.

[0085] (b) The process by which an AP responds to an SCS setup carrying an R-TWT setup request for the SCS is as follows. In at least one embodiment, the response to the SCS setup, including R-TWT scheduling for the SCS, may be carried in a modified SCS state element as illustrated in FIG. 27. The AP transmits an SCS response frame as illustrated in FIG. 25, thereby allowing the SCS state list to carry one or more modified SCS state elements as illustrated in FIG. 27. It should be noted that each modified SCS state element represents a setup response for one SCS indicated in the SCS ID field.

[0086] FIGS. 20 and 21 illustrate an exemplary embodiment (110) of a non-AP that transmits an SCS request frame containing an R-TWT setup request to its associated AP in order to request an SCS setup containing R-TWT membership request information.

[0087] The non-AP sends an SCS request frame (112) to the AP to establish an SCS designated as SCSx. The non-AP STA may indicate its R-TWT setup request for the transmission of traffic of SCSx during SCSx. For example, within the SCS descriptor element of SCSx within the SCS request frame, the non-AP STA may set the R-TWT request field to "required" or "optional" in the TS information field format within the RTA-TSPEC element (or the control information field within the QoS attribute element defined in IEEE 802.11be) to indicate that the non-AP STA requests R-TWT scheduling for the transmission of traffic of SCSx.

[0088] Subsequently, a TWT element may be included in the SCS descriptor element of the SCSx to indicate the R-TWT scheduling requirements for the SCSx. The Negotiation Type field within the control field of the TWT element must be set to "3" to indicate that the TWT element is for a membership exchange. Assume that a non-AP is requesting membership in the R-TWTx for the transmission of traffic in the SCSx. Subsequently, the TWT element includes the Broadcast TWT Parameter Set field of the R-TWTx. The TWT Request field and the Broadcast TWT Recommend field within the Request Type field of the Broadcast TWT Parameter Set field of the R-TWTx must be set to "1" and "4", respectively, to indicate that the TWT element is for an R-TWT membership request. The Broadcast TWT Recommend field within the Request Type field of the Broadcast TWT Parameter Set field of the R-TWTx may be set to the value "4" or other values ​​indicating that the R-TWTx is an R-TWT. Note that non-APs may have multiple broadcast TWT parameter set fields in one or more TWT elements within a single SCS descriptor element to request membership of different R-TWTs.

[0089] In at least one embodiment / mode / case, a non-AP STA may set the R-TWT request field in the TS information field format within the RTA-TSPEC element to "required" or "optional" without adding a TWT element to the SCS descriptor element of the SCSx. Then, according to at least one embodiment, if the AP accepts the SCS setup request, it may transmit an unrequested R-TWT scheduling for the SCSx.

[0090] A non-AP can set the R-TWT request field to "not required," and the SCS request frame is for SCS setup only, as defined in IEEE 802.11. No TWT elements are carried by the SCS descriptor elements within the SCS request frame. This provides backward compatibility with existing protocols. Next, the non-AP STA receives an SCS response frame containing the setup results of the SCSx.

[0091] In block (114), if it is determined that the AP rejected the SCS setup request, the associated R-TWT setup request as well as the SCS setup failed in 124 of FIG. 21.

[0092] Execution moves to block (126), where the AP may include the proposed parameter settings. The non-AP may retransmit another SCS request frame using the proposed parameter settings to request the SCS setup again. In at least one embodiment / mode / case, when the SCSx setup is rejected, the AP does not include a TWT element in the corresponding SCS state element within the SCS response frame.

[0093] In block (114) of FIG. 20, the non-AP receives an SCS response frame from the AP in which the AP accepts the SCSx setup. Then, the SCSx setup is successful, and in block (116), the non-AP can distinguish the traffic of the SCS from other traffic. When the SCSx is successfully established, the non-AP STA checks in 118 of FIG. 21 whether the R-TWT setup request for the SCS is accepted by the AP.

[0094] If an R-TWT setup request is accepted in block (118), the non-AP STA in block (122) becomes a member of the R-TWT(s) indicated in the TWT element within the state element of SCSx in the SCS response frame. The traffic of the SCS becomes the member SCS of these R-TWT(s).

[0095] If the R-TWT setup request is not accepted in block (118), the membership of the non-AP STA of the R-TWTs notified by the AP in block (120) is not changed.

[0096] If an SCS is requested to modify an existing SCS, TWT elements cannot be added to the SCS descriptor elements of that SCS.

[0097] If an SCS setup request is accepted but an R-TWT setup request for that SCS is rejected, a non-AP STA can request membership in the R-TWT by sending a TWT setup frame.

[0098] FIG. 22 shows an exemplary embodiment (130) in which an AP responds to an SCS response frame containing an R-TWT setup response to the SCS.

[0099] When the AP receives an SCS request frame containing an R-TWT setup request from a non-AP STA to establish an SCS marked as SCSx (132), and schedules R-TWT SPs to transmit traffic belonging to the SCSx, the AP sends an SCS response frame containing an R-TWT setup response to the non-AP STA (134).

[0100] In block (136), it is determined whether the AP accepts the SCS request and the R-TWT setup request. The SCSx setup performed by the AP may be indicated in the SCS state element of the SCSx within the SCS response frame. Within the SCS state element of the SCSx, a response to the R-TWT setup for the SCSx may also be included. It should be understood that in at least one embodiment / mode / case, the AP does not include any TWT elements in the SCS state element of the SCSx to indicate the rejection of the R-TWT setup.

[0101] If the SCS and R-TWT are accepted, the non-AP STA in block (138) becomes a member of the R-TWT, and traffic belonging to the SCS is scheduled to be transmitted during the R-TWT SP. Otherwise, if the request is not accepted in block (136), traffic belonging to the SCS in block (140) is not allowed or is given a lower priority than that transmitted during the R-TWT SPs.

[0102] More specifically, in at least one embodiment, the AP has the following options to respond to non-AP.

[0103] (a) The AP accepts the SCSx setup and the R-TWT setup request for the SCSx. In this case, the SCSx is successfully established, and the traffic of the SCSx can be separated from other traffic. The AP also allocates R-TWT(s) to transmit the traffic of the SCSx. The AP adds a TWT element to the modified SCS state field of the SCSx to indicate the R-TWT scheduling for the transmission of the SCSx's traffic. More specifically, when the R-TWT SP is trigger-based, the AP will schedule the transmission of traffic belonging to the SCS during the SPs of that R-TWT.

[0104] (b) The AP accepts the SCSx setup request but rejects the R-TWT setup request for the SCSx. Note that this occurs only when the AP receives an SCS request frame in which the R-TWT request field in the TS information field format within the RTA-TSPEC element in the SCS descriptor element of the SCSx is set to "optional". In this case, the SCSx is successfully established, but no R-TWT is scheduled for the transmission of traffic for the SCSx. To reject an R-TWT setup request for an SCSx, the AP may (1) not include a TWT element in the SCS state element for the SCSx, (2) add a TWT element having a TWT setup command field indicating "TWT rejected" to the SCS state element for the SCSx to indicate rejection of the R-TWT setup request for the SCS, or (3) add a TWT element having a TWT setup command field indicating "TWT replacement" or "TWT instruction" to the SCS state element for the SCS to indicate proposed parameters for the R-TWT setup for the SCS when rejecting the R-TWT setup request.

[0105] (c) Otherwise, the AP rejects the SCSx setup request and rejects the R-TWT setup request for the SCSx. In this case, the SCSx setup failed and no R-TWT is scheduled for the traffic transmission of the SCSx. To reject the R-TWT setup request for the SCSx, the AP may: (1) not include a TWT element in the SCS state element for the SCSx; (2) add a TWT element with a TWT setup command field indicating "TWT rejected" to the SCS state element for the SCSx to indicate the rejection of the R-TWT setup request for the SCS; or (3) add a TWT element with a TWT setup command field indicating "TWT substitute" or "TWT instruction" to the SCS state element for the SCS to indicate the proposed parameters for the R-TWT setup for the SCS when rejecting the R-TWT setup request.

[0106] 3.3.2. Communication Frame Formats

[0107] FIG. 23 shows an exemplary embodiment (150) of a modified SCS descriptor element of an SCS indicated in the SCS ID field. The modified SCS descriptor element can carry an R-TWT setup request for traffic transmission of the SCS indicated in the SCS. Modifications of this modified SCS descriptor element compared to the SCS descriptor element shown in FIG. 13 are described below. Without any description below, for these fields, they may be identical to or alternative to those of FIG. 13.

[0108] The Request Type field is set to indicate the request type of the SCS descriptor element. If a non-AP STA sets the Request Type field to "Add," the non-AP STA requests the addition of a new SCS. Subsequently, the AP responds whether the request has been accepted. The AP must also accept an R-TWT setup request for the new SCS if it accepts an SCS request where the R-TWT Request field within the TS Information field of the RTA-TSPEC element is set to "Required." If the R-TWT Request field within the TS Information field of the RTA-TSPEC element is set to "Optional," the AP may reject the R-TWT membership request. It should be noted that RTA-TSPEC can be replaced by the QoS Attribute element defined in IEEE 802.11be.

[0109] If a non-AP STA sets the request type field to "Change," the non-AP STA is requesting a change to the type of the existing SCS. When the AP receives this field, the tuple<SCSID, 비-AP STA MAC 어드레스> SCS can be discovered using [this method]. Then, the AP accepts or rejects changes to the parameters of that SCS. If the AP rejects a request to change a previously accepted SCS, the previously accepted classification and R-TWT scheduling (if any) are used for this SCS and continue to operate.

[0110] If a non-AP STA sets the request type to "Remove," the non-AP STA requests the removal of the existing SCS. When the AP receives this field, the tuple <SCSID, 비-AP MLD MAC 어드레스(비-AP가 STA이면, 이것은 비-AP STA MAC 어드레스라는 점에 유의함)> The SCS can be identified and removed by [this]. R-TWT SPs scheduled for this SCS may be modified or removed. For example, if R-TWT SPs are scheduled for this SCS, their durations must be reduced by the amount of time required to transmit traffic belonging to this SCS when the SCS is removed. If R-TWT SPs are scheduled only for this SCS, the R-TWT SPs must be canceled. The AP may add a TWT element to indicate a change in R-TWT scheduling.

[0111] RTA-TSPEC is configured by non-AP STAs to indicate the specifications and QoS requirements of SCS traffic. When an AP receives this field, it can use the information within it to determine whether to accept or reject the SCS request. If the AP accepts an SCS request that also requires R-TWT setup, the AP must also transmit the SCS traffic and schedule R-TWT SPs to satisfy its QoS requirements.

[0112] The modified TWT element field has the format shown in FIG. 28, which sets a non-AP STA to indicate an R-TWT setup request for the transmission of traffic for an SCS. When an AP receives this field, the AP schedules an R-TWT for the transmission of traffic for the SCS indicated in the SCS descriptor element (i.e., SCSID) according to the requirements indicated in the TWT element. The parameter settings and functions of this element may be the same as those in the TWT signaling requesting membership in the R-TWT.

[0113] A non-AP STA may determine whether to add one or more TWT elements to a single SCS descriptor element when the R-TWT request subfield within the modified TS information field is set to "required" or "optional". TWT elements must not be added to the SCS descriptor element if the R-TWT request subfield within the modified TS information field is set to "not required". If a non-AP STA sets the R-TWT request subfield within the modified TS information field to "required" or "optional" but does not add TWT elements to the SCS descriptor element, the AP still schedules the R-TWT for the transmission of traffic for the SCS indicated in the SCS descriptor element. R-TWT scheduling may be carried in the corresponding SCS status field within the SCS response frame.

[0114] The negotiation type subfield of the TWT element is "3" to indicate that the non-AP STA is for R-TWT membership.

[0115] When the request type within the SCS descriptor element is set to "Additional", the TWT setup command field within the request type field in the broadcast TWT parameter set field(s) within the TWT element must be set to "TWT request", "TWT offer", or "TWT demand". The TWT request subfield within the request type field in the broadcast parameter set field(s) within the TWT element is set to "1" to indicate an R-TWT membership request.

[0116] In at least one embodiment / mode / case, the request type within the SCS descriptor element is set to "change", but it will not be possible to add a TWT element to the SCS descriptor element.

[0117] When the request type within the SCS descriptor element is set to "Remove," if the traffic of the SCS is the only traffic stream of a non-AP STA scheduled to be transmitted by some R-TWTs, the TWT setup command field within the TWT element can be set to "TWT Deny." Then, the non-AP STA is no longer a member of these R-TWTs.

[0118] In at least one embodiment / mode / case, multiple TWT elements may be carried in a single modified SCS descriptor field to indicate a single value or a range of values, such as for a Target Wake Time (TWT) field, a Nominal Minimum TWT Wake Duration field, and a TWT Wake Interval Parameter for the same R-TWT. To indicate a single value for a parameter, the STA sets the value of the parameter identically in each TWT element for the same R-TWT on the same link. A range of values ​​may also be expressed. For example, in at least one embodiment, a range of values ​​for a parameter is indicated by an STA that sets the value of the parameter differently in each TWT element for the same R-TWT on the same link. The range indicated for a parameter is a range that includes all values ​​starting from a lower value and going up to a higher value, regardless of their order in the TWT elements, excluding the TWT Wake Interval Mantissa and TWT Wake Interval Exponential fields. The range indicated for the TWT wake interval starts at the lower of the two TWT wake interval values ​​and ends at the higher of the two TWT wake interval values, and the TWT wake interval is determined from the TWT wake interval mantissa and TWT wake interval exponent fields (copied from draft P802.11ax D8.0).

[0119] FIG. 24 illustrates an exemplary embodiment (170) of an RTA-TSPEC element that may include the RTA attributes of the present disclosure as well as two parts of the original TSPEC, exemplified by subfields of nominal service interval, reliability, jitter, MSDU lifetime, and deterministic service. It should be understood that a subset or superset of the above subfields may be used without departing from the teachings of the present disclosure.

[0120] FIG. 25 illustrates an exemplary embodiment (190) of a modified TS information field in an RTA-TSPEC element. The TSPEC may be identical to that shown in FIG. 1, except that the TS information field is as shown in FIG. 25 instead of FIG. 2.

[0121] The value of the TSID field within the TS information field of TSPEC can be set to a value of 0 to 15 instead of 8 to 15 as in FIG. 1.

[0122] User priority in the TS information field of TSPEC (or the control information field of the QoS attribute element) may be reserved when there is at least one TCLAS element or intra-AC priority element in the same SCS descriptor element. When no TCLAS element exists in the same SCS descriptor element, the user priority (or TID) may be set to indicate the user priority (or TID) of the traffic. If the SCS setup is successful, the traffic of that user priority (or TID) will belong to that SCS. For example, if this user priority (or TID) is set to "6", i.e., UP6 (or TID6), for the SCS setup, all traffic of UP6 (or TID6) belongs to that SCS. If the TID is between 0 and 7, UP must be the same value as the TID.

[0123] A default use case field may be added to the TS information field (or the control information field of the QoS attribute element). This field may be configured to display some classic use cases of traffic, such as AR / VR, online games, robotics, etc. When the default use case is set to "0", this indicates that no use case is specified and the parameters in the RTA-TSPEC element must be set manually. If the default use case field is set to a specific use case, e.g., AR / VR, some parameters in the RTA-SPEC element may be set to default. In at least one embodiment / mode / case, the default use case may control the format of the RTA-TSPEC. Some fields having default parameter settings for a specific use case in the RTA-TSPEC element may be removed from the RTA-TSPEC, and some additional fields may be added.

[0124] The R-TWT request field is configured to indicate whether the AP needs to schedule R-TWT SPs for the transmission of SCS traffic streams.

[0125] If this field is set to "Required", the AP must schedule an R-TWT for the transmission of SCS traffic. If the AP cannot schedule an R-TWT for the transmission of SCS traffic, it must reject SCS setup requests from non-AP STAs.

[0126] If this field is set to "Optional," the AP attempts to schedule R-TWTs for SCS traffic transmission. The AP can accept SCS membership requests from non-APs even if it cannot schedule R-TWT SPs for SCS traffic transmission.

[0127] If this field is set to "Not Required," the AP does not need to consider R-TWT scheduling for the SCS during the SCS setup procedure. The TWT element is not included in the same modified SCS descriptor element or the same modified SCS status field of the RTA-TSPEC element.

[0128] When this field is set to "Required" or "Optional", a non-AP STA may include a TWT element in the same modified SCS descriptor element of the RTA-TSPEC element to indicate the TWT setup request.

[0129] When this field is set to "required" or "optional," in at least one embodiment / mode / case, the non-AP STA does not include any TWT elements in the same modified SCS descriptor element of the RTA-TSPEC element. Then, the AP may still transmit TWT elements in the response frame to schedule R-TWT SPs for the transmission of SCS traffic.

[0130] Returning to Fig. 24, the RTA attribute field indicates additional QoS requirements for latency-sensitive traffic under this RTA-TSPEC. In at least one embodiment / mode / case, this field appears only as a TSPEC element when RTA-TSPEC is implemented on both the non-AP STA and the AP.

[0131] Under this RTA-TSPEC, a reliability field is set by a non-AP STA to indicate the packet loss requirements for latency-sensitive traffic. When an AP receives this field, it must estimate the resource distribution for the transmission of traffic under this RTA-TSPEC to ensure that the packet loss of traffic under this RTA-TSPEC is less than the packet loss indicated in the reliability field. Packet loss may be the proportion of packets under this RTA-TSPEC that are not delivered within the limited latency (or MSDU lifetime). It should be noted that this field may also represent the proportion of packets under this RTA-TSPEC that are delivered within the limited latency (or MSDU lifetime).

[0132] A jitter field is set by a non-AP STA to indicate the jitter requirements of the traffic under this RTA-TSPEC. When the AP receives this field, it preferably performs an estimation of the resource distribution for the transmission of the traffic under this RTA-TSPEC to ensure that the jitter requirements of the traffic under this RTA-TSPEC can be satisfied.

[0133] The MSDU lifetime field indicates the time an MSDU can be stored in a queue. A non-AP STA sets this field to indicate the lifetime of an MSDU or A-MSDU for traffic under this RTA-TSPEC when the deterministic service field is set to the first state (e.g., "1"). When a non-AP STA receives this field and the deterministic service field is set to this first state, the MSDU or A-MSDU will be dropped if it is not successfully transmitted within its lifetime. When the deterministic service field is set to the second state (e.g., "0"), this field is reserved. It should be noted that this field may be replaced by the delay limit field in the TSPEC element.

[0134] A deterministic service field is set by a non-AP STA to indicate whether the MSDU of traffic under this RTA-TSPEC will be dropped when its lifespan expires. If the non-AP STA sets this field to a first state (e.g., "1"), the MSDU or A-MSDU of traffic under this RTA-TSPEC will be dropped when its lifespan expires. Otherwise, the non-AP STA sets this field to a second state (e.g., "0"). If the AP receives this field with a value of "1", the MSDU of traffic under this RTA-TSPEC will be dropped when its lifespan expires. If the AP receives this field set to "0", there is no lifespan for the MSDU of traffic under this RTA-TSPEC. Note that this field is not required if the value of the MSDU lifespan field, e.g. "0", indicates that the MSDU lifespan is not specified and the MSDU of traffic under this RTA-TSPEC will not be dropped due to the expiration of the MSDU lifespan.

[0135] FIG. 27 illustrates an exemplary embodiment (230) of a modified SCS status field of an SCS indicated in the SCS ID field. The modified SCS status field may carry an R-TWT setup response for the traffic transmission of the SCS indicated in the SCS. Modifications to the modified SCS status field compared to those shown in FIG. 14 are described below. Without any explanation below, these fields are identical to or derived from those of FIG. 1. The fields of the SCS status are as follows.

[0136] The Element ID field indicates that this is a modified SCS state element. The Length field indicates the length of the modified SCS state element.

[0137] The TCLAS field, TCLAS processing field, and RTA-TSPEC field are configured to indicate proposed parameters in these fields when the AP rejects an SCS setup request by a non-AP STA. The non-AP STA may resend the SCS setup request using the proposed parameters. If the AP accepts the SCS setup, the AP may duplicate the parameters from the fields received from the SCS setup request, or decide not to include these fields in the SCS status field.

[0138] The modified TWT element field can be configured as illustrated in FIG. 28. The AP sets this field to indicate an R-TWT setup response for the transmission of traffic from the SCS. When a non-AP STA receives this field, it can determine whether some R-TWTs are scheduled for the transmission of traffic from the SCS. The parameter settings and functions of this element may be the same as those in TWT signaling to respond to a membership request from an R-TWT.

[0139] When a TWT request is accepted, the non-AP STA must follow R-TWT scheduling as indicated in the TWT element for the transmission of SCS traffic.

[0140] If the TWT request is not accepted, the information within the TWT element indicates the proposed parameter settings within the TWT element to request R-TWT membership for the SCS traffic stream. A non-AP STA may transmit a separate TWT request frame to request R-TWT membership. The negotiation type subfield of the TWT element (as shown in Fig. 6) is "3".

[0141] In at least one embodiment / mode / case, the AP adds more than one modified TWT element to a single modified SCS state element to schedule multiple R-TWTs for traffic transmission of an SCS traffic stream. In at least one embodiment / mode / case, when one modified TWT element is configured to accept a TWT setup, other modified TWT elements within the same SCS state element must also be configured to accept a TWT setup.

[0142] It should be noted that the result of the SCS setup (e.g., acceptance or rejection of the SCS setup) is reported in the status field of the modified SCS status as shown in Fig. 14.

[0143] FIG. 28 illustrates an exemplary embodiment (250) of a modified TWT element. All fields within the modified TWT element may be identical to those within the TWT element as illustrated in FIG. 5, except that a link ID field is added to each (modified) broadcast TWT parameter set field. It should be noted that the modified broadcast TWT parameter set fields may be used in TWT signaling as illustrated in FIG. 15.

[0144] The Link ID field is set to indicate the link to which the TWT information displayed in the corresponding Broadcast TWT Parameter Set field will be applied. For example, if the Link ID of the Modified Broadcast TWT Parameter Set field is set to Link2, the Modified Broadcast TWT Parameter Set field will be applied on Link2.

[0145] When setting parameters in the broadcast TWT parameter set field, the parameter setting may be based on the time reference of the link indicated in the link ID field. For example, when the link ID of the modified broadcast TWT parameter set field is set to Link 2 and the modified broadcast TWT parameter set field is transmitted over Link 1, the target wake time field may be set to the time of the timing synchronization function (TSF) of a non-AP STA (or AP) on Link 2, and the non-AP STA on Link 2 is instructed to wake up.

[0146] The TWT parameter information field may have multiple modified broadcast TWT parameter set fields. In some cases, the broadcast TWT parameter set fields may have different TWT IDs. Subsequently, each broadcast TWT parameter set field represents TWT setup commands for an independent TWT.

[0147] While multiple broadcast TWT parameter set fields may share the same TWT ID, using different link IDs is also permitted. This can be used to indicate TWTs where the SPs are scheduled for the same time periods on different links (i.e., TWT SPs on different links start and end simultaneously). In this case, the TWT ID can be managed by the AP at the MLD level. That is, if a TWT generated by an AP MLD with TWT ID 3 exists only on Link 1, no other TWT with TWT ID 3 should exist on other links of the same AP MLD. It should be noted that TWT ID 0 may be an exception.

[0148] Additionally, it should be noted that the trigger field within the request type field in the broadcast TWT parameter information field, as illustrated in FIG. 8, may differ when it is in the modified broadcast TWT parameter set field. When this field is set to a first state (e.g., "1") in the modified broadcast TWT parameter set field of the R-TWT, this indicates that the R-TWT SPs are trigger-enabled R-TWT SPs. During the trigger-enabled R-TWT SPs scheduled in the modified broadcast TWT parameter set field, non-AP STAs other than the member STAs of the R-TWT SP are not allowed to content for the channel during the R-TWT SP when they receive this field, provided that the field specifies that only DL transmissions and trigger-based UL transmissions are allowed between the APs that are members of the R-TWT and their associated non-AP STAs during the R-TWT SPs. Thus, only the APs are allowed to content for the channel during the R-TWT SPs, and the members of the R-TWT are not allowed. Note that non-AP STAs that do not support R-TWT operations are not constrained to follow this rule. Otherwise, this field is set to a second state (e.g., "0"), and any members of the R-TWT may compete for the channel to initiate UL transmission during the R-TWT SPs. Note that this field may contain a new field instead of reusing the trigger field from the request type field.

[0149] In at least one embodiment, the AP or AP MLD may assign distinct TWT IDs to the broadcast TWTs and R-TWTs. That is, if the AP generates a broadcast TWT with TWT ID 1, the AP must not assign TWT ID 1 to other R-TWTs, and vice versa.

[0150] It should be understood that the broadcast TWT parameter set field can be replaced by any type of TWT parameter set field, such as individual TWT parameter set fields for individual TWT signaling. Subsequently, the individual TWT parameter set field with the attached (modified) link ID field represents the individual TWT parameter set for the link indicated in the link ID field. Time settings in the individual TWT parameter set field, such as the target wake time, are set based on the TSF time on the link indicated in the link ID field.

[0151] 3.3.3. Examples of setting up R-TWT SPs during SCS setup

[0152] This section illustrates several examples of setting up R-TWT SPs during the SCS setup procedure.

[0153] Table 1 provides details regarding three SCS traffic streams (SCS1, SCS2, and SCS3) in an R-TWT scheduling AP for the examples illustrated in FIGS. 29 to 32.

[0154] In SCS1, the SCSID is set to the first state (e.g., "1"), and this SCS is established between STA2 and AP1 (or MLD1). The direction of this SCS traffic stream is uplink. The traffic identifier (TID) of this SCS is "8", and the user priority value is "5". Two TWTs (i.e., TWTID 1 and 3) are scheduled to transmit this SCS traffic stream. Both TWTs are scheduled on Link 1.

[0155] In SCS2, the SCSID is set to "2", and this SCS is established between MLD2 and MLD1. The direction of this SCS traffic stream is downlink. The TID of this SCS is "9", and the user priority is "6". One TWT (i.e., TWTID 1) is scheduled to transmit this SCS traffic stream over Link 1.

[0156] In SCS3, the SCSID is set to "3", and this SCS is established between MLD3 and MLD1. The direction of this SCS traffic stream is downlink. The TID of this SCS is "10", and the user priority is "3". One TWT (i.e., TWTID 2) is scheduled to transmit this SCS traffic stream over Link 2.

[0157] You should know that an SCSID can be mapped to a TID linked to a TWT. Also, you should note that TID 0 through TID 7 can be identical to UP 0 through UP 7.

[0158] Table 2 provides details for other scheduled TWTs by AP MLD1, and MLD3 is a member of these TWTs. The SPs of these TWTs are scheduled on Link 1 and Link 2. Examples of these TWTs are illustrated in FIGS. 33 through 36. The exemplified target wait times are R-TWT4, a restricted TWT with TWT ID "4"; B-TWT5, a broadcast TWT with TWT ID "5"; and I-TWT6, an individual TWT with TWT ID "6".

[0159] FIG. 29 illustrates an exemplary embodiment (270) for scheduling R-TWTs for an SCS traffic stream during the setup procedure of the SCS. The figure illustrates communication between AP1 (272) of MLD1 and STA1 (274) of MLD2.

[0160] As illustrated in the drawing, the SCS setup with the R-TWT (276) begins with STA1 sending an SCS request frame (278) to AP1 to establish SCS2. The format of the SCS request frame may be similar to that shown in FIG. 12, so that the SCS descriptor list field within the SCS request frame can carry the modified SCS descriptor elements of SCS2 (shown in FIG. 23).

[0161] STA1 may set the R-TWT request field to "Required" or "Optional" in the TS information field of the RTA-TSPEC element of the modified SCS descriptor element of SCS2. Subsequently, STA1 may include a modified TWT element in the modified SCS descriptor element of SCS2 to indicate the R-TWT membership request for R-TWT1. Alternatively, it is permissible for STA1 not to include a modified TWT element in the SCS descriptor element of SCS2. If a modified TWT element is included, an example of parameter settings in the modified TWT element is described below.

[0162] The negotiation type subfield in the control field of the modified TWT element is set to "3" to indicate that it is intended to provide membership management. The modified broadcast parameter set field may be used in the TWT element, and thereby the broadcast TWT ID field within the broadcast TWT information field of the modified broadcast parameter set field is set to the TWT ID of R-TWT1, indicating that the modified broadcast parameter set field is for R-TWT1.

[0163] The request subfield within the request type field in the modified broadcast parameter set field of R-TWT1 is set to a first state (e.g., "1") to indicate an R-TWT1 membership request. The TWT setup command subfield within the request type field in the modified broadcast parameter set field of R-TWT1 is set to "TWT request," "TWT proposal," or "TWT demand," indicating that STA1 requests R-TWT1 membership with the proposed TWT parameter set in the modified broadcast parameter set field for R-TWT1.

[0164] The Broadcast TWT Recommendation subfield within the Request Type field of the Modified Broadcast Parameter Set field of R-TWT1 is set to "4" to indicate that this request is for R-TWT. The Target Wake Time field within the Modified Broadcast Parameter Set field of R-TWT1 is set to the TSF time on Link 1 where STA1 proposes the start of the first R-TWT1 SP for SCS2. A non-AP STA may set it to 0 to allow the AP to make a decision. The TWT Wake Interval Mantissa and TWT Wake Interval Exponent fields within the Modified Broadcast Parameter Set field of R-TWT1 are set to the interval between R-TWT1 SPs proposed by STA1. A non-AP STA may set it to 0 to allow the AP to make a decision.

[0165] The Nominal Minimum TWT Wake Duration field in the Modified Broadcast Parameter Set field of R-TWT1 is set to one R-TWT1 SP time proposed by STA1. A non-AP STA may set it to 0 and allow the AP to make the decision. The Link ID subfield in the Modified Broadcast Parameter Set field is set to Link1.

[0166] When AP1 receives an SCS request frame from STA1, it can decide whether to accept the request. In this example, AP1 accepts the SCS request and schedules R-TWT1 for the transmission of the SCS2 traffic stream. AP1 sends an SCS response frame (280) back to STA1. The format of the SCS response frame may be similar to that shown in FIG. 14, so that the SCS status list field within the frame carries the modified SCS status field of SCS2 (shown in FIG. 27). A modified TWT element carrying the broadcast parameter set field of R-TWT1 may be included in the modified SCS status field of SCS2 to indicate that R-TWT1 is scheduled to transmit the SCS1 traffic stream. An example of parameter settings in the modified TWT element may be as described below.

[0167] The negotiation type subfield within the control field of the TWT element is set to "3" to indicate that it is for membership management.

[0168] The modified broadcast parameter set field can be used in the modified TWT element, and thereby the broadcast TWT ID field within the broadcast TWT information field in the modified broadcast parameter set field is set to the TWT ID of R-TWT1, indicating that the modified broadcast parameter set field is for R-TWT1.

[0169] The request subfield within the request type field in the modified broadcast parameter set field of R-TWT1 is set to a second state (e.g., "0") to indicate that the modified broadcast parameter set field will respond to the R-TWT1 membership request.

[0170] The TWT setup command subfield within the request type field in the modified broadcast parameter set field of R-TWT1 is set to "TWT accept" to indicate that AP1 accepts the R-TWT1 membership request.

[0171] The TWT Broadcast Recommendation subfield within the Request Type field of the Modified Broadcast Parameter Set field of R-TWT1 is set to indicate that the response is for R-TWT. The Target Wake Time field in the Modified Broadcast Parameter Set field of R-TWT1 is set to the TSF time on Link 1 where the first R-TWT1 SP for SCS2 starts. The TWT Wake Interval Mantissa and TWT Wake Interval Exponent fields in the Modified Broadcast Parameter Set field of R-TWT1 are set to the interval between R-TWT1 SPs.

[0172] The nominal minimum TWT wake duration field in the modified broadcast parameter set field of R-TWT1 is set to one R-TWT1 SP time. The link ID subfield in the modified broadcast parameter set field of R-TWT1 is set to Link 1. The drawing illustrates an example of a trigger-enabled R-TWT1 SP (282). AP1 can acquire channel access for the R-TWT1 SP (284), send DL PPDUs (288 and 292) carrying an SCS2 traffic stream to STA1 during the R-TWT1 SP, and begin receiving acknowledgments (e.g., BA (Block Ack)) (290 and 294).

[0173] In some cases, the R-TWT SP time must not be greater than the transmission time required by the SCS traffic streams scheduled to be transmitted during the R-TWT SP. For example, in this case, if STA1 is the only member of the R-TWT1 SP transmitting the SCS2 traffic stream, the R-TWT1 SP time must be equal to the transmission time required by the SCS2 traffic stream. For example, the R-TWT1 SP time per second must be equal to the median time indicated in the RTA-TSPEC element during the SCS2 setup.

[0174] If only one R-TWT is scheduled for traffic transmission of the SCS, the interval of the R-TWT (286) (the interval between two consecutive SPs of the same R-TWT) must be between the minimum service interval and the maximum service interval of the SCS (indicated in the RTA-TSPEC element during SCS setup). For example, the interval = (minimum service interval + maximum service interval) / 2. As illustrated in the drawing, the interval of R-TWT1 (the interval between R-TWT1 SPs) must be between the minimum service interval and the maximum service interval of SCS2. The drawing illustrates this interval (286) between the R-TWT1 SP (284) and the subsequent R-TWT1 SP (296).

[0175] FIG. 30 illustrates an exemplary embodiment (310) illustrating a case where R-TWT for an SCS traffic stream is not scheduled during the setup procedure of the SCS. The figure illustrates communication between AP1 (272) of MLD1 and STA1 (274) of MLD2.

[0176] The drawing illustrates the use of separate SCS setup and R-TWT setup (312). STA1 transmits an SCS request frame (314) to AP1 to establish SCS2. The format of the SCS request frame may be similar to that shown in FIG. 12, so that the SCS descriptor elements for SCS2 within the frame may be as shown in FIG. 23.

[0177] STA1 can set the R-TWT request field to "optional" or "not required" in the TS information field of the RTA-TSPEC element of the modified SCS descriptor element of SCS2 in the SCS request frame. If STA1 sets the R-TWT request field to "optional", STA1 may include the modified TWT element in the modified SCS descriptor element of SCS2 to indicate the R-TWT membership request for R-TWT1 or other R-TWTs.

[0178] In some cases, STA1 may not include the modified TWT element in the modified SCS descriptor element of SCS2. It should be noted that if the R-TWT request field is set to "not required," the modified TWT element is not included in the SCS descriptor element. If the R-TWT request field is set to "optional" and the modified TWT element is included in the SCS descriptor element of SCS2, the parameters within the modified TWT element may be set as described below.

[0179] The negotiation type subfield within the control field of the TWT element is set to "3" to indicate that it is for membership management.

[0180] The modified broadcast parameter set field may be present in the modified TWT element, and thereby the broadcast TWT ID field within the broadcast TWT information field in the modified broadcast parameter set field is set to the TWT ID of R-TWT1, indicating that the modified broadcast parameter set field is for R-TWT1.

[0181] The request subfield within the request type field in the modified broadcast parameter set field of R-TWT1 is set to a second state (e.g., "0") to indicate that the modified broadcast parameter set field will respond to the R-TWT1 membership request.

[0182] The TWT Setup Command subfield within the Request Type field in the Modified Broadcast Parameter Set field of R-TWT1 is set to "Accept TWT" to indicate that AP1 accepts the R-TWT1 membership request. The TWT Broadcast Recommend TWT subfield within the Request Type field in the Modified Broadcast Parameter Set field of R-TWT1 is set to indicate that the response is for R-TWT. The Target Wake Time field in the Modified Broadcast Parameter Set field of R-TWT1 is set to the TSF time on Link 1 where the first R-TWT1 SP for SCS2 starts. The TWT Wake Interval Mantissa and TWT Wake Interval Exponent fields in the Modified Broadcast Parameter Set field of R-TWT1 are set to the interval between R-TWT1 SPs. The Nominal Minimum TWT Wake Duration field in the Modified Broadcast Parameter Set field of R-TWT1 is set to the time of one R-TWT1 SP. The Link ID subfield in the Modified Broadcast Parameter Set field of R-TWT1 is set to Link 1.

[0183] When AP1 receives an SCS request frame from STA1, it decides whether to accept the request and retransmit an SCS response frame. The format of the SCS response frame (316) may be similar to that shown in FIG. 14, so that the SCS status list field within the frame carries the modified SCS status field of SCS2 as shown in FIG. 27. If STA1 requests that an R-TWT be set up for SCS2, a modified TWT element may be included in the SCS status field for SCS2 to indicate the result of the R-TWT setup for the SCS1 traffic stream.

[0184] In this example, AP1 accepts the SCS request but does not schedule R-TWT for the transmission of the SCS2 traffic stream at that time, as exemplified in the following scenario.

[0185] STA1 requests membership for R-TWTs other than R-TWT1, but AP1 does not accept the membership request. Instead, AP1 sends back to STA1 an SCS response frame containing TWT elements to propose that AP1 request membership for R-TWT1. The parameter settings in the modified TWT elements may be as described below.

[0186] The Negotiation Type subfield within the Control field of the TWT element is set to "3" to indicate that it is for membership management. The Modified Broadcast Parameter Set field may be present in the Modified TWT element, thereby setting the Broadcast TWT ID field within the Broadcast TWT Information field in the Broadcast Parameter Set field to the TWT ID of R-TWT1, indicating that the Broadcast Parameter Set field is for R-TWT1. The Request subfield within the Request Type field in the Modified Broadcast Parameter Set field of R-TWT1 is set to "0" to respond to the R-TWT1 membership request for SCS2. The TWT Setup Command subfield within the Request Type field in the Modified Broadcast Parameter Set field of R-TWT1 is set to "TWT Instruction" to indicate that AP1 does not accept the R-TWT1 membership request for SCS2, but the parameters in the Modified Broadcast Parameter Set field include the parameters proposed to resend the R-TWT Setup request. The TWT Broadcast Recommendation subfield within the Request Type field of the Modified Broadcast Parameter Set field of R-TWT1 is set to indicate that R-TWT1 is an R-TWT. The Target Wake Time field in the Broadcast Parameter Set field of R-TWT1 is set to the TSF time on Link 1 where the first R-TWT1 SP for SCS2 begins. The TWT Wake Interval Mantissa and TWT Wake Interval Exponential fields in the Broadcast Parameter Set field of R-TWT1 are set to the interval between R-TWT1 SPs. The Nominal Minimum TWT Wake Duration field in the Broadcast Parameter Set field of R-TWT1 is set to the time of a single R-TWT1 SP.

[0187] After SCS2 is successfully established, STA1 may transmit a TWT setup frame to request (318) membership of an R-TWT such as R-TWT1. Subsequently, AP1 may decide to accept or reject the request as defined in IEEE 802.11ax. The format of the TWT setup frame may be the same as shown in FIG. 16, and thus the format of the TWT elements within the frame may be as shown in FIG. 28. It should be noted that the R-TWT setup (R-TWT request (318) and R-TWT response (320)) can be performed independently at any time.

[0188] The drawing illustrates an example of a trigger-enabled R-TWT1 SP. AP1 is shown to acquire channel access to the first R-TWT1 SP for SCS2 (282), send DL PPDUs (288 and 292) carrying the SCS2 traffic stream to STA1 during the R-TWT1 SP, and start the R-TWT1 SP (284) to receive BAs (290 and 294) from STA1.

[0189] The interval (286) between R-TWT SPs is shown between the first R-TWT SP (284) and the second R-TWT SP (296). In at least some cases, the R-TWT SP time must not be greater than the transmission time required by the SCS traffic stream scheduled to be transmitted during the R-TWT SP. For example, in this case, if STA1 is the only member of the R-TWT1 SP transmitting the SCS2 traffic stream, the R-TWT1 SP time must be equal to the transmission time required by the SCS2 traffic stream. For example, the R-TWT1 SP time per second must be equal to the intermediate time indicated in the RTA-TSPEC element during the SCS2 setup.

[0190] If only a single R-TWT is scheduled for the traffic transmission of an SCS, the interval of the R-TWT (the interval between two consecutive SPs of the same R-TWT) must be limited to be between the minimum service interval and the maximum service interval of that SCS (indicated in the RTA-TSPEC element during SCS setup) in at least some cases. For example, interval = (minimum service interval + maximum service interval) / 2. As illustrated in the figure, the interval of R-TWT1 must be between the minimum service interval and the maximum service interval of SCS2.

[0191] FIG. 31 illustrates an exemplary embodiment (350) of scheduling multiple R-TWTs for a single SCS traffic stream during the setup procedure of the SCS. The figure illustrates communication between AP1 (352), STA2 (354) of MLD1 and STA1 (356) of MLD2.

[0192] As illustrated in the drawing, an SCS setup is performed with an R-TWT (358) in which STA2 sends an SCS request frame (360) to AP1 to establish SCS1. The format of the SCS request frame may be similar to that shown in FIG. 12, so that the SCS descriptor list field within the frame can carry the modified SCS descriptor elements of SCS1 shown in FIG. 23.

[0193] STA2 may set the R-TWT request field to "required" or "optional" in the TS information field within the RTA-TSPEC element in the modified SCS descriptor element of SCS1 in the SCS request frame. Then, STA2 may include a modified TWT element in the modified SCS descriptor element of SCS1 having multiple broadcast TWT parameter set fields (one field for R-TWT1 and another field for R-TWT3) to indicate the R-TWT membership request for R-TWT1 and R-TWT3. In certain cases, STA2 may not include any modified TWT elements in the modified SCS descriptor element of SCS1.

[0194] When AP1 receives an SCS request frame from STA2, it can decide whether to accept the request. In this example, AP1 accepts the SCS request and schedules R-TWT1 and R-TWT3 for the transmission of the SCS1 traffic stream. AP1 sends an SCS response frame (362) back to STA2. The format of the SCS response frame may be similar to that shown in FIG. 14, in which the SCS status list field within the frame carries the modified SCS status field of SCS1 shown in FIG. 27. A modified TWT element having a plurality of modified broadcast TWT parameter set fields (one field for R-TWT1 and another field for R-TWT3) may be included in the modified SCS status field of SCS1 to indicate that R-TWT1 and R-TWT3 are scheduled to transmit the SCS1 traffic stream.

[0195] The drawing illustrates an example of a trigger-enabled R-TWT1 SP (364). In this example, STA2 and STA1 are members of R-TWT1, and traffic transmissions of SCS1 and SCS2 are scheduled to be transmitted during the R-TWT1 SP. AP1 acquires channel access and requests STA2's buffer status by sending a Buffer Status Report Poll (BSRP) frame (368) to STA2. STA2 reports its buffer status by sending back a Buffer Status Report (BSR) frame (370). Then, AP1 sends a DL PPDU (372) to STA1, first carrying the SCS2 traffic stream during the R-TWT1 SP. This may occur because SCS2's UP has a higher priority than SCS1's UP. STA1 responds with a block acknowledgment (374). After that, AP1 sends a trigger frame (376) to STA2 to trigger a UL transmission (378) for the SCS1 traffic stream according to the buffer state of the SCS1 traffic stream, and AP1 responds with a BA (380), which terminates the first R-TWT3 SP for SCS1 (365).

[0196] Similarly, when the R-TWT3 SP (382) starts, AP1 schedules the transmission of the SCS1 traffic stream's UL during the R-TWT3 SP. The drawing illustrates AP1 transmitting the BSRP (384) and receiving the BSR (386) back from STA2, after which AP1 generates a default trigger (388) that triggers STA2 to then transmit the UL PPDU (390).

[0197] In many cases, the R-TWT SP time must not be greater than the transmission time required by the SCS traffic streams scheduled to be transmitted during the R-TWT SP. For example, in this case, if STA1 and STA2 are members of the R-TWT1 SP transmitting the SCS2 and SCS1 traffic streams, the R-TWT1 SP time must be equal to the transmission time required by the SCS2 and SCS1 traffic streams. For example, the R-TWT1 SP time per second must be equal to the sum of the intermediate times indicated in the RTA-TSPEC elements during the SCS2 and SCS1 setups.

[0198] If multiple R-TWTs are scheduled for traffic transmission of the SCS, the R-TWT SP must be scheduled for a time interval set between the minimum service interval and the maximum service interval of the SCS (indicated in the RTA-TSPEC element during SCS setup). As illustrated in the drawing, the interval (392) between two consecutive R-TWT SPs, illustrated here as R-TWT1 and R-TWT3 (even if the two SPs are from different R-TWTs), must be between the minimum service interval and the maximum service interval of SCS1. For example, the interval of R-TWT1 = the interval of R-TWT3 = (the minimum service interval of SCS1 + the maximum service interval of SCS1). The interval between the R-TWT1 SP and its neighbor R-TWT3 SP is between the minimum service interval and the maximum service interval of SCS1, such as (the minimum service interval of SCS1 + the maximum service interval of SCS1) / 2. It should be noted that SCS2 was established as shown in FIG. 29 or FIG. 30.

[0199] FIG. 32 illustrates an exemplary embodiment (410) of an SCS setup procedure in which R-TWTs on different links are set up for the transmission of an SCS traffic stream. The figure illustrates both sides (412, 413) of communication between STA3 (442) and AP1 (448) on Link 1, and between STA5 (444) and AP2 (450) on Link 2. STA3 and STA5 are part of MLD3 (440), while AP1 and AP2 are part of MLD1 (446).

[0200] As illustrated in the drawing, STA3 transmits an SCS request frame (416) to AP1 (448) to establish SCS3 in the SCS + R-TWT setup process (414). The format of the SCS request frame may be similar to that shown in FIG. 12, so that the SCS descriptor list field within the frame carries the SCS descriptor elements of the SCS3 shown in FIG. 23.

[0201] STA3 may set the R-TWT request field to "required" or "optional" in the TS information field of the RTA-TSPEC element in the modified SCS descriptor element of SCS3 in the SCS request frame. Then, STA3 may include a modified TWT element in the modified SCS descriptor element of SCS3 to indicate the R-TWT membership request for R-TWT2 on Link 2. In at least one embodiment / mode / case, STA3 does not include a TWT element in the modified SCS descriptor element of SCS2. Where a modified TWT element is included, examples of parameter settings in the modified TWT element for the R-TWT2 setup request may be as follows.

[0202] The negotiation type subfield in the control field of the modified TWT element is set to "3" to indicate that it is for membership management. The modified broadcast parameter set field may be present in the TWT element, and the broadcast TWT ID field within the broadcast TWT information field in the modified broadcast parameter set field is set to the TWT ID of R-TWT2, indicating that the modified broadcast parameter set field is for R-TWT2.

[0203] The request subfield within the request type field in the modified broadcast parameter set field of R-TWT2 is set to the first state (e.g., "1") to indicate an R-TWT2 membership request. The TWT setup command subfield within the request type field in the modified broadcast parameter set field of R-TWT2 is set to "TWT request," "TWT proposal," or "TWT demand" to indicate that MLD3 requests R-TWT2 membership with the proposed set of TWT parameters in the modified broadcast parameter set field for R-TWT2. The TWT broadcast TWT recommendation subfield within the request type field in the modified broadcast parameter set field of R-TWT2 is set to "4" to indicate that this request is for R-TWT. The target wake time field within the modified broadcast parameter set field of R-TWT2 is set to the TSF time on Link 2 where STA5 proposes the start of the first R-TWT2 SP for SCS3. A non-AP STA can set it to 0 and allow the AP to make a decision.

[0204] The TWT wake interval mantissa and TWT wake interval exponent fields in the modified broadcast parameter set field of R-TWT2 are set to the interval between R-TWT2 SPs proposed by MLD3. Non-AP STAs can also be set to 0, allowing AP to determine the interval.

[0205] The Nominal Minimum TWT Wake Duration field in the Modified Broadcast Parameter Set field of R-TWT2 is set to one R-TWT2 SP time proposed by MLD3. Non-AP STAs may set it to 0 and allow the AP to make the decision. The Link ID subfield within the Modified Broadcast Parameter Set field is set to Link 2.

[0206] When AP1 receives an SCS request frame from STA3, it can decide whether to accept the request. In this example, AP1 accepts the SCS request and schedules R-TWT2 for the transmission of the SCS3 traffic stream. AP1 sends an SCS response frame (418) back to STA3 for the SCS3, R-TWT2, on Link 2. The format of the SCS response frame may be similar to that shown in FIG. 14, so that the SCS status list field within the frame carries the modified SCS status field of SCS3 shown in FIG. 27. A modified TWT element carrying the modified broadcast parameter set field of R-TWT2 may be included in the modified SCS status field of SCS3 to indicate that R-TWT2 is scheduled to transmit the SCS3 traffic stream. An example of parameter settings in the modified TWT element may be as described below.

[0207] The Negotiation Type subfield within the Control field of the TWT element is set to "3" to indicate that it is for membership management. The Modified Broadcast Parameter Set field is located in the Modified TWT element, and the Broadcast TWT ID field within the Broadcast TWT Information field of the Modified Broadcast Parameter Set field is set to the TWT ID of R-TWT2, indicating that the Modified Broadcast Parameter Set field is for R-TWT2.

[0208] The request subfield within the request type field in the modified broadcast parameter set field of R-TWT2 is set to a second state (e.g., "0") to indicate that the modified broadcast parameter set field will respond to an R-TWT2 membership request. The TWT setup command subfield within the request type field in the modified broadcast parameter set field of R-TWT2 is set to "TWT accept" to indicate that MLD1 accepts the R-TWT2 membership request. The TWT broadcast TWT recommendation subfield within the request type field in the modified broadcast parameter set field of R-TWT2 is set to indicate that the response is for R-TWT.

[0209] The Target Wake Time field in the Modified Broadcast Parameter Set field of R-TWT2 is set to the TSF time on Link 2, which is the time when the first R-TWT2 SP for SCS3 begins. The TWT Wake Interval Mantissa and TWT Wake Interval Exponent fields in the Modified Broadcast Parameter Set field of R-TWT2 are set to the interval between R-TWT2 SPs. The Nominal Minimum TWT Wake Duration field in the Modified Broadcast Parameter Set field of R-TWT2 is set to a single R-TWT2 SP time. The Link ID subfield of the Modified Broadcast Parameter Set field of R-TWT2 is set to Link 2.

[0210] The drawing illustrates an example of a trigger-enabled R-TWT2 SP (420). AP2 (450) can acquire channel access during the interval between R-TWT2 SPs (424) and begins sending DL PPDUs (428, 432) carrying an SCS3 traffic stream to STA5 during R-TWT2 SP (426). STA5 responds to the PPDUs with BAs (430 and 434).

[0211] Another R-TWT2 SP (436) is shown to start after the interval between the R-TWT2 SPs.

[0212] FIG. 33 illustrates an exemplary embodiment (470) of an R-TWT setup procedure (484) that utilizes a modified TWT element on one link to set up R-TWTs on multiple links. The figure illustrates communications between STA3 (476) and AP1 (480) on Link 1, and between STA5 (478) and AP2 (482) on Link 2. STA3 and STA5 are part of MLD3 (472), while AP1 and AP2 are part of MLD1 (474).

[0213] As illustrated in the drawing, STA3 transmits an R-TWT request (setup) frame (486) on Link 1 to AP1 to request membership of R-TWT4. R-TWT4 is an R-TWT whose SPs are scheduled across multiple different links. The format of the TWT request frames may be similar to that illustrated in FIG. 16, and thus the TWT elements within the frame may be as illustrated in FIG. 28.

[0214] The R-TWT request frame (486) may carry multiple modified broadcast TWT parameter set fields of R-TWT4 in the TWT parameter information field within a single TWT element to indicate that this is a membership request for R-TWT4 on which the SPs are scheduled on multiple different links. The link ID field in the modified broadcast TWT parameter set field of R-TWT4 indicates the link on which the R-TWT4 scheduling indicated in the modified broadcast TWT parameter set field is proposed to be scheduled. The target wake time field in the modified broadcast TWT parameter set field of R-TWT4 is preferably set based on the TSF on the link indicated in the link ID field of the same modified broadcast TWT parameter set field of R-TWT4. The TWT wake interval and nominal minimum TWT wake duration may be set identically in all modified broadcast TWT parameter set fields. Additionally, the TWT setup command field in the request type field of all broadcast TWT parameter set fields of R-TWT4 is set to the same value.

[0215] When AP1 receives an R-TWT request frame from STA3, it decides whether to accept the request. In this example, AP1 accepts the R-TWT4 request. In response, AP1 sends an R-TWT response frame (488) back to STA3. The format of the R-TWT setup (response) frame may be similar to that shown in FIG. 16, and thus the TWT elements within the frame may be the same as those shown in FIG. 28. Multiple modified broadcast TWT parameter set fields of the R-TWT4 may be included in the TWT parameter information field within a single TWT element to indicate that this is a membership response of the R-TWT4. The target wake time field in the modified broadcast TWT parameter set fields is preferably set based on the TSF on the link indicated in the link ID field of the same target wake time field in the modified broadcast TWT parameter set fields. For example, as illustrated in the drawing, the target wake time field in the modified broadcast TWT parameter set field (490) of the R-TWT4 on Link 1 should be set to the TSF time of Link 1 when the first R-TWT4 SP on Link 1 starts. The target wake time field in the modified broadcast TWT parameter set field (492) of the R-TWT4 on Link 2 is preferably set to the TSF time of Link 2 when the first R-TWT4 SP on Link 2 starts. The TWT wake interval and the nominal minimum TWT wake duration are preferably set identically in all modified broadcast TWT parameter set fields of the R-TWT4. Additionally, the TWT setup command field within the request type field of all modified broadcast TWT parameter set fields of the R-TWT4 is set to the same value.

[0216] The drawing illustrates an example of a trigger-enabled R-TWT4 SP. AP1 and AP2 can acquire channel access from the R-TWT4 SP (496) as illustrated in the drawing, and simultaneously begin transmitting DL PPDUs (498, 500, 506 and 508) to STA3 and STA5 during the R-TWT4 SPs on both Link 1 and Link 2, and can respond back to the APs with BAs (502, 504, 510 and 512).

[0217] The drawing also shows the spacing (494) between the R-TWT4 SPs and where the next R-TWT4 SP (514) starts.

[0218] FIG. 34 illustrates an exemplary embodiment (530) of a broadcast TWT setup procedure for setting up broadcast TWTs on multiple links using modified TWT elements on one link. The figure illustrates communications between STA3 (476) and AP1 (480) on Link 1, and between STA5 (478) and AP2 (482) on Link 2. STA3 and STA5 are part of MLD3 (472), while AP1 and AP2 are part of MLD1 (474).

[0219] As illustrated in the drawing, during the B-TWT setup (532), STA3 transmits a B-TWT request (setup) frame (534) on Link 1 to AP1 to request membership in B-TWT5. B-TWT5 is a broadcast TWT whose SPs are scheduled across multiple different links. The format of the TWT request frames may be similar to that illustrated in FIG. 16, and thus the TWT elements within the frames may be the same as those illustrated in FIG. 28.

[0220] A B-TWT request frame (534) may incorporate multiple modified broadcast TWT parameter set fields of B-TWT5 into the TWT parameter information field within a single TWT element to indicate that this is a membership request for B-TWT5 where the SPs are scheduled on multiple different links. The link ID field in the modified broadcast TWT parameter set field of B-TWT5 indicates the link indicated in the modified broadcast TWT parameter set field where the B-TWT5 scheduling is proposed to be scheduled. The target wake time field in the modified broadcast TWT parameter set field of B-TWT5 may be set based on the TSF on the link indicated in the link ID field of the same modified broadcast TWT parameter set field of B-TWT5. The TWT wake interval and nominal minimum TWT wake duration may be set identically in all modified broadcast TWT parameter set fields of B-TWT5. In addition, the TWT setup command field within the request type field of all broadcast TWT parameter set fields of B-TWT5 is set to the same value.

[0221] When AP1 receives a B-TWT request frame from STA3, it can decide whether to accept the request. In this example, AP1 accepts the B-TWT5 request and sends a B-TWT response frame (536) back to STA3. The format of the B-TWT setup (response) frame may be similar to that shown in FIG. 16, and thus the TWT elements within the frame may be the same as those shown in FIG. 28.

[0222] Multiple modified broadcast TWT parameter set fields of B-TWT5 may be in the TWT parameter information field within a single TWT element to indicate that this is a membership response of B-TWT5. The target wake time field of the modified broadcast TWT parameter set fields is preferably set based on the timing synchronization function (TSF) (538 and 540) on the link indicated in the link ID field of the same target wake time field of the modified broadcast TWT parameter set fields. The TWT wake interval and the nominal minimum TWT wake duration may be set to the same value in all modified broadcast TWT parameter set fields of B-TWT5. Additionally, the TWT setup command field within the request type field of all modified broadcast TWT parameter set fields of B-TWT5 is set to the same value.

[0223] The drawing illustrates an example of B-TWT5 SP (542, 544), wherein AP1 and AP2 acquire channel access and simultaneously transmit DL PPDUs (546, 548, 554 and 556) to STA3 and STA5 during the B-TWT5 SPs on both Link 1 and Link 2.

[0224] The drawing also shows the spacing (542) between the B-TWT4 SPs and where the next B-TWT4 SP (562) starts.

[0225] FIG. 35 illustrates an exemplary embodiment (590) of negotiation of wake TBTT and wake intervals using modified TWT elements. The figure illustrates communications between STA3 (476) and AP1 (480) on Link 1, and between STA5 (478) and AP2 (482) on Link 2. STA3 and STA5 are part of MLD3 (472), while AP1 and AP2 are part of MLD1 (474).

[0226] As illustrated in the drawing, during TBTT negotiation (592), STA3 transmits a TWT request (setup) frame (594) to AP1 on Link 1 to request negotiation of the wake interval and wake TBTT on Link 1 and Link 2. The format of the TWT request frames may be similar to that illustrated in FIG. 16, and thus the modified TWT element within the frame may be as illustrated in FIG. 27, except that the broadcast TWT parameter set field of FIG. 28 is replaced with an individual TWT parameter set field as defined in IEEE 802.11ax. The negotiation type field within the control field of the modified TWT element is set to a first state (e.g., "1") to indicate that it is a negotiation of the wake TBTT and wake interval.

[0227] A TWT request frame (594) may carry multiple modified individual TWT parameter set fields in the modified TWT parameter information field within the TWT element to indicate negotiations for wake TBTTs and wake intervals on multiple links (one modified individual TWT parameter set field carries one individual TWT parameter set field and one link ID field as defined in IEEE 802.11ax). The link ID field in each modified individual TWT parameter set field indicates the link where the parameters in the same modified individual TWT parameter set field proposed by the non-AP are set. The target wake time field in the modified individual TWT parameter set field is set based on the TSF on the link indicated in the link ID field of the same modified individual TWT parameter set field.

[0228] When AP1 receives a TWT request (setup) frame from STA3, it determines whether to accept the request. In this example, AP1 accepts the negotiation request and sends a TWT response (setup) frame (596) back to STA3. The format of the TWT response frame may be similar to that shown in FIG. 16, and thus the TWT elements within the frame may be similar to FIG. 28, except that the broadcast TWT parameter set field of FIG. 28 is replaced with individual TWT parameter set fields as defined in IEEE 802.11ax. The negotiation type field within the control field of the modified TWT element is set to a first state (e.g., "1") to indicate that it is a negotiation of the wake TBTT and wake interval. A TWT response frame may carry multiple modified individual TWT parameter set fields in the TWT parameter information field within a modified TWT element to indicate the negotiation of wake TBTTs and wake intervals on multiple links (one modified individual TWT parameter set field carries one individual TWT parameter set field and one link ID field as defined in IEEE 802.11ax). The link ID field within each modified individual TWT parameter set field indicates the parameters within the same modified individual TWT parameter set field set by the AP, and the link to which a non-AP STA is instructed to comply. The target wake time field in the modified individual TWT parameter set field is set based on the TSF on the link indicated in the link ID field of the same modified individual TWT parameter set field.

[0229] The first TBTT on Link 1 (598), set to the Target Wake Time (TWT), indicates the time when STA3 needs to wake (request to wake) to receive a beacon frame (608) from AP1 to determine the start time of the B-TWT5 SP on Link 1. This is set in the Target Wake Time field within the modified individual TWT parameter set field having a Link ID field set to Link 1. The Target Wake Time field can be set to the TSF time on Link 1 (i.e., the TSF time of STA3 and AP1). It will be known that after the TBTT (598), the listening interval (606) for the beacon (B-TWT IE) (608) begins.

[0230] The first TBTT on Link 2 (600), set to the target wake time, indicates the time when STA5 needs to wake (requests to wake) to receive a beacon frame (604) from AP2 to determine the start time of the B-TWT5 SP on Link 2. This is set in the target wake time field of a modified individual TWT parameter set field having a link ID field set to Link 2. The target wake time field can be set to the TSF time on Link 2 (i.e., the TSF time of STA5 and AP2). It will be known that after the TBTT (608), the listening interval (602) for the beacon (B-TWT IE) (604) begins.

[0231] The drawing illustrates an example of a trigger-enabled B-TWT4 SP (610), where AP1 and AP2 acquire channel access and can send trigger frames (612 and 614) (e.g., basic trigger frames or UAPSD triggers) to STA3 and STA5, respectively. Then, STA3 and STA5 send PS-Poll frames (616 and 618) again to indicate that they are awake and ready to receive traffic. Then, AP1 and AP2 send BAs (multi-user BAs or Acks) (620 and 622) for acknowledgment, begin sending DL MU PPDUs (624, 626) to STA3 and STA5, respectively during an R-TWT2 SP, and receive acknowledgments (BAs) (628 and 630) from the APs.

[0232] It should be noted that during the channel time between the trigger frame on the link and the beacons (B-TWT IE), the STA on the link may be in a dormant state, and beacons (632, 634, 636 and 638) are shown as examples.

[0233] FIG. 36 illustrates an exemplary embodiment (650) of an individual TWT setup using modified TWT elements. The figure illustrates communications between STA3 (476) and AP1 (480) on Link 1, and between STA5 (478) and AP2 (482) on Link 2. STA3 and STA5 are part of MLD3 (472), while AP1 and AP2 are part of MLD1 (474).

[0234] As illustrated in the drawing, during the I-TWT setup (652), STA3 transmits a TWT request (setup) frame (654) to AP1 on Link 1 to request individual TWT setups on Link 1 and Link 2. The format of the TWT request frames may be similar to that illustrated in FIG. 16, and thus the modified TWT element within the frame may be as illustrated in FIG. 28, except that the broadcast TWT parameter set field of FIG. 28 is replaced with an individual TWT parameter set field as defined in IEEE 802.11ax. The negotiation type field within the control field of the modified TWT element is set to a second state (e.g., "0") to indicate that it is a negotiation for an individual TWT setup.

[0235] A TWT request frame may carry multiple modified individual TWT parameter set fields in the modified TWT parameter information field within the TWT element to indicate the negotiation of individual TWTs represented as I-TWT6 on multiple links (one modified individual TWT parameter set field carries one individual TWT parameter set field and one link ID field as defined in IEEE 802.11ax). The link ID field in each modified individual TWT parameter set field indicates the link where the parameters in the modified individual TWT parameter set field, identical to those in the non-AP, are proposed. The target wake time field in the modified individual TWT parameter set field is set based on the TSF on the link indicated in the link ID field of the same modified individual TWT parameter set field.

[0236] When AP1 receives a TWT request frame from STA3, it can decide whether to accept the request. In this example, AP1 accepts the negotiation request and sends a TWT response frame (656) back to STA3. The format of the TWT response frame may be similar to that shown in FIG. 16, for example, and thus the TWT elements within the frame may be similar to FIG. 28, except that the broadcast TWT parameter set field of FIG. 28 is replaced with an individual TWT parameter set field as defined in IEEE 802.11ax. The negotiation type field within the control field of the modified TWT element is set to a first state (e.g., "1") to indicate that it is a negotiation of an individual TWT setup. The TWT response frame may also carry multiple modified individual TWT parameter set fields in the TWT parameter information field within the modified TWT element to indicate the negotiation of individual TWT setups on multiple links (one modified individual TWT parameter set field carries one individual TWT parameter set field and one link ID field as defined in IEEE 802.11ax). The link ID field within each modified individual TWT parameter set field indicates the parameters within the same modified individual TWT parameter set field set by the AP and the link that the non-AP STA must follow. The target wake time field in the modified individual TWT parameter set field is set based on the TSF on the link indicated in the link ID field of the same modified individual TWT parameter set field.

[0237] The first TBTT on Link 1 set to the target wake time indicates the time when STA3 needs to wake (requested to wake) for the start of the first I-TWT6 SP on Link 1 (658). This is set in the target wake time field within the modified individual TWT parameter set field having the link ID field set to Link 1. The target wake time field can be set to the TSF time on Link 1 (i.e., the TSF time of STA3 and AP1).

[0238] The first TBTT on Link 2, set to the target wake time, indicates the time when STA5 needs to wake (requests to wake) for the start of the first I-TWT6 SP (660) on Link 2. This is set in the target wake time field of the modified individual TWT parameter set field having the link ID field set to Link 2. The target wake time field can be set to the TSF time on Link 2 (i.e., the TSF time of STA5 and AP2).

[0239] The drawing illustrates an example of an I-TWT6 SP (661) in which AP1 and AP2 can acquire channel access to transmit trigger frames (662 and 664) (e.g., basic trigger frames or U-APSD triggers) to STA3 and STA5, respectively, as illustrated. Then, STA3 and STA5 transmit PS-Poll frames (666 and 668) again to indicate that they are awake and ready to receive traffic. Then, AP1 and AP2 transmit BAs (670 and 672) for acknowledgment and begin transmitting DL PPDUs (674 and 676) to STA3 and STA5, respectively, during an R-TWT2 SP, after which acknowledgments (e.g., BAs) (678 and 680) are received.

[0240] 3.4. Alternative SCS Setup Procedure for R-TWT Membership

[0241] This section introduces an alternative SCS setup procedure for R-TWT membership that is different from Section 3.3.

[0242] This section considers a scenario in which SCS setup involves multi-link (ML) operations, whereas R-TWT setup is a link-level operation. Therefore, the setup procedure of SCS (i.e., SCS setup frame exchange) can occur over any number of links, whereas the setup procedure of R-TWT (i.e., R-TWT setup frame exchange) can occur only over the links where R-TWT is scheduled.

[0243] 3.4.1. Operation of the Alternative SCS Setup Procedure

[0244] FIGS. 37 and 38 show an exemplary embodiment (710) of a non-AP MLD that transmits an SCS request frame and indicates that R-TWT scheduling is required (requested) for the SCS within the frame.

[0245] In FIG. 37, the non-AP MLD sends a frame to the AP MLD to set up the SCS (712) and indicates that R-TWT scheduling is required (requested) for the SCS in the frame.

[0246] Next, in block (714), it is determined whether the non-AP MLD received a frame indicating that the AP MLD accepts the SCS request. If the SCS request is not accepted, the SCS setup failed in block (718), and the process terminates.

[0247] Otherwise, if the SCS setup is accepted, the SCS is successfully established in block (716), and the non-AP MLD waits for a response from the AP MLD to assign R-TWT membership on any enabled links (links where the non-AP MLD is associated with the AP MLD). It should be noted that when the non-AP MLD waits for a response regarding the R-TWT membership of the SCS, it does not send an R-TWT request frame for the SCS on any link.

[0248] After that, in the check (720) of Fig. 38, a determination is made as to whether the STA associated with the non-AP MLD has received a frame indicating that the AP MLD accepts the membership of the R-TWT.

[0249] If the condition is not satisfied, the non-AP MLD in block (722) may transmit an R-TWT membership request frame or another SCS request frame (along with the R-TWT request) for the SCS traffic stream. Thus, if the AP MLD accepts the SCS request but the non-AP MLD does not receive a frame assigning the R-TWT membership before the timeout, the non-AP MLD may transmit an R-TWT membership request for the SCS or retransmit the SCS request frame for the SCS traffic stream. It should be noted that in some cases, the non-AP MLD may retransmit the SCS request frame over a different link. Additionally, if the non-AP MLD does not receive a frame indicating that the AP MLD accepts the SCS request (within the timeout), the SCS setup has failed. The non-AP MLD may retransmit the SCS request frame for the SCS traffic stream according to the current SCS setup rule.

[0250] Otherwise, if an R-TWT membership is accepted as determined in block (720), the STA becomes a member STA of the R-TWT (724), and frames from the SCS traffic streams will be allowed to be transmitted or prioritized to be transmitted during the SPs of the R-TWT. It should be noted that in at least one embodiment / mode / case, the AP MLD assigns memberships of multiple R-TWTs for the same SCS traffic stream. In at least one embodiment / mode / case, multiple R-TWTs for the same SCS traffic stream may be scheduled on different links.

[0251] It should also be noted that in at least one embodiment / mode / case, the frame exchange of the SCS setup procedure is transmitted, for example, through Link 1, while the frames assigning R-TWT membership are transmitted through links other than Link 1, such as Link 2, Link 3, etc.

[0252] FIG. 39 illustrates an exemplary embodiment (750) of an AP MLD that transmits an SCS response frame and assigns membership to the SCS.

[0253] The AP MLD receives a request frame from the non-AP MLD to set up an SCS traffic stream (752). In the frame, it requests that an R-TWT be scheduled for the SCS traffic stream.

[0254] In check (754), it is determined whether the AP MLD has accepted the SCS request. If the AP MLD has not accepted the SCS request, in block (756), the AP MLD generates an SCS response frame rejecting the SCS request. It should be noted that one reason the AP MLD might reject the SCS could be that the AP MLD is unable to schedule R-TWT SPs on any of the links for the SCS traffic stream. The AP MLD may indicate the reason for the rejection in the SCS response frame. For example, this reason may be indicated in the status field, as illustrated in FIG. 14.

[0255] Otherwise, if the condition in check (754) is satisfied, the AP MLD accepts the SCS request from the non-AP MLD by responding with an SCS response frame (758). Then, the AP MLD transmits a frame (760) to assign R-TWT memberships on at least one link for the SCS traffic stream within a timeout interval. In at least one embodiment / mode / case, the frame format for assigning R-TWT memberships may be the same as in IEEE 802.11be (as shown in FIG. 16), thereby allowing TWT elements to be replaced using a modified format as shown in FIG. 41. It should be noted that in certain cases, the AP MLD may assign memberships of multiple R-TWTs for the same SCS traffic stream. In certain cases, it is also permissible for multiple R-TWTs for the same SCS traffic stream to be scheduled on different links.

[0256] 3.4.2. SCS descriptors with R-TWT frame format

[0257] FIG. 40 shows an exemplary embodiment (770) of an SCS descriptor element having an R-TWT request field within a QoS characteristic element. The fields within the SCS descriptor element may be identical to the fields of IEEE 802.11be [P802.11be_D1.31], except that they have one field, such as an R-TWT request field indicating whether an R-TWT is required for an SCS traffic stream.

[0258] The QoS characteristic element field may be identical to that defined in IEEE 802.11be, except that at least a new R-TWT request field is added to this element. The R-TWT request field may be in the control information field of the QoS characteristic element.

[0259] The R-TWT request field is set by the non-AP MLD to indicate whether R-TWT scheduling is required for the transmission of frames from the SCS traffic stream. This field may contain a 1-bit indication. If this field is set to a first state (e.g., "1"), the non-AP MLD requests that R-TWT SPs be scheduled for the transmission of the SCS traffic stream. If the AP MLD receiving this field accepts the SCS request, it sends an unsolicited TWT response frame(s) to the non-AP MLD to allocate R-TWT membership for the transmission of at least one SCS traffic stream over the link within a timeout period, which aims to satisfy the QoS requirements of the SCS traffic stream. It should be noted that the timeout may be predetermined or negotiated by the AP and non-AP MLDs. Otherwise, this field is set to a second state (e.g., "0"), and the AP MLD does not need to schedule R-TWT SPs for the SCS traffic stream. If a non-AP MLD needs to schedule an R-TWT SP for an SCS traffic stream (or decides to schedule one), it initiates R-TWT membership negotiations with the AP MLD over the link.

[0260] FIG. 41 illustrates an exemplary embodiment (790) of the data field diagram of the modified TWT element illustrated in FIG. 40. All fields within the modified TWT element may be identical to those within the TWT element illustrated in FIG. 5, except that an SCSID field is added to each (modified) broadcast TWT parameter set field. The AP sets this field to indicate that the R-TWT scheduling indicated in the modified broadcast TWT parameter set field is for the transmission of the SCS traffic stream indicated in the SCSID field. If the AP sets the modified broadcast TWT parameter set field to accept membership from non-AP STAs, the SCS traffic stream indicated in the non-AP STA's SCSID field is given a higher priority to be transmitted during the R-TWT SPs indicated in the modified broadcast TWT parameter set field.

[0261] 3.4.3. Examples of SCS setups requesting R-TWT scheduling

[0262] This section presents several examples of SCS setup procedures requesting R-TWT scheduling.

[0263] FIG. 42 illustrates an exemplary embodiment (810) of an SCS setup procedure requesting R-TWT scheduling in an example of AP1 scheduling R-TWT SPs for an SCSx traffic stream on Link 1. The figure illustrates communications between STA3 (813a) and AP1 (841a) on Link 1, and between STA5 (813b) and AP2 (841b) on Link 2. STA3 and STA5 are part of MLD3 (812), while AP1 and AP2 are part of MLD1 (840).

[0264] MLD3 sets up an SCS traffic stream, denoted as SCSx, with MLD1. In this example, SCSx is a DL traffic stream. STA3 associated with MLD3 acquires channel access and initiates an SCS setup procedure (814) with AP1 associated with MLD1. STA3 sends an SCS request frame (816) to AP1 to set up the SCSx traffic stream. The format of the SCS request frame may be as shown in FIG. 11, where the SCS descriptor list field carries the SCS descriptor element shown in FIG. 40. The SCS descriptor element includes an indication that an R-TWT is required (requested) for the transmission of the SCSx traffic stream.

[0265] After receiving an SCS request frame for SCSx, AP1 decides (determines) to respond with an SCS response frame (818) to accept the SCSx traffic stream. Once the SCSx traffic stream is successfully established (820), MLD3 begins counting down its backoff (BO) timer (822) and waits for an R-TWT response frame from MLD1 to allocate R-TWT membership to the SCSx traffic stream before the timeout.

[0266] In this example, MLD1 decides to assign membership to an R-TWT, denoted as R-TWTy, on Link 1 for the SCSx traffic stream. Then, AP1 associated with MLD1 transmits a non-request TWT response frame (i.e., a TWT setup frame) (824) to assign / accept the R-TWTy membership of STA3. The frame format of the TWT response frame may be as shown in FIG. 16, carrying modified TWT elements, as shown in FIG. 41. The SCSID subfield within the modified broadcast TWT parameter set field accepting the membership of R-TWTy must be set to the SCS ID of the SCSx to indicate that this R-TWTy membership is for the SCSx.

[0267] Next, STA3 becomes a member (826) STA of the R-TWTy and waits for a first R-TWTy SP (832) with a higher priority to allow or transmit frames of the SCSx traffic stream (828). As illustrated in the drawing, AP1 transmits PPDUs (830, 836) of the SCSx traffic stream during the R-TWTy SP on Link 1, and STA3 responds with acknowledgments (BAs) (834 and 838).

[0268] FIG. 43 illustrates an exemplary embodiment (850) for scheduling R-TWT SPs for SCSx traffic streams on different links. The figure illustrates communications between STA3 (813a) and AP1 (841a) on Link 1, and between STA5 (813b) and AP2 (841b) on Link 2. STA3 and STA5 are part of MLD3 (812), while AP1 and AP2 are part of MLD1 (840).

[0269] Compared to Fig. 42, in this example, the SCSx traffic stream is a UL traffic stream, and the SCS setup procedure for SCSx occurs on Link 2, whereas the AP membership assignment for R-TWTy occurs on Link 1.

[0270] MLD3 sets up an SCS traffic stream, denoted as SCSx, with MLD1. In this example, SCSx is a UL traffic stream. STA5 associated with MLD3 obtains channel access and initiates an SCS setup procedure (852) with AP2 associated with MLD1 on Link 2. STA5 sets up the SCSx traffic stream by sending an SCS request frame (854) to AP2. The format of the SCS request frame may be as shown in FIG. 11, in which the SCS descriptor list field carries the SCS descriptor element shown in FIG. 40. The SCS descriptor element contains an indication that an R-TWT is required (requested) for the transmission of the SCSx traffic stream.

[0271] After receiving an SCS request frame for SCSx, AP2 decides to respond with an SCS response frame (856) to accept the SCSx traffic stream. The SCSx traffic stream is successfully established (858), and MLD3 begins waiting for an R-TWT response frame (862) from MLD1 to allocate R-TWT membership to the SCSx traffic stream before the timeout.

[0272] In this example, MLD1 decides to assign membership to an R-TWT, denoted as R-TWTy, on Link 1 for an SCSx traffic stream. Then, AP1 associated with MLD1 contests for the channel (860) and transmits a non-request TWT response frame (i.e., a TWT setup frame) (862) to assign / accept the R-TWTy membership of STA3. The frame format of the TWT response frame may be as shown in FIG. 16, carrying modified TWT elements as shown in FIG. 41. The SCSID subfield within the modified broadcast TWT parameter set field for accepting the R-TWTy membership must be set to the SCS ID of the SCSx to indicate that this R-TWTy membership is for the SCSx.

[0273] Next, STA3 becomes a member STA of R-TWTy (864) and waits for an R-TWTy SP (868) to which the transmission of frames of the SCSx traffic stream is allowed or given a higher priority to transmit (866). As illustrated in the drawing, AP1 triggers the transmission of PPDUs (872) of the SCSx traffic stream during the R-TWTy SP on Link 1 (870).

[0274] FIG. 44 illustrates an exemplary embodiment (890) of MLD1 for scheduling R-TWT SPs for SCSx traffic streams on multiple links. The figure illustrates communications between STA3 (813a) and AP1 (841a) on Link 1, and between STA5 (813b) and AP2 (841b) on Link 2. STA3 and STA5 are part of MLD3 (812), while AP1 and AP2 are part of MLD1 (840).

[0275] Compared to Fig. 43, in this example, the SCSx traffic stream is a P2P traffic stream, and the SCS setup procedure of SCSx occurs on Link 2, while the AP assigns memberships of R-TWTy and R-TWTz on Link 1 and Link 2, respectively.

[0276] MLD3 sets up an SCS traffic stream (892) designated as SCSx with MLD1. In this example, SCSx is a P2P traffic stream. STA5 associated with MLD3 obtains channel access and initiates an SCS setup procedure with AP2 associated with MLD1 on Link 2. Specifically, STA5 sends an SCS request frame (894) to AP2 to set up the SCSx traffic stream. The format of the SCS request frame may be as shown in FIG. 11, where the SCS descriptor list field carries the SCS descriptor element shown in FIG. 40. The SCS descriptor element contains an indication that an R-TWT is required (requested) for the transmission of the SCSx traffic stream.

[0277] After receiving an SCS request frame for SCSx, AP2 decides to respond with an SCS response frame (896) to accept the SCSx traffic stream. The SCSx traffic stream is successfully established (898), and AP2 begins waiting for an R-TWT response frame from MLD1 to allocate R-TWT membership to the SCSx traffic stream before the timeout.

[0278] In this example, MLD1 decides to assign memberships of two R-TWTs, denoted as R-TWTy and R-TWTz, on Link 1 and Link 2, respectively, for the SCSx traffic stream. Then, AP1 associated with MLD1 starts counting down the backoff timer (900) and sends an unsolicited TWT response frame (i.e., TWT setup frame) to assign / accept R-TWTy membership (904) of STA3 over Link 1. Meanwhile, AP2 associated with MLD1 counts down the backoff timers (902) and sends an unsolicited TWT response frame (i.e., TWT setup frame) (906) to assign / accept R-TWTy membership of STA5 over Link 2.

[0279] The frame format of the TWT response frame may be the same as that shown in FIG. 16, which carries the modified TWT element as shown in FIG. 41. The SCSID subfield within the modified broadcast TWT parameter set field for accepting membership of R-TWTy (or R-TWTz) must be set to the SCS ID of SCSx to indicate that this R-TWTy (or R-TWTz, respectively) membership is for SCSx.

[0280] After that, STA3 becomes a member STA of the R-TWTy (908) on Link 1. During the R-TWTy SPs, frames of the SCSx traffic stream will be allowed to be transmitted or will have a higher priority to be transmitted. As illustrated in the drawing, after an interval (912), AP1 transmits a MU-RTS TXS trigger frame (as defined in IEEE 802.11be) (916) to share a TXOP with STA3, and STA3 begins the transmission of PPDUs (920) of the SCSx traffic stream after a response CTS (918) during the R-TWTy SP on Link 1.

[0281] STA5 becomes a member STA of the R-TWTz (910) on Link 2. During the R-TWTz SP, after the period (914), frames of the SCSx traffic stream will be allowed to be transmitted or will have a higher priority to be transmitted. As illustrated in the drawing, AP2 transmits a MU-RTS TXS trigger frame (922) to share a TXOP with STA5, and STA5 initiates the transmission of PPDUs (926) of the SCSx traffic stream after the response CTS (922) during the R-TWTz SP on Link 1.

[0282] It should be noted that a P2P (or DL / UL) SCS traffic stream may indicate that the SCS traffic stream can be transmitted only through specific links due to the link ID field (or link bitmap field) within the control information field of the SCS traffic stream's QoS attribute element (or TID to link mapping). In the case of P2P, the SCS traffic stream can be transmitted only through its tunneled Direct-Link Setup (TDLS) links. Next, the AP MLD can schedule only R-TWT SPs for the transmission of the SCS traffic stream through these specific links.

[0283] FIG. 45 illustrates an exemplary embodiment (950) of MLD3 that does not receive R-TWT membership for SCSx before a timeout. The figure illustrates communications between STA3 (813a) and AP1 (841a) on Link 1, and between STA5 (813b) and AP2 (841b) on Link 2. STA3 and STA5 are part of MLD3 (812), while AP1 and AP2 are part of MLD1 (840).

[0284] MLD3 sets up an SCS traffic stream, denoted as SCSx, with MLD1. In this example, SCSx is a UL traffic stream. STA5 associated with MLD3 obtains channel access and initiates an SCS setup procedure (952) with AP2 associated with MLD1 on Link 2. STA5 sets up the SCSx traffic stream by sending an SCS request frame (954) to AP2. The format of the SCS request frame may be as shown in FIG. 11, where the SCS descriptor list field carries the SCS descriptor element shown in FIG. 40. The SCS descriptor element includes an indication that an R-TWT is required (requested) for the transmission of the SCSx traffic stream.

[0285] After receiving an SCS request frame for SCSx, AP2 decides to respond and sends an SCS response frame (955) to accept the SCSx traffic stream. The SCSx traffic stream is successfully established (956), and AP2 waits for an R-TWT response frame from MLD1 to assign R-TWT membership to SCSx (958). The R-TWT response is not received by MLD3 within a set timeout period (958) (960).

[0286] After the timeout (958), MLD3 begins counting down the BO timer (962) and resumes the SCS setup procedure for the SCSx traffic stream. The resumption can be performed on any link. In this example, the resumption occurs on Link 1 along with another SCS setup process (964), and STA3 sends an SCS request (966) to which an SCS response (968) is received.

[0287] 4. General scope of the embodiments

[0288] Embodiments of the present technology may be described herein with reference to flowchart examples of methods and systems according to embodiments of the technology, and / or procedures, algorithms, steps, actions, formulas, or other computational descriptions that may also be implemented as computer program products. In this regard, any procedure, algorithm, step, action, formula, or computational description, as well as each block or step of a flowchart and combinations of blocks (and / or steps) in a flowchart, may be implemented by various means such as hardware, firmware, and / or software comprising one or more computer program instructions implemented in computer-readable program code. As can be understood, any such computer program instructions may be executed, without limitation, by one or more computer processors, including general-purpose computers or special-purpose computers, or other programmable processing units that make up the machine, so as to produce means for computer program instructions executed on the computer processor(s) or other programmable processing units to implement specified function(s).

[0289] Accordingly, blocks of flowcharts and the procedures, algorithms, steps, actions, formulas, or computational descriptions described herein support combinations of means for performing specified function(s), combinations of steps for performing specified function(s), and computer program instructions such as those implemented by computer-readable program code logic means for performing specified function(s). It will also be understood that any procedures, algorithms, steps, actions, formulas, or computational descriptions and combinations thereof described herein, as well as each block of the flowchart examples, may be implemented by special-purpose hardware-based computer systems for performing specified function(s) or step(s), or by combinations of special-purpose hardware and computer-readable program code.

[0290] Additionally, these computer program instructions, such as those implemented in computer-readable program code, may also be stored in one or more computer-readable memories or memory devices capable of instructing a computer processor or other programmable processing unit to function in a specific manner, so that the instructions stored in the computer-readable memories or memory devices produce an article of manufacture comprising instruction means for implementing a function specified in the block(s) of the flowchart(s). The computer program instructions may also be executed by a computer processor or other programmable processing unit, so that a series of operational steps are performed on the computer processor or other programmable processing unit, thereby producing a process implemented by a computer such that the instructions executed on the computer processor or other programmable processing unit provide steps for implementing the functions specified in the block(s) of the flowchart(s), procedure(s), algorithm(s), step(s), operation(s), formula(s), or computational description(s).

[0291] It will also be understood that the terms “programming” or “programmable” as used herein refer to one or more instructions that can be executed by one or more computer processors to perform one or more functions as described herein. Instructions may be implemented as software, as firmware, or as a combination of software and firmware. Instructions may be stored locally on non-transient media on the device, or stored remotely, such as on a server, or all or part of the instructions may be stored locally and remotely. Remotely stored instructions may be automatically downloaded (pushed) to the device by user initiation or based on one or more arguments.

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

[0293] From the description in this specification, it will be understood that the present disclosure includes a number of implementations of the technology, including but not limited to the following:

[0294] A device for wireless communication in a network, comprising: (a) a wireless communication circuit that operates as a regular STA or an access point (AP) STA to communicate wirelessly with other radio stations (STAs) using a carrier sensing multiple access / collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN), as a radio station (STA) that is a separate STA or as a STA within a multi-link device (MLD); (b) a processor coupled to the wireless communication circuit to operate on the WLAN; (c) includes a non-transient memory for storing instructions executable by a processor to communicate with other STAs, and (d) the instructions, when executed by the processor, perform steps of a wireless communication protocol for a wireless communication circuit, and the steps of the wireless communication protocol include: (d)(i) transmitting a Stream Classification Service (SCS) request frame to an AP station by a STA acting as a non-AP STA to initiate an SCS setup in addition to scheduling a reserved Limited Target Wait Time (R-TWT) - the SCS request frame includes a Traffic Specification (TSPEC) element or a QoS characteristic element -; (d)(ii) receiving an SCS request frame from a non-AP STA - whereby the AP determines whether to accept the request -; (d)(iii) transmitting an SCS response frame by the AP to the non-AP STA indicating the decision on the request; and (d)(iv) a step of scheduling SCS traffic to be transmitted with increased priority by AP and non-AP STA during R-TWT service periods (SPs) when the request is accepted - SCS traffic is selected from a group of communication traffic consisting of downlink (DL), uplink (UL), and peer-to-peer (P2P) -

[0295] A device for wireless communication in a network, comprising: (a) a wireless communication circuit that operates as a regular STA or an access point (AP) STA to communicate wirelessly with other radio stations (STAs) using a carrier sensing multiple access / collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN), and as a radio station (STA) that is a separate STA or as a STA within a multi-link device (MLD); (b) a processor coupled to the wireless communication circuit to operate on the WLAN; (c) a non-transient memory that stores instructions executable by the processor to communicate with other STAs; and (d) the instructions, when executed by the processor, perform steps of a wireless communication protocol for the wireless communication circuit, wherein the steps of the wireless communication protocol include: (d)(i) a step of indicating a link on which the modified TWT parameter set field is set using a TWT parameter set field that incorporates a link identification (ID) field into a target latency (TWT) element; (d)(ii) a non-AP STA transmitting a TWT setup frame to the AP in a modified TWT parameter set field within a TWT element on one link to initiate a TWT setup process on multiple links by the AP; (d)(iii) the AP transmitting a TWT response frame using the modified TWT parameter set field within a TWT element on one link to indicate its decision on the request; and (d)(iv) the non-AP STA receiving the decision from the AP in the TWT setup frame and performing TWT scheduling for frame exchange with the AP as directed by the AP.

[0296] A device for wireless communication in a network, comprising: (a) a wireless communication circuit that operates as a regular STA or an access point (AP) STA to communicate wirelessly with other radio stations (STAs) using a carrier sensing multiple access / collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN), and as a radio station (STA) that is a separate STA or as a STA within a multi-link device (MLD); (b) a processor coupled to the wireless communication circuit to operate on the WLAN; (c) a non-transient memory that stores instructions executable by the processor to communicate with other STAs; and (d) the instructions, when executed by the processor, perform steps of a wireless communication protocol for the wireless communication circuit, wherein the steps of the wireless communication protocol include: (d)(i) initiating an SCS setup in addition to scheduling a limited target wait time (R-TWT) for the SCS by transmitting a stream classification service (SCS) request frame containing QoS characteristic elements to an AP station by a non-AP STA; (d)(ii) receiving an SCS request frame from a non-AP STA, wherein the AP determines whether to accept the request; (d)(iii) sending an SCS response frame by the AP to the non-AP STA indicating the decision regarding the request; (d)(iv) if the SCS response frame accepts the SCS request, sending a TWT response frame by the AP to allocate an R-TWT membership to schedule the transmission of SCS traffic during corresponding R-TWT service periods (SPs); and (d)(v) if the request is accepted, scheduling the transmission of SCS traffic by the AP and the non-AP STA to be sent with increased priority during corresponding R-TWT SPs.

[0297] A device for wireless communication in a network, comprising: (a) a wireless communication circuit that operates as a regular STA or an access point (AP) STA to communicate wirelessly with other radio stations (STAs) using a carrier sensing multiple access / collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN), and as a radio station (STA) that is a separate STA or as a STA within a multi-link device (MLD); (b) a processor coupled to the wireless communication circuit to operate on the WLAN; (c) a non-transient memory that stores instructions executable by the processor to communicate with other STAs; and (d) the instructions, when executed by the processor, perform steps of a wireless communication protocol for the wireless communication circuit, wherein the steps of the wireless communication protocol include: (d)(i) initiating an SCS setup in addition to scheduling transmissions for the SCS by transmitting a stream classification service (SCS) request frame containing QoS characteristic elements to an AP station by a non-AP STA; (d)(ii) receiving an SCS request frame from a non-AP STA, wherein the AP determines whether to accept the request; (d)(iii) sending an SCS response frame by the AP to the non-AP STA indicating the decision on the request; and (d)(iv) scheduling SCS traffic to be transmitted by the AP and the non-AP STA if the SCS request is accepted.

[0298] A wireless communication device / method for performing transmission of packets to which CSMA / CA is applied in a system / device, comprising: (a) a non-AP STA transmitting an SCS request frame to initiate SCS setup and R-TWT setup with an AP; (b) an AP transmitting an SCS response frame to indicate its decision regarding the request; and (c) SCS traffic being scheduled to be transmitted during R-TWT SPs in which the request is accepted.

[0299] In any preceding implementation device or method, the R-TWT SP is trigger-enabled.

[0300] In any preceding implementation device or method, the non-AP transmits an SCS request frame containing TWT elements to request an R-TWT setup for the SCS.

[0301] In any preceding device or method of implementation, the AP transmits an SCS response frame containing TWT elements to indicate the results of the R-TWT setup for the SCS.

[0302] In any preceding device or method of implementation, the total R-TWT SP time per second scheduled by the AP is not allowed to exceed what is required by the traffic to be transmitted or prioritized during the R-TWT SPs.

[0303] In any preceding implementation device or method, the AP scheduling the R-TWT can set an interval between two consecutive R-TWT SPs for the SCS traffic stream between the minimum service interval and the maximum service interval of the SCS traffic stream.

[0304] In any preceding device or method of implementation, the parameters of the modified TWT parameter set are set based on the timing synchronization function (TSF) time value on the link indicated in the link identification (ID) field.

[0305] In any preceding device or method of implementation, a TWT setup frame carries a TWT element, and thus a plurality of modified TWT parameter set fields within the TWT element have the same TWT ID but have different link IDs to indicate TWTs on which the SPs are scheduled on different links.

[0306] In any preceding device or method of implementation, a TWT setup frame carries a plurality of TWT elements, and thereby the parameters within the modified TWT parameter set fields for the same TWT and the links within different TWT elements represent the range of parameters for that TWT on the links.

[0307] In any preceding implementation device or method, the TWT response frame may be transmitted by the AP MLD on any link where the R-TWT SP is scheduled for the SCS traffic stream.

[0308] In any preceding implementation device or method, the TWT response frame can be transmitted by the AP MLD within a timeout.

[0309] In any preceding implementation device or method, the non-AP MLD must not transmit a TWT request frame for the SCS traffic stream within a timeout after the SCS traffic stream requesting R-TWT scheduling has been successfully established.

[0310] In any preceding device or method of implementation, if the non-AP MLD does not receive a TWT response frame for the SCS traffic stream within a timeout after the SCS traffic stream requesting R-TWT scheduling has been successfully established, it retransmits the SCS request frame.

[0311] In any preceding device or method of implementation, if the non-AP MLD does not receive a TWT response frame for the SCS traffic stream within a timeout after the SCS traffic stream requesting R-TWT scheduling has been successfully established, it transmits a TWT request frame for the SCS traffic stream.

[0312] In any preceding implementation device or method, the AP MLD schedules R-TWT SPs to transmit SCS traffic streams.

[0313] In any preceding device or method of implementation, the AP MLD triggers the transmission of an uplink (UL) or peer-to-peer (P2P) SCS traffic stream in a time interval of which the length is set between the minimum service interval and the maximum service interval of the SCS traffic stream.

[0314] In any preceding implementation device or method, a non-AP requesting an SCS setup may set all fields of the TSPEC element within the frame to request the SCS.

[0315] In any preceding device or method of implementation, a non-AP requesting an SCS setup for UL traffic may set the redundant bandwidth allow field of the TSPEC element within the frame to request the SCS.

[0316] In any preceding device or method of implementation, a non-AP requesting an SCS setup for DL ​​traffic may reserve a redundant bandwidth allowance field of the TSPEC element within the frame to request the SCS.

[0317] In any preceding device or method of implementation, an AP requesting an SCS setup may reserve an intermediate time field of a TSPEC element within a frame to request the SCS.

[0318] In any preceding device or method of implementation, the AP may set the intermediate time field of the TSPEC element within the frame to accept the SCS.

[0319] In any preceding implementation device or method, the non-AP may transmit an SCS request frame containing TWT elements to request an R-TWT setup for the SCS.

[0320] In any preceding implementation device or method, the non-AP may transmit an SCS response frame containing TWT elements to indicate the results of the R-TWT setup for the SCS.

[0321] In any preceding implementation device or method, the AP scheduling R-TWT may schedule additional R-TWT SP time when a new SCS is established.

[0322] In any preceding implementation device or method, the AP scheduling R-TWT can reduce the R-TWT SP time when the existing SCS is removed.

[0323] In any preceding implementation device or method, the AP scheduling the R-TWT can update the R-TWT SP time when the existing SCS changes.

[0324] In any preceding device or method of implementation, the total R-TWT SP time per second scheduled by the AP cannot exceed an upper limit.

[0325] In any preceding device or method of implementation, the AP scheduling the R-TWT may set an interval between two consecutive R-TWT SPs longer than the maximum value of all minimum SI fields of the TSPECs of the SCSs scheduled to transmit the traffic during the R-TWT SPs.

[0326] In the system / device described in paragraph 1, the AP scheduling the R-TWT may set the interval between two consecutive R-TWT SPs to be shorter than the minimum value of all maximum SI fields of the TSPECs of the SCSs scheduled to transmit the traffic during the R-TWT SPs.

[0327] In any preceding device or method of implementation, the AP scheduling the R-TWT can set the interval between two consecutive R-TWT SPs to a divisor of the beacon interval.

[0328] In any preceding implementation device or method, an AP scheduling an R-TWT can set the R-TWT ID to a unique value at the MLD level when the AP is associated with an MLD.

[0329] In any preceding implementation device or method, the AP scheduling the R-TWT sets the R-TWT ID to a unique value at the STA level and the tuple<R-TWT ID, 링크 ID> R-TWT can be identified at the MLD level using this.

[0330] In any preceding device or method of implementation, the AP scheduling the R-TWT may set an interval between two consecutive R-TWT SPs between the maximum SI fields and the minimum SI fields of the TSPEC of the SCS that is scheduled to transmit the traffic during the R-TWT SPs.

[0331] Each and all implementations of the technology described herein, as well as any aspect, component, or element of any embodiment described herein, and any combination of aspects, components, or elements of any embodiment described herein.

[0332] As used herein, the term “implementation” is intended to include, without limitation, embodiments, examples, or other forms of practicing the technology described herein.

[0333] As used herein, singular terms (“a,” “an,” and “the”) may include multiple referents unless the context clearly indicates otherwise. Unless explicitly stated otherwise, a reference to a singular object is not intended to mean “one and only one,” but rather “one or more.”

[0334] Syntactic constructions such as "A, B and / or C" describe, within the disclosure, places where A, B, or C may exist, or any combination of items A, B, and C. Enumerating a group of elements followed by syntactic constructions such as "at least one of" indicates that at least one of such group elements is present, which, where applicable, includes any possible combination of the enumerated elements.

[0335] References in this disclosure referring to the words “Example,” “at least one Example,” or similar Example indicate that a specific feature, structure, or characteristic described in relation to the described Example is included in at least one Example of this disclosure. Accordingly, these various Example phrases do not necessarily refer to the same Example or to a specific Example that is different from all other Examples described. An Example phrase should be interpreted to mean that the specific features, structures, or characteristics of a given Example may be combined in any suitable manner in one or more Examples of the disclosed Device, System, or Method.

[0336] As used herein, the term "set" refers to a collection of one or more objects. Accordingly, for example, a set of objects may include a single object or a number of objects.

[0337] Relational terms such as first and second, top and bottom, etc., may be used solely to distinguish one entity or action from another entity or action and do not necessarily require or imply any actual such relationship or order between these entities or actions.

[0338] The terms “comprises,” “comprising,” “has,” “having,” “includes,” “including,” “contains,” “containing,” or any other variation thereof are intended to cover non-exclusive inclusion, and thus a process, method, article, or device that comprizes, has, includes, or contains a list of elements may not only include these elements but may also include other elements that are not explicitly enumerated or are unique to such process, method, article, or device. An element preceded by “comprises...a,” “has...a,” “includes...a,” or “contains...a” does not, without further restriction, exclude the existence of additional identical elements in the process, method, article, or device that comprizes, has, includes, or contains the element.

[0339] As used herein, the terms “approximately,” “approximate,” “substantially,” “essentially,” and “about,” or any other versions thereof, are used to describe and consider minor variations. When used with events or situations, the terms may refer to cases where the event or situation occurs exactly as it is, as well as cases where the event or situation occurs as a close approximation. When used with numerical values, the terms may refer to a range of variation of the numerical value of ±10% or less, such as ±5% or less, ±4% or less, ±3% or less, ±2% or less, ±1% or less, ±0.5% or less, ±0.1% or less, or ±0.05% or less. For example, "substantially" aligned may refer to a range of angle variation of ±10° or less, such as ±5° or less, ±4° or less, ±3° or less, ±2° or less, ±1° or less, ±0.5° or less, ±0.1° or less, or ±0.05° or less.

[0340] Additionally, quantities, ratios, and other numeric values ​​may occasionally be presented in the specification in a range format. It should be understood that such range formats are used for convenience and brevity and should be flexibly understood to include not only numeric values ​​explicitly specified as limits of the range, but also all individual numeric values ​​or sub-ranges included within the range, as each numeric value and sub-range is explicitly specified. For example, ratios within the range of about 1 to about 200 should be understood to include not only the explicitly stated limits of about 1 and about 200, but also individual ratios such as about 2, about 3, and about 4, and sub-ranges such as about 10 to about 50, about 20 to about 100, etc.

[0341] The term “combined” as used herein is defined as being connected, although not necessarily directly or mechanically. A device or structure “configured” in a particular way is configured at least in that way, but may also be configured in ways not listed.

[0342] Benefits, advantages, solutions to problems, and any element(s) that may cause or make more prominent any benefit, advantage, or solution occur shall not be interpreted as important, required, or essential features or elements of the technology or any or all claims described herein.

[0343] Additionally, in the foregoing disclosure, various features may be grouped together in various embodiments for the purpose of simplifying the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed embodiments require more features than explicitly stated in each claim. The subject matter of the invention may be less than all the features of a single disclosed embodiment.

[0344] The summary of the present disclosure is provided to enable the reader to quickly ascertain the essence of the technical disclosure. It is submitted under the understanding that it is not to be used to interpret or limit the scope or meaning of the claims.

[0345] It will be understood that the practice of some jurisdictions may require the deletion of one or more parts of the present disclosure after the application has been filed. Accordingly, the reader should refer to the filed application for the original content of the present disclosure. Any deletion of the content of the present disclosure shall not be construed as a disclaimer, forfeiture, or dedication to the public of any subject matter of the present application as originally filed.

[0346] The following claims are thereby incorporated into the present disclosure, and each claim is independent as a subject matter claimed individually.

[0347] Although the description in this specification includes many details, they should not be interpreted as limiting the scope of the disclosure and merely provide examples of some of the currently preferred embodiments. Accordingly, it will be understood that the scope of the disclosure fully includes other embodiments that will be apparent to those skilled in the art.

[0348] All structural and functional equivalents to the elements of the disclosed embodiments known to a person skilled in the art are expressly incorporated herein by reference and are intended to be incorporated by the claims. Furthermore, no element, component, or method step of the disclosure is intended to be made available to the public, regardless of whether such element, component, or method step is explicitly cited in the claims. No claim element in the specification shall be interpreted as a "means plus function" element unless explicitly enumerated using the phrase "means for." No claim element in the specification shall be interpreted as a "step plus function" element unless explicitly enumerated using the phrase "step for."

[0349]

[0350]

Claims

Claim 1 A device for wireless communication in a network, comprising: (a) a wireless communication circuit that operates as a regular STA or an access point (AP) STA to communicate wirelessly with other radio stations (STAs) using a carrier sensing multiple access / collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN), and as a radio station (STA) that is a separate STA or as a STA within a multi-link device (MLD); (b) a processor coupled to the wireless communication circuit to operate on the WLAN; (c) a non-transient memory that stores instructions executable by the processor to communicate with other STAs; and (d) the instructions, when executed by the processor, perform steps of a wireless communication protocol for the wireless communication circuit, wherein the steps of the wireless communication protocol include: (i) a stream classification service (SCS) request frame by a STA operating as a non-AP STA to initiate SCS setup in addition to scheduling a reserved restricted target wait time (R-TWT) to the AP A device comprising: (ii) a step of transmitting to a station—wherein the SCS request frame includes a Traffic Specification (TSPEC) element or a QoS characteristic element—; (iii) a step of receiving the SCS request frame from the non-AP STA—wherein the AP determines whether to accept the request—; (iii) a step of transmitting an SCS response frame by the AP to the non-AP STA indicating the decision regarding the request; and (iv) a step of scheduling, by the AP and the non-AP STA, during R-TWT service periods (SPs) if the request is accepted, for the SCS traffic to be transmitted with a transmission priority that precedes the transmission priority of the non-SCS traffic—wherein the SCS traffic is selected from a group of communication traffic consisting of downlink (DL), uplink (UL), and peer-to-peer (P2P). Claim 2 In paragraph 1, the R-TWT SP is a device that is trigger-enabled. Claim 3 In claim 1, the non-AP is a device that transmits the SCS request frame containing TWT elements to request an R-TWT setup for the SCS. Claim 4 In claim 1, the device, wherein the AP transmits an SCS response frame containing TWT elements to display the results of the R-TWT setup for the SCS. Claim 5 A device according to claim 1, wherein the total R-TWT SP time per second scheduled by the AP is not allowed to exceed what is required by the traffic to be transmitted or prioritized during the R-TWT SPs. Claim 6 In claim 1, the AP scheduling the R-TWT is a device capable of setting an interval between two consecutive R-TWT SPs for an SCS traffic stream between a minimum service interval and a maximum service interval of the SCS traffic stream. Claim 7 A device for wireless communication in a network, comprising: (a) a wireless communication circuit that operates as a regular STA or an access point (AP) STA to communicate wirelessly with other radio stations (STAs) using a carrier sensing multiple access / collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN), and as a radio station (STA) that is a separate STA or as a STA within a multi-link device (MLD); (b) a processor coupled to the wireless communication circuit to operate on the WLAN; (c) a non-transient memory that stores instructions executable by the processor to communicate with other STAs; and (d) the instructions, when executed by the processor, perform steps of a wireless communication protocol for the wireless communication circuit, wherein the steps of the wireless communication protocol include: (i) indicating a link on which the modified TWT parameter set field is set using a TWT parameter set field that incorporates a link identification (ID) field into a target wait time (TWT) element; (ii) a non-AP STA transmitting a TWT setup frame to the AP in the modified TWT parameter set field within the TWT element on one link to initiate a TWT setup process on multiple links by the AP; (iii) the AP transmitting a TWT response frame using the modified TWT parameter set field within the TWT element on one link to indicate its decision on the request; and (iv) the non-AP STA receiving the decision from the AP in the TWT setup frame and performing TWT scheduling for frame exchange with the AP as directed by the AP, comprising: (iv) a device comprising Claim 8 A device according to claim 7, wherein the parameters of the modified TWT parameter set are set based on the timing synchronization function (TSF) time value on the link indicated in the link identification (ID) field. Claim 9 In claim 7, the device wherein the TWT setup frame carries a TWT element, and thereby a plurality of modified TWT parameter set fields within the TWT element have the same TWT ID but have different link IDs to indicate a TWT on which the SPs are scheduled on different links. Claim 10 In claim 7, the device wherein the TWT setup frame carries a plurality of TWT elements, and thereby the parameters within the modified TWT parameter set fields for the same TWT and the links within different TWT elements represent the range of parameters for the TWT on the links. Claim 11 A device for wireless communication in a network, comprising: (a) a wireless communication circuit that operates as a regular STA or an access point (AP) STA to communicate wirelessly with other radio stations (STAs) using a carrier sensing multiple access / collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN), and as a radio station (STA) that is a separate STA or as a STA within a multi-link device (MLD); (b) a processor coupled to the wireless communication circuit to operate on the WLAN; (c) a non-transient memory that stores instructions executable by the processor to communicate with other STAs; and (d) the instructions, when executed by the processor, perform steps of a wireless communication protocol for the wireless communication circuit, wherein the steps of the wireless communication protocol include: (i) initiating an SCS setup in addition to scheduling a limited target wait time (R-TWT) for the SCS by transmitting a stream classification service (SCS) request frame containing QoS characteristic elements to an AP station by a non-AP STA; (ii) receiving the SCS request frame from the non-AP STA, wherein the AP determines whether to accept the request; (iii) transmitting an SCS response frame by the AP to the non-AP STA indicating the decision regarding the request; (iv) transmitting a TWT response frame by the AP to allocate R-TWT membership for scheduling the transmission of SCS traffic during corresponding R-TWT service periods (SPs) if the SCS response frame accepts the SCS request; and (v) scheduling by the AP and the non-AP STA during the corresponding R-TWT SPs such that the SCS traffic is transmitted with a transmission priority that precedes the transmission priority of non-SCS traffic if the request is accepted, the apparatus comprising Claim 12 In paragraph 11, the TWT response frame is a device that can be transmitted by an AP MLD on any link where the R-TWT SP is scheduled for an SCS traffic stream. Claim 13 In paragraph 11, the device, wherein the above TWT response frame can be transmitted by the AP MLD within a timeout. Claim 14 In paragraph 11, the device, the non-AP MLD, must not transmit a TWT request frame for said SCS traffic stream within a timeout after the SCS traffic stream requesting R-TWT scheduling has been successfully established. Claim 15 In paragraph 11, the non-AP MLD is a device that retransmits an SCS request frame if it does not receive a TWT response frame for said SCS traffic stream within a timeout after the SCS traffic stream requesting R-TWT scheduling has been successfully established. Claim 16 In paragraph 11, the non-AP MLD transmits a TWT request frame for the SCS traffic stream if, after the SCS traffic stream requesting R-TWT scheduling is successfully established, it does not receive a TWT response frame for the SCS traffic stream within a timeout. Claim 17 delete Claim 18 delete Claim 19 delete

Images