Stream Classification Service (SCS) with RESTRICTED TARGET WAIT TIME (R-TWT) setup

Abstract

An IEEE 802.11 protocol that eliminates the need and issues surrounding separate SCS setup and target wait time reservation (R-TWT). In this disclosure, new data structures and processes are implemented that allow a station (STA) to request that an R-TWT be scheduled for Stream Classification Service (SCS) traffic transmissions during the SCS setup procedure. When using the techniques of this disclosure, a STA can exchange TWT setup frames on one link and schedule R-TWT on multiple links.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[0002] Not applicable

[0003] Notification of copyrighted material

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

[0004]

[0005] The techniques of this disclosure relate generally to wireless local area networks operating under 802.11, and more specifically to a CSMA / CA protocol that enables requesting Limited Target Wait Time (R-TWT) scheduling for Stream Classification Service (SCS) traffic transmissions during SCS setup. [Background technology]

[0005]

[0007] Current wireless technologies that use CSMA / CA (such as IEEE 802.11be) focus on high throughput network performance but do not provide a high level of low latency (low delay) performance. However, many applications, such as real-time applications (RTA), require low latency capabilities, so a technology gap exists.

[0006]

[0008] Real-time applications (RTA) require low latency communication and rely on best-effort communication. Data generated from RTA is called RTA traffic and is packetized as RTA packets at the sender STA. Data generated from non-time-sensitive applications is called non-RTA traffic and is packetized as non-RTA packets at the sender STA.

[0007]

[0009] RTA packets require low latency due to high timeliness requirements in packet delivery: an RTA packet is valid when delivered within a specific period of time. Summary of the Invention [Problem to be solved by the invention]

[0008]

[0010] Thus, there is a need for an enhanced CSMA / CA WLAN protocol that can provide low latency for RTA packets while providing high throughput for non-RTA packet traffic. The present disclosure fulfills this need and provides further advantages. [Means for solving the problem]

[0009]

[0011] The disclosed protocol for CSMA / CA WLANs allows stations (STAs) to request scheduling of Limited Target Wait Time (R-TWT) for Stream Classification Service (SCS) traffic transmissions during the SCS setup procedure. Thus, STAs can exchange TWT setup frames on one link to schedule R-TWT on multiple links.

[0010]

[0012] Further aspects of the technology described herein will become apparent in the following portions of this specification, and this detailed description is provided for complete disclosure of preferred embodiments of the technology without limiting them.

[0011]

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

[0012] [Figure 1] FIG. 2 is a data field diagram of a conventional TSPEC element as defined in IEEE 802.11. [Diagram 2] FIG. 2 is a data field diagram of the TS information field of the TSPEC element of FIG. 1. [Diagram 3] FIG. 1 is a data field diagram of the TCLAS element defined in IEEE 802.11. [Figure 4] FIG. 2 is a data field diagram of the TCLAS processing element as specified in IEEE 802.11. [Diagram 5] FIG. 2 is a data field diagram of the TWT element as specified in IEEE 802.11. [Figure 6] FIG. 6 is a data field diagram of the control field of the TWT element of FIG. 5. [Figure 7] FIG. 6 is a data field diagram of the broadcast TWT parameter information of FIG. 5. [Figure 8] FIG. 8 is a data field diagram of a request type field in the broadcast TWT parameter information field shown in FIG. 7. [Figure 9] FIG. 8 is a data field diagram of a Broadcast TWT information field in the Broadcast TWT parameter information field shown in FIG. 7. [Figure 10] FIG. 2 is an inter-level communication diagram of the SCS setup procedure as specified in IEEE 802.11be. [Figure 11] FIG. 13 is a data field diagram of an SCS request frame. [Figure 12] FIG. 1 is a data field diagram of the SCS descriptor element format. [Figure 13] FIG. 13 is a data field diagram of an SCS response frame. [Figure 14] FIG. 13 is a data field diagram of the SCS status field. [Figure 15] FIG. 1 is an inter-level communication diagram of TWT setup signaling. [Figure 16] FIG. 6 is a data field diagram of a TWT Setup frame carrying TWT elements as seen in FIG. 5. [Figure 17] FIG. 2 is a hardware block diagram of a wireless station (STA) hardware in accordance with at least one embodiment of the present disclosure. [Figure 18] FIG. 2 is a hardware block diagram of a station configuration as included in a multi-link device (MLD) hardware in accordance with at least one embodiment of the present disclosure. [Figure 19] FIG. 2 illustrates a station topology under consideration, in accordance with at least one embodiment of the present disclosure. [Figure 20] A flow diagram of a non-AP sending an SCS request frame including R-TWT membership request information in accordance with at least one embodiment of the present disclosure. [Figure 21] A flow diagram of a non-AP sending an SCS request frame including R-TWT membership request information in accordance with at least one embodiment of the present disclosure. [Figure 22] 1 is a flow diagram of an AP responding with an SCS response frame that includes an R-TWT membership response, in accordance with at least one embodiment of the present disclosure. [Figure 23] FIG. 13 is a data field diagram of a modified SCS descriptor element including an R-TWT setup request in accordance with at least one embodiment of the present disclosure. [Figure 24] FIG. 2 is a data field diagram of an RTA-TSPEC element in accordance with at least one embodiment of the present disclosure. [Diagram 25] FIG. 1 is a data field diagram of a modified TS information field format within an RTA-TSPEC element in accordance with at least one embodiment of the present disclosure. [Figure 26] FIG. 13 is a data field diagram of an example RTA-TSPEC element format when setting a default use case, in accordance with at least one embodiment of the present disclosure. [Figure 27] FIG. 13 is a data field diagram of a modified SCS status in accordance with at least one embodiment of the present disclosure. [Figure 28] FIG. 13 is a data field diagram of a modified TWT element in accordance with at least one embodiment of the present disclosure. [Figure 29] FIG. 1 is a communication diagram of an SCS setup including an R-TWT in accordance with at least one embodiment of the present disclosure. [Diagram 30] FIG. 13 is a communication diagram illustrating a method for scheduling an R-TWT for an SCS traffic stream during an SCS setup procedure in accordance with at least one embodiment of the present disclosure. [Diagram 31] FIG. 1 is a communications diagram for scheduling multiple R-TWTs for one SCS traffic stream in accordance with at least one embodiment of the present disclosure. [Diagram 32] FIG. 13 is a communication diagram of an SCS setup including an R-TWT for another link in accordance with at least one embodiment of the present disclosure. [Diagram 33] FIG. 1 is a communication diagram of an R-TWT setup using modified TWT elements in accordance with at least one embodiment of the present disclosure. [Diagram 34] FIG. 1 is a communication diagram of a broadcast TWT setup using modified TWT elements in accordance with at least one embodiment of the present disclosure. [Diagram 35] FIG. 13 is a communication diagram of a wake TBTT negotiation using a modified TWT element in accordance with at least one embodiment of the present disclosure. [Diagram 36] FIG. 13 is a communication diagram of an individual negotiation using a modified TWT element in accordance with at least one embodiment of the present disclosure. [Figure 37] FIG. 13 is a flow diagram in which a non-AP MLD initiates an SCS setup procedure requesting R-TWT scheduling to an SCS, in accordance with at least one embodiment of the present disclosure. [Figure 38] FIG. 13 is a flow diagram in which a non-AP MLD initiates an SCS setup procedure requesting R-TWT scheduling to an SCS, in accordance with at least one embodiment of the present disclosure. [Figure 39] 1 is a flow diagram of an AP MLD sending an SCS response frame to assign membership to an SCS, in accordance with at least one embodiment of the present disclosure. [Diagram 40] FIG. 13 is a data field diagram of an SCS descriptor element including an R-TWT request field within a QoS characteristics element in accordance with at least one embodiment of the present disclosure. [Diagram 41] FIG. 13 is a data field diagram of a modified Broadcast TWT parameter set field including an SCSID subfield in accordance with at least one embodiment of the present disclosure. [Diagram 42] FIG. 1 is a communication diagram in which AP1 schedules an R-TWT SP for an SCSx traffic stream on Link 1, in accordance with at least one embodiment of the present disclosure. [Diagram 43] FIG. 1 is a communication diagram in which AP1 schedules R-TWT SPs for SCSx traffic streams on different links, in accordance with at least one embodiment of the present disclosure. [Diagram 44]FIG. 13 is a communication diagram in which MLD1 schedules R-TWT SPs for SCSx traffic streams on multiple links, in accordance with at least one embodiment of the present disclosure. [Diagram 45] FIG. 11 is a communication diagram in which MLD3 does not receive R-TWT membership for SCSx before a timeout, in accordance with at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] 1. Introduction to IEEE 802.11 Data Elements 1.1. Traffic Specification (TSPEC) Elements

[0059] Figure 1 shows the contents within a TSPEC element as defined in IEEE 802.11, with the following fields: The Element ID field indicates the type of element, e.g., in this case, a TSPEC element. The Length field indicates the length of the TSPEC element. The TS info field provides traffic stream information as explained below in Figure 2.

[0014]

[0060] The nominal MSDU size field indicates the nominal size of an MSDU or A-MSDU belonging to a TS under this TSPEC. The maximum MSDU size field indicates the maximum size of an MSDU or A-MSDU belonging to a TS under this TSPEC. The minimum service interval field indicates the minimum time between the start times of two consecutive service periods (SPs). The maximum service interval field indicates the maximum time between the start times of two consecutive SPs. The inactivity interval field indicates the maximum time interval before the transmission arrival of an MSDU belonging to a TS before the TS is deleted. The suspension interval field indicates the maximum time interval without either the arrival or transmission of an MSDU belonging to a TS before the generation of consecutive QoS(+)CF-Polls for the TS is stopped.

[0015]

[0061] 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 a TS under this TSPEC. The Mean Data Rate field indicates the average data rate specified by the MAC SAP for transmitting MSDUs or A-MSDUs belonging to a 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 a TS under this TSPEC. The Burst Size field indicates the maximum burst of MSDUs or A-MSDUs belonging to a TS under this TSPEC at the peak data rate. The Delay Bound field is the maximum time allowed to transmit an MSDU or A-MSDU belonging to a TS under this TSPEC.

[0016]

[0062] The Minimum PHY Rate field indicates the minimum PHY rate for transmitting an MSDU or A-MSDU belonging to a TS under this TSPEC. The Excess Bandwidth Allowance field contains the ratio of the bandwidth used for transmitting and retransmitting an MSDU or A-MSDU belonging to a TS under this TSPEC to the bandwidth used for transmitting the MSDU or A-MSDU once at the minimum PHY rate. The Medium Time field (time per second) indicates the time allowed to access the medium. The DMG Attributes field is present when the TSPEC is applied to a Directional Multi-Gigabit (DMG) BSS.

[0017]

[0063] Figure 2 shows the contents in the TS Information field of the TSPEC element of Figure 1 as specified in IEEE 802.11. This element has the following subfields: The Traffic Type subfield specifies whether the traffic is periodic or not. The TSID indicates an ID number for identifying the TS. The Direction subfield specifies the direction of data transmission. The Access Policy subfield specifies the method for gaining channel access. The Aggregation subfield specifies whether an aggregation schedule is required. The APSD subfield indicates whether automatic PS distribution is used. The User Priority subfield indicates the user priority of the MSDUs or A-MSDUs belonging to the TS. The TS Information 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.

[0018] 1.2. Traffic Classification (TCLAS) Elements

[0065] Figure 3 shows the contents of the TCLAS element as specified in IEEE 802.11, with 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 higher layers; The Frame Classification field indicates the method for classifying frames from higher layers.

[0019] 1.3. Traffic Classification (TCLAS) Processing Element

[0067] Figure 4 shows the contents in a TCLAS processing element as specified in IEEE 802.11, with the following fields: Element ID field indicates the type of element, in this case a TCLAS processing element; Length field indicates the length of the TCLAS processing element; Processing field indicates how to classify traffic from higher layers when multiple TCLAS elements are present.

[0020] 1.4.TWT element

[0069] Figure 5 shows the format of the TWT element as specified in IEEE 802.11ax, with the following fields: Element ID and Length serve the same purpose as described above. The Control field provides control information. When the Negotiation Type field in the Control field in the TWT element is set to a value of "2" or "3", the TWT Parameter Information field in the TWT element carries the Broadcast TWT Parameter Information field as shown in Figure 7.

[0021]

[0070] Note that there is an update in IEEE 802.11be (Draft P802.11be_D1.01) related to this element. When the Broadcast TWT Recommendation field in 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) indicated in the Broadcast TWT Parameter Information field is a restricted TWT (R-TWT).

[0022]

[0071] FIG. 6 illustrates a control field for the TWT element with the subfields: NDP paging indicator, responder PM mode, negotiation type, TWT information frame disable, wake duration units, and reserved field.

[0023]

[0072] 7 shows the Broadcast TWT Parameter Information field (TWT Parameter Information field in the TWT element when the Negotiation Type is 2 or 3). The subfields include Request Type, Target Wake Time, Nominal Minimum TWT Wake Duration, TWT Wake Interval Mantissa, and Broadcast TWT Information.

[0024]

[0073] Figure 8 illustrates the Request Type field in the Broadcast TWT Parameter Information field illustrated in Figure 7. The subfields include TWT Request, TWT Setup Command, Trigger, Last Broadcast Parameter Set, Flow Type, Broadcast TWT Recommendation, TWT Wake Interval Exponent, and Reserved subfields.

[0025]

[0074] Figure 9 shows the Broadcast TWT Information subfield in the Broadcast TWT Parameter Information field shown in Figure 7. The subfields include a Reservation subfield, a Broadcast TWT ID subfield, and a Broadcast TWT Duration subfield.

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

[0076] An example of a Stream Classification Service (SCS) setup as specified in IEEE 802.11be (Draft P802.11be_D1.01) is shown in Figure 10. The interaction model of the STAs can be the same as that specified in the IEEE 802.11 standard.

[0027]

[0077] A non-AP STA decides to initiate an SCS setup procedure towards an AP. The station management entity (SME) of the non-AP STA sends an MLME-SCS.request message to the MAC sublayer management entity (MLME) of the non-AP STA. When the MLME of the non-AP STA receives the MLME-SCS.request message, it collects the information in the MLME-SCS.request message and sends an SCS request frame to the AP. The MLME of the AP receives the frame and generates an MLME-SCS.indication message to the SME of the AP, which processes the request.

[0028]

[0078] The SME of the AP then sends an MLME-SCS.response message containing the SCS setup result to the MLME of the AP. The MLME of the AP then sends an SCS response frame to the non-AP STA. The MLME of the non-AP STA receives the frame and sends an MLME-SCS.confirm message to the SME of the non-AP STA. At this point, the non-AP can then know whether the SCS setup was successful or not.

[0029]

[0079] 11 to 14, the SCS request frame and related data will be described.

[0030]

[0080] Figure 11 illustrates an SCS request frame with the following fields: Frame Control, Address Fields (1-3), Sequence Control, Action, and Frame Check Sequence (FCS). The action field shown includes the following subfields: Category, Robust Action, Dialog Token, and SCS Descriptor List, each of which includes the fields shown in Figure 12. It should be understood that the SCS Descriptor List field can carry multiple SCS Descriptor elements.

[0031]

[0081] As shown in FIG. 12, each descriptor element has the following fields: element ID, length, SCSID, request type, intra-access category priority, TCLAS, TCLAS operation (optional), TSPEC, and optional sub-elements.

[0032]

[0082] Figure 13 shows an SCS Response frame with the subfields Frame Control, Duration, Address (1-3), Sequence Control, Action, and FCS. The Action subfield shown has subfields Category, Robust Action, Dialog Token, and SCS Status List. The SCS Status List subfield can carry multiple SCS Status subfields as shown in Figure 14.

[0033]

[0083] 14 shows an SCS status field including SCSID and status subfields. The status indicates the SCS setup result (e.g. accepted, rejected, rejected with reason, terminated, etc.) for the SCS indicated in the SCSID field.

[0034] 1.6.TWT Signalling

[0085] An example of TWT setup signaling as specified in IEEE 802.11ax is shown in Figure 15. The STA interaction model can be the same as that specified in the IEEE 802.11 standard.

[0035]

[0086] A non-AP STA decides to initiate a TWT setup procedure with the AP. The station management entity (SME) of the non-AP STA sends an MLME-TWTSETUP.request message to the MAC sublayer management entity (MLME) of the non-AP STA. When the MLME of the non-AP STA receives the MLME-TWTSETUP.request message, it collects the information in the MLME-TWTSETUP.request message and sends a TWT setup frame (i.e., a TWT request frame) to the AP. The MLME of the AP receives the frame and generates an MLME-TWTSETUP.indication message to the SME of the AP, which processes the request.

[0036]

[0087] The AP's SME then sends an MLME-TWTSETUP.response message containing the TWT setup result to the AP's MLME. The AP's MLME then 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 the non-AP STA's SME. The non-AP STA can then know (determine) whether the TWT setup is successful or not.

[0037]

[0088] Figure 16 shows a TWT Setup frame that carries the TWT elements within a frame as shown in Figure 5. The subfields of the TWT Setup are Frame Control, Duration, Address (1-3), Sequence Control, Data, and FCS. The data field shown has the subfields Category, Action, Dialog Token, and TWT Elements.

[0038] 2. Statement of the Problem and Contributions of This Disclosure

[0090] Current IEEE 802.11 protocols support separate SCS and R-TWT setup, however, this can lead to problems when, for example, the SCS is successfully set up but the QoS requirements of the SCS may not be met by not being able to schedule the R-TWT for that SCS's traffic transmission.

[0039]

[0091] In many cases, a trade-off is required between high throughput and low latency performance, since they may not be achievable simultaneously across all traffic. To meet the different requirements of real-time application (RTA) packet traffic and non-RTA packet traffic, a network may use some features to enhance low latency performance when transmitting RTA packets, while utilizing other features to maximize throughput when transmitting non-RTA packets.

[0040]

[0092] Therefore, for this purpose, RTA and non-RTA traffic should be distinguished by the sender STA, while sometimes the receiver STA may benefit from distinguishing between RTA and non-RTA packets, and the network may choose to use different features to meet the requirements of RTA and non-RTA traffic separately.

[0041]

[0093] In many cases, RTA traffic is generated periodically, as in connection-oriented communication. An RTA connection-oriented communication established by an application between STAs is called an RTA session. In some instances, a STA may have multiple RTA sessions in a network, and the STA must be able to manage those RTA sessions.

[0042]

[0094] To manage those RTA sessions in a WLAN network, the present disclosure is configured to regard the RTA sessions as Stream Classification Service (SCS) traffic streams in IEEE 802.11. Then, the RTA traffic of the SCS traffic streams can be differentiated from other traffic. Meanwhile, the Restricted Target Wait Time (R-TWT) can be used to schedule and reserve channel resources for the transmission of the RTA traffic. The present disclosure includes the R-TWT setup in the SCS setup procedure. When the SCS traffic stream is established for the RTA session, the channel resources are reserved to guarantee the QoS quality (such as latency, jitter, and packet loss) of the RTA traffic stream via the R-TWT.

[0043]

[0095] This disclosure provides a protocol by which a STA can request to schedule an R-TWT for SCS traffic transmission during an SCS setup procedure. By utilizing this configuration, a STA can exchange TWT setup frames on one link to schedule R-TWTs on multiple links.

[0044] 3. Embodiments of the present disclosure 3.1. Communication Station (STA and MLD) Hardware

[0098] FIG. 17 illustrates an example 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 the circuitry 12 on which a CPU 18 and a memory (e.g., RAM) 20 are connected to execute a program implementing the communication protocol. The host machine contains at least one modem 22 for supporting communications, which is coupled to at least one RF module 24, 28, each of which is connected to one or more antennas 29, 26a, 26b, 26c, ..., 26n. An RF module containing multiple antennas (e.g., an antenna array) allows beamforming to be performed during transmission and reception. In this manner, the STA can transmit signals using a set of multiple beam patterns.

[0045]

[0099] The bus 14 allows connecting various devices to the CPU, e.g., sensors, actuators, etc. On the processor 18, instructions are executed from the memory 20 for executing programs implementing a communication protocol, which allows the STA to perform the functions of an Access Point (AP) station or a normal station (non-AP STA). It is to be understood that the programming is also configured to operate in different modes (TXOP holder, TXOP sharing participant, source, intermediate, destination, first AP, other AP, station associated with first AP, station associated with other AP, coordinator, coordinator, AP in OBSS, STA in OBSS, etc.) depending on what role it is performing in the current communication context.

[0046]

[0100] The illustrated STA HW is therefore configured to include at least one modem and associated RF circuitry to provide communications in at least one band, with this disclosure primarily directed to the sub-6 GHz band.

[0047]

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

[0048]

[0102] It should further be noted that multiple instances of station hardware such as those shown in the figure may be combined into a multi-link device (MLD), which typically has a processor and memory for coordinating activity, but a separate CPU and memory is not always required for each STA in the MLD.

[0049]

[0103] FIG. 18 shows the hardware configuration of a multi-link device (MLD).

[0050]

[0104] FIG. 18 shows an example embodiment 40 of a multi-link device (MLD) hardware configuration. The Soft-AP MLD is an MLD consisting of one or more associated STAs operating as APs. The Soft-AP MLD supports multiple radio operation at 2.4 GHz, 5 GHz, and 6 GHz. Among the multiple radios, the basic link set is a link pair that satisfies simultaneous transmit / receive (STR) mode, e.g., basic link set (2.4 GHz and 5 GHz), basic link set (2.4 GHz and 6 GHz).

[0051]

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

[0052]

[0106] A number of STAs are associated with the MLD, each of which operates on a different frequency link. The MLD has external I / O access to applications that connect to an MLD management entity 48 having a CPU 62 and memory (e.g., RAM) 64 to run programs that implement communication protocols at the MLD level. The MLD distributes tasks to each of the associated stations (here illustrated as STA 1 42, STA 2 44, ..., STA N 46) to which the MLD is connected, and can collect information from each associated station and share the information among the associated STAs.

[0053]

[0107] In at least one embodiment, each STA of the MLD has its own CPU 50 and memory (RAM) 52, which are coupled via a bus 58 to at least one modem 54, which is connected to at least one RF circuit 56, which has one or more antennas. In this example, the RF circuit has multiple antennas 60a, 60b, 60c, ..., 60n, e.g., an antenna array. The modem cooperates with the RF circuit and associated antennas to transmit / receive data frames to / from neighboring STAs. In at least one implementation, the RF module includes a frequency converter, an array antenna controller, and other circuitry for interfacing with the antennas.

[0054]

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

[0055] 3.2.Network Topology to Consider

[0110] 19 shows an example STA topology considered in the embodiments of the present disclosure. The diagram is provided to aid in the explanation of the techniques involved and to improve understanding of the proposed technology. It should be understood that the present disclosure is in no way limited to this example topology, as the protocol can be utilized for communication between WLAN STAs and MLDs of any desired topology.

[0056]

[0111] An MLD is a device that has more than one associated STA and has one MAC Service Access Point (SAP) for a Logical Link Control (LLC) that contains one MAC data service.

[0057]

[0112] If an AP is associated with an MLD, then the MLD is an AP MLD. If a non-AP STA is associated with an MLD, then the MLD is a non-AP MLD.

[0058]

[0113] As shown in FIG. 19, the example scenario has a total of seven stations, six of which are in MLDs 72, 74, and 76 in a conference room. AP1 78 and AP2 80 are associated with multi-link device (MLD) #1 72, 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 that has only one STA and operates on one link). STA1, STA2, and STA3 are associated with AP1 through link 1 94, 98, and STA4 and STA5 are associated with AP2 through link 2 96 and 100. All STAs use EDCA for random channel access on all links.

[0059] 3.3. SCS Setup Procedure / R-TWT Membership Exchange

[0115] This section describes the SCS setup process, including the R-TWT membership exchange for SCS traffic. The purpose of adding the R-TWT membership exchange to the SCS setup procedure is to schedule an R-TWT SP to transmit the SCS traffic and meet its QoS requirements (such as throughput, latency, jitter, and packet loss), and then establish the SCS. If an R-TWT service period (SP) cannot be scheduled to transmit the SCS traffic, the SCS setup request can be rejected.

[0060]

[0116] Note that if desired, the SCS and R-TWT setup procedures can be separated, and the R-TWT SPs are scheduled to meet the QoS requirements of the SCS traffic streams.

[0061]

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

[0062]

[0118] (b) The SCS status element for SCSx within the TWT element of the corresponding SCS response frame sent by the AP may include an R-TWT membership response, in which case the R-TWT membership response indicates one of the following responses:

[0063]

[0119] (b)(i) The R-TWT membership request is accepted and the non-AP STA transmits traffic for SCSx according to the accepted R-TWT scheduling. The traffic for the SCS is scheduled to transmit during the accepted R-TWT SP. For example, if it is a trigger-based R-TWT, the AP schedules trigger-based transmission for that SCSx traffic stream. The non-AP STA becomes a member STA of the accepted R-TWT. SCSx is denoted as a member STA of the accepted R-TWT. In at least one embodiment / mode / case, traffic that does not belong to a member SCS of the R-TWT is either not allowed to transmit during the SP of the R-TWT or is given lower priority than traffic of the member SCS of the R-TWT for transmitting during the SP of the 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 can transmit those frames during the SP of the R-TWT. The AP should transmit its frames during the SP of the R-TWT earlier than the frames of the member SCSs of the R-TWT with the same TID when block acknowledgement is used for that TID, because their sequence numbers are assigned lower than the frames of the member SCSs of the R-TWT with the same TID.

[0064]

[0120] (b)(ii) The R-TWT membership request is not accepted, but proposed R-TWT parameters are given by the AP. The 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 relevant to an R-TWT of which the non-AP STA is a member, or the proposed R-TWT parameters relevant to an R-TWT of which the non-AP STA is a member do not affect the non-AP STA's membership of that R-TWT.

[0065]

[0121] (b)(iii) The R-TWT membership request is rejected and the non-AP should not re-request membership in that R-TWT.

[0066]

[0122] In this section, the proposed technique considers R-TWT scheduling for the SCS during the SCS setup procedure. It may also be allowed to set up other types of TWTs (such as individual TWTs and broadcast TWTs) during the SCS setup procedure. The setup signaling exchange for other types of TWTs may be the same as the R-TWT membership exchange in the SCS setup procedure, since all types of TWT setup signaling information is carried by the TWT element. The TWT setup procedure for other types of TWTs during the SCS procedure may be the same as that shown in section 1.6.

[0067]

[0123] It is noted that the SCS setup procedure may be the same as that shown in FIG. 10, except that the format of the SCS request frame and the SCS response frame are modified to add the TWT membership.

[0068] 3.3.1. Non-AP sends SCS request frame / R-TWT membership request information

[0125] This section describes the setup procedure for the SCS including the R-TWT setup request on the non-AP STA side. This section provides details on the following operations:

[0069]

[0126] (a) The process for a non-AP STA to send an SCS setup request carrying an R-TWT setup request for an SCS is as follows: In at least one embodiment, the SCS request including the R-TWT setup request may be carried in a modified SCS Descriptor element as shown in Figure 23. The non-AP STA may send an SCS request frame as shown in Figure 12, whereby the SCS Descriptor List field may carry one or more modified SCS Descriptors to the AP. Each modified SCS Descriptor element represents an SCS setup request for one SCS indicated in the SCS ID field.

[0070]

[0127] (b) The process for an AP to respond to an SCS setup carrying an R-TWT setup request for an SCS is as follows: In at least one embodiment, a response to an SCS setup including R-TWT scheduling for that SCS may be carried in a modified SCS status element as shown in Figure 27. The AP transmits an SCS response frame as shown in Figure 25, whereby the SCS status list may carry one or more modified SCS status elements as shown in Figure 27. Each modified SCS status element represents a setup response for one SCS indicated in the SCS ID field.

[0071]

[0128] 20 and 21 show an example embodiment 110 in which a non-AP sends an SCS request frame including an R-TWT setup request to an AP associated with it to request SCS setup including R-TWT membership request information.

[0072]

[0129] The non-AP sends an SCS request frame (112) to the AP to establish an SCS (denoted as SCSx). The non-AP STA may indicate an R-TWT setup request for traffic transmissions of SCSx during SCSx. For example, within the SCS Descriptor element of SCSx in 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 Characteristics element as specified in IEEE 802.11be) to indicate that the non-AP STA requests R-TWT scheduling for traffic transmissions of SCSx.

[0073]

[0130] Then, the SCS Descriptor element of SCSx may include a TWT element to indicate the R-TWT scheduling requirements for SCSx. The Negotiation Type field in the Control field of the TWT element should be set to "3" to indicate that the TWT element is for a membership exchange. Assume that a non-AP is requesting membership of R-TWTx for traffic transmission of SCSx. Then, the TWT element includes a Broadcast TWT Parameter Set field of R-TWTx. The TWT Request field and the Broadcast TWT Recommendation field in the Request Type field of the Broadcast TWT Parameter Set field of R-TWTx should be set to "1" and "4", respectively, to indicate that the TWT element is for an R-TWT membership request. The Broadcast TWT Recommendation field in the Request Type field of the Broadcast TWT Parameter Set field of R-TWTx may be set to the value "4" or other value to indicate that R-TWTx is an R-TWT. Note that a non-AP may have multiple broadcast TWT parameter set fields in one or more TWT elements in one SCS descriptor element to request membership in different R-TWTs.

[0074]

[0131] In at least one embodiment / mode / case, the non-AP STA may set the R-TWT request field to "required" or "optional" in the TS information field format in the RTA-TSPEC element, but may not add a TWT element to the SCS descriptor element of SCSx. Then, according to at least one embodiment, the AP may send an unsolicited R-TWT scheduling to SCSx if it accepts the SCS setup request.

[0075]

[0132] The non-AP can set the R-TWT request field to "not required" and the SCS request frame is for SCS setup only as specified in IEEE 802.11. There is no TWT element carried by the SCS Descriptor element in the SCS request frame. This provides backward compatibility with existing protocols. The non-AP STA then receives an SCS response frame to indicate the SCSx setup result.

[0076]

[0133] If, in block 114, it is determined that the AP has rejected the SCS setup request, then the SCS setup, along with any associated R-TWT setup request, has failed (124) (FIG. 21).

[0077]

[0134] Execution proceeds 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 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 Status element in the SCS Response frame.

[0078]

[0135] If the non-AP receives an SCS response frame from the AP that the AP has accepted the SCSx setup in block 114 of Figure 20, the SCSx setup is successful and the non-AP can distinguish the SCS traffic from other traffic in block 116. If the SCSx establishment is successful, the non-AP STA checks (118) whether the R-TWT setup request for SCS has been accepted by the AP (Figure 21).

[0079]

[0136] If the R-TWT setup request is accepted in block 118, the non-AP STAs become members of the R-TWT indicated by the TWT element in the Status element of SCSx in the SCS Response frame in block 122. The SCS traffic becomes the member SCSs of those R-TWTs.

[0080]

[0137] If, at block 118, the R-TWT setup request is not accepted, at block 120, the non-AP STA does not change its membership in the R-TWT advertised by the AP.

[0081]

[0138] If an SCS is requested to modify an existing SCS, it is not possible to add a TWT element to the SCS Descriptor element of that SCS.

[0082]

[0139] If an SCS setup request is accepted but an R-TWT setup request for that SCS is rejected, a non-AP STA may send a TWT setup frame to request membership in the R-TWT.

[0083]

[0140] FIG. 22 illustrates an example embodiment 130 in which the AP responds with an SCS response frame that includes an R-TWT setup response for the SCS.

[0084]

[0141] When the AP receives an SCS request frame from a non-AP STA (132) including an R-TWT setup request for establishing an SCS (denoted as SCSx) and schedules an R-TWT SP to transmit traffic belonging to SCSx, the AP sends an SCS response frame (134) to the non-AP STA including an R-TWT setup response.

[0085]

[0142] In block 136, it is determined whether the AP accepted the SCS request and the R-TWT setup request. The SCSx setup performed by the AP may be indicated in the SCS status element of SCSx in the SCS response frame. A response to the R-TWT setup for SCSx may also be included in the SCS status element of SCSx. It should be understood that in at least one embodiment / mode / case, the AP indicates rejection of the R-TWT setup by not including any TWT element in the SCS status element of SCSx.

[0086]

[0143] If the SCS and R-TWT are accepted, the non-AP STA becomes a member of the R-TWT and traffic belonging to the SCS is scheduled to transmit during the R-TWT SP in block 138. On the other hand, if the request is not accepted in block 136, traffic belonging to the SCS is not allowed or is given a lower priority than transmission during the R-TWT SP in block 140.

[0087]

[0144] Specifically, in at least one embodiment, an AP has the following options for responding to a non-AP:

[0088]

[0145] (a) The AP accepts the SCSx setup and the R-TWT setup request for SCSx. In this case, the establishment of SCSx is successful and the traffic of SCSx can be distinguished from other traffic. The AP also allocates an R-TWT to transmit the traffic of SCSx. The AP adds a TWT element to the modified SCS status field of SCSx to indicate the R-TWT scheduling for the traffic transmission of SCSx. Specifically, when the R-TWT SP is trigger-based, the AP schedules the transmission of the traffic belonging to the SCS during the SP of that R-TWT.

[0089]

[0146] (b) The AP accepts the SCSx setup request but rejects the R-TWT setup request for SCSx. Note that this case can only occur when the AP receives an SCS request frame with the R-TWT request field in the TS information field format in the RTA-TSPEC element in the SCS descriptor element of SCSx set to "optional". In this case, the establishment of SCSx is successful, but no R-TWT is scheduled for traffic transmission of SCSx. To reject an R-TWT setup request for SCSx, the AP may (1) not include a TWT element in the SCS status element for SCSx, or (2) add a TWT element including a TWT setup command field indicating "reject TWT" to the SCS status element for SCSx to indicate the rejection of the R-TWT setup request for that SCS, or (3) add a TWT element including a TWT setup command field indicating "Alternate TWT" or "Dictate TWT" to the SCS status element for the SCS to indicate the proposed parameters for R-TWT setup for the SCS when rejecting the R-TWT setup request.

[0090]

[0147] (c) Otherwise, the AP rejects the SCSx setup request and rejects the R-TWT setup request for SCSx. In this case, the SCSx setup failed, but no R-TWT is scheduled for traffic transmission for SCSx. To reject the R-TWT setup request for SCSx, the AP can (1) not include a TWT element in the SCS status element for SCSx, or (2) add a TWT element with a TWT setup command field indicating "reject TWT" to the SCS status element for SCSx to indicate the rejection of the R-TWT setup request for that SCS, or (3) add a TWT element with a TWT setup command field indicating "Alternate TWT" or "Dictate TWT" to the SCS status element for the SCS to indicate the proposed parameters for R-TWT setup for the SCS when rejecting the R-TWT setup request.

[0091] 3.3.2.Communication Frame Format

[0149] Figure 23 shows an example embodiment 150 of a modified SCS Descriptor element for the 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. The modifications of this modified SCS Descriptor element compared to the SCS Descriptor element as shown in Figure 13 are described as follows. Fields without any description below can be the same as those in Figure 13 or reserved.

[0092]

[0150] Set the request type field to indicate the request type of the SCS descriptor element. When a non-AP STA sets the request type field to "Add", it requests to add a new SCS. Next, the AP responds whether the request is accepted or not. Also, when the AP accepts an SCS request in which the R-TWT request field in the TS information field within the RTA-TSPEC element is set to "Required", it should accept an R-TWT setup request for the new SCS. When the R-TWT request field in the TS information field within the RTA-TSPEC element is set to "Optional", the AP can reject the R-TWT membership request. Note that the RTA-TSPEC can be replaced by the QoS characteristics element defined in IEEE 802.11be.

[0093]

[0151] When a non-AP STA sets the request type field to "Modify", it requests to change the type of the existing SCS. When the AP receives this field, it can find the SCS using the tuple <SCSID, non-AP STA MAC address>. Next, the AP accepts or rejects changing the parameters of that SCS. If the AP rejects a request to change a previously accepted SCS, it continues to operate using the previously accepted classification and R-TWT scheduling (if any) for this SCS.

[0094]

[0152] When a non-AP STA requests to remove an existing SCS by setting the request type to "remove", the AP can identify the SCS by the tuple <SCS ID, non-AP MLD MAC address (if the non-AP is a STA, the non-AP STA MAC address)> when it receives this field and remove the SCS. The R-TWT SP scheduled for this SCS can be modified or removed. For example, if an R-TWT SP is scheduled for this SCS, when this SCS is removed, the duration of the R-TWT SP should be reduced by the amount of time required to transmit the traffic belonging to this SCS. If an R-TWT SP is scheduled only for this SCS, the R-TWT SP should be cancelled. The AP can add a TWT element to indicate the change in R-TWT scheduling.

[0095]

[0153] The non-AP STA sets the RTA-TSPEC to indicate the traffic specification and QoS requirements of the SCS. When the AP receives this field, it can use the information in this field to determine whether to accept or reject the SCS request. When the AP receives an SCS request that also requires R-TWT setup, it should schedule the R-TWT SP to transmit the traffic of the SCS and meet its QoS requirements.

[0096]

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

[0097]

[0155] A non-AP STA can determine whether to add one or more TWT elements to an SCS descriptor element when the R-TWT request subfield in the modified TS information field is set to "mandatory" or "optional". If the R-TWT request subfield in the modified TS information field is set to "not mandatory", the non-AP STA should not add a TWT element to the SCS descriptor element. If a non-AP STA sets the R-TWT request subfield in the modified TS information field to "mandatory" or "optional" but does not add a TWT element to the SCS descriptor element, the AP still schedules R-TWT for traffic transmission of the SCS indicated in the SCS descriptor element. The R-TWT scheduling can be carried in the corresponding SCS status field in the SCS response frame.

[0098]

[0156] The Negotiation Type subfield of the TWT element is "3", indicating that the non-AP STA is for R-TWT membership.

[0099]

[0157] When the Request Type in the SCS Descriptor element is set to "Add", the TWT Setup Command field in the Request Type field in the Broadcast TWT Parameter Set field in the TWT element MUST be set to "Request TWT", "Suggest TWT", or "Demand TWT". The TWT Request subfield in the Request Type field in the Broadcast Parameter Set field in the TWT element is set to "1" to indicate an R-TWT membership request.

[0100]

[0158] In at least one embodiment / mode / case, the request type in the SCS Descriptor element is set to "Modify", but no TWT elements may be added to the SCS Descriptor element.

[0101]

[0159] When the request type in the SCS Descriptor element is set to "Remove", if the SCS traffic is the only traffic stream of a non-AP STA that is scheduled to transmit by some R-TWT, the TWT Setup Command field in the TWT element can be set to "Reject TWT". Then the non-AP STA is no longer a member of those R-TWTs.

[0102]

[0160] In at least one embodiment / mode / case, a single modified SCS Descriptor field may carry multiple TWT elements to indicate a single value or a range of values ​​for the same R-TWT, e.g., the Target Wake Time (TWT) field, the Nominal Minimum TWT Wake Duration field, and the TWT Wake Interval parameter. To indicate a single value for a parameter, the STA sets the value of that parameter to be the same 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, the STA indicates a range of values ​​for a parameter by setting 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 to a higher value, regardless of order in the TWT element, except for the TWT Wake Interval Mantissa and TWT Wake Interval Exponent fields. The range shown 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, where 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).

[0103]

[0161] 24 illustrates an example embodiment 170 of an RTA-TSPEC element that can incorporate two parts: the original TSPEC and the RTA attributes of the present disclosure, exemplified by the following subfields: 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 utilized without departing from the teachings of the present disclosure.

[0104]

[0162] An example embodiment 190 of a modified TS information field in the RTA-TSPEC element is shown in Figure 25. The TSPEC can be the same as that shown in Figure 1, except that the TS information field is as shown in Figure 25 instead of Figure 2.

[0105]

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

[0106]

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

[0107]

[0165] A default use case field can be added to the TS information field (or the control information field of the QoS characteristic element). This field can be set to indicate some classic use cases of traffic, e.g., AR / VR, online gaming, robotics, etc. The default use case, when set to "0", indicates that no use case is specified and that parameters in the RTA-TSPEC element should 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-TSPEC element can be set by default. In at least one embodiment / mode / case, the default use case can control the format of the RTA-TSPEC. Some fields can be removed from the RTA-TSPEC, including default parameter settings for a specific use case in the RTA-TSPEC element, and some additional fields can be added.

[0108]

[0166] The R-TWT request field is set to indicate whether the AP should schedule an R-TWT SP for traffic transmission of the SCS traffic stream.

[0109]

[0167] If this field is set to "required", the AP must schedule an R-TWT for SCS traffic transmission. If the AP cannot schedule an R-TWT for SCS traffic transmission, it must decline an SCS setup request from a non-AP STA.

[0110]

[0168] If this field is set to "Optional", the AP will attempt to schedule R-TWT for SCS traffic transmissions. The AP may accept SCS membership requests from non-APs even if it is unable to schedule R-TWT SPs for SCS traffic transmissions.

[0111]

[0169] 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 and shall not include a TWT element in the same Modified SCS Descriptor element or the same Modified SCS Status field of the RTA-TSPEC element.

[0112]

[0170] If this field is set to "mandatory" or "optional", a non-AP STA may indicate a TWT setup request by including a TWT element in the same modified SCS descriptor element of the RTA-TSPEC element.

[0113]

[0171] If this field is set to "mandatory" or "optional", in at least one embodiment / mode / case, the non-AP STA does not include any TWT element in the same modified SCS descriptor element of the RTA-TSPEC element, after which the AP can still send the TWT element in its response frame to schedule the R-TWT SP for SCS traffic transmission.

[0114]

[0172] Returning to Figure 24, the RTA Attributes field indicates additional QoS requirements for latency sensitive traffic under this RTA-TSPEC. In at least one embodiment / mode / case, this field appears with or within the TWT element only when the RTA-TSPEC is implemented in both non-AP STAs and the AP.

[0115]

[0173] The reliability field is set by a non-AP STA to indicate the packet loss requirement of latency sensitive traffic under this RTA-TSPEC. Upon receiving this field, the AP should estimate the resource distribution for 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 can be the ratio of packets under this RTA-TSPEC that are not delivered within the bounded latency (or MSDU lifetime). Note that this field can also represent the ratio of packets under this RTA-TSPEC that are delivered within the bounded latency (or MSDU lifetime).

[0116]

[0174] The jitter field is set by a non-AP STA to indicate the jitter requirement of traffic under this RTA-TSPEC. Upon receiving this field, the AP preferably performs a resource distribution estimation for the transmission of traffic under this RTA-TSPEC to ensure that the jitter requirement of traffic under this RTA-TSPEC can be met.

[0117]

[0175] The MSDU Lifetime field indicates the time that an MSDU can be stored in the queue. A non-AP STA sets this field to indicate the MSDU or A-MSDU Lifetime 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, if the MSDU or A-MSDU is not successfully transmitted within the Lifetime, the MSDU or A-MSDU is discarded. When the Deterministic Service field is set to the second state (e.g., "0"), this field is reserved. Note that this field can be replaced by the Delay Bound field in the TSPEC element.

[0118]

[0176] The deterministic service field is set by a non-AP STA to indicate whether to discard MSDUs of traffic under this RTA-TSPEC when their lifetime expires. If a non-AP STA sets this field to a first state (e.g., "1"), MSDUs or A-MSDUs of traffic under this RTA-TSPEC are discarded when their lifetime expires. Otherwise, the non-AP STA sets this field to a second state (e.g., "0"). When an AP receives this field with a value of "1", MSDUs of traffic under this RTA-TSPEC are discarded when their lifetime expires. When an AP receives this field set to "0", there is no lifetime of MSDUs of traffic under this RTA-TSPEC. Note that if the value of the MSDU lifetime field, e.g., "0", indicates that the MSDU lifetime is not specified, this field is unnecessary and MSDUs of traffic under this RTA-TSPEC are not discarded due to the expiration of the MSDU lifetime.

[0119]

[0177] FIG. 27 illustrates an example embodiment 230 of a modified SCS status field for an SCS as indicated in the SCS ID field. The modified SCS status field can carry an R-TWT setup response to the SCS's traffic transmission indicated in the SCS. The modifications of the modified SCS status field compared to that shown in FIG. 14 are described below. Fields without any description below are the same as those in FIG. 1 or are reserved. The fields of the SCS status are as follows:

[0120]

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

[0121]

[0179] The TCLAS, TCLAS-Processing, and RTA-TSPEC fields are set to indicate the proposed parameters in those fields when the AP rejects an SCS setup request by a non-AP STA. The non-AP STA can retransmit the SCS setup request using the proposed parameters. If the AP accepts the SCS setup, it can either duplicate the parameters from those fields received from the SCS setup request or decide not to include those fields in the SCS status field.

[0122]

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

[0123]

[0181] If the TWT request is accepted, the non-AP STA should follow the R-TWT scheduling as indicated in the TWT element for the SCS's traffic transmission.

[0124]

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

[0125]

[0183] In at least one embodiment / mode / case, the AP adds more than one modified TWT element to one modified SCS status element to schedule multiple R-TWTs for traffic transmissions of the SCS traffic stream. In at least one embodiment / mode / case, if one modified TWT element is set to accept the TWT setup, other modified TWT elements in the same SCS status element must also be set to accept the TWT setup.

[0126]

[0184] It should be noted that the result of the SCS setup (eg, acceptance or rejection of the SCS setup) is reported in the status field in the modified SCS status, as in FIG.

[0127]

[0185] Figure 28 illustrates an example embodiment 250 of a modified TWT element. All fields in the modified TWT element may be the same as in the TWT element as shown in Figure 5, except for the addition of a Link ID field to each (modified) Broadcast TWT Parameter Set field. Note that the modified Broadcast TWT Parameter Set fields may be used in TWT signaling as shown in Figure 15.

[0128]

[0186] The link ID field is set to indicate the link on which the TWT information indicated in the corresponding broadcast TWT parameter set field takes effect. For example, when the link ID in the modified broadcast TWT parameter set field is set to link 2, the modified broadcast TWT parameter set field takes effect on link 2.

[0129]

[0187] When setting parameters in the Broadcast TWT Parameter Sets field, the parameter settings can be based on the time reference of the link indicated in the Link ID field. For example, when the Link ID in the Modified Broadcast TWT Parameter Sets field is set to Link 2 and the Modified Broadcast TWT Parameter Sets field is transmitted over Link 1, the Target Wake Time field can be set to the Timing Synchronization Function (TSF) time of the non-AP STAs (or AP) on Link 2, at which time the non-AP STAs on Link 2 are instructed to wake up.

[0130]

[0188] The TWT parameter information field can have multiple modified broadcast TWT parameter set fields. In some examples, the broadcast TWT parameter set fields can have different TWT IDs. Each broadcast TWT parameter set field represents a TWT setup command for an independent TWT.

[0131]

[0189] It is also possible to allow several broadcast TWT parameter set fields to share the same TWT ID but use different link IDs. This can be used to indicate TWTs with SPs scheduled during the same period on different links (i.e. TWTs SPs on different links start and end at the same time). In this case, the TWT ID can be managed by the AP at the MLD level. That is, if there is a TWT created by the AP MLD with TWT ID 3 only on link 1, there should not be another TWT with TWT ID 3 on other links in the same AP MLD. Note that TWT ID 0 can be an exception.

[0132]

[0190] It should also be understood that the trigger field in the request type field in the broadcast TWT parameter information field as shown in FIG. 8 can be different when present in the modified broadcast TWT parameter set field. This field indicates that the R-TWT SP is a triggerable R-TWT SP when set to a first state (e.g., "1") in the modified broadcast TWT parameter set field of the R-TWT. During a triggerable R-TWT SP scheduled in the modified broadcast TWT parameter set field, non-AP STAs that are not members of the R-TWT SP are not allowed to contend for the channel during the R-TWT SP when they receive this field, if the field specifies that only DL transmissions and trigger-based UL transmissions are allowed between the AP and non-AP STAs (in this case, non-AP STAs associated with the AP and members of the R-TWT) during the R-TWT SP. Thus, only APs are allowed to contend for the channel during the R-TWT SP, and members of the R-TWT are not allowed. Note that non-AP STAs that do not support R-TWT operation are not forced to follow this rule. On the other hand, this field can be set to a second state (e.g., "0") to allow any number of R-TWTs to contend for the channel to initiate UL transmission during the R-TWT SP. Note that this field can contain a new field instead of reusing the Trigger field in the Request Type field.

[0133]

[0191] In at least one embodiment, an AP or AP MLD can assign distinct TWT IDs to its broadcast TWTs and R-TWTs, i.e., if an AP creates a broadcast TWT with TWT ID 1, it should not assign TWT ID 1 to another R-TWT and vice versa.

[0134]

[0192] It should be understood that the Broadcast TWT Parameter Set field can be replaced by any type of TWT parameter set field, for example, a dedicated TWT parameter set field for dedicated TWT signaling. Also, the dedicated TWT parameter set field appended (modified) with the Link ID field represents a dedicated TWT parameter set for the link indicated in the Link ID field. The time setting (e.g., target wake time) in the dedicated TWT parameter set field is set based on the TSF time on the link indicated in the Link ID field.

[0135] 3.3.3. Example of setting up R-TWT SP during SCS setup

[0194] This section provides some examples of setting up an R-TWT SP during the SCS setup procedure.

[0136]

[0195] Table 1 shows details about three SCS traffic streams (SCS1, SCS2, and SCS3) in the R-TWT scheduling AP for the examples shown in FIGS.

[0137]

[0196] In SCS1, the SCSID is set to a 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.

[0138]

[0197] For 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 on link 1.

[0139]

[0198] For 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 on link 2.

[0140]

[0199] It should be understood that the SCSID can be mapped to a TID that is linked to the TWT. Also, note that TID 0 to TID 7 can be the same as UP 0 to UP 7.

[0141]

[0200] Table 2 shows details about other TWTs scheduled by AP MLD1, of which MLD3 is a member. The SPs of those TWTs are scheduled on Link 1 and Link 2. Examples of those TWTs are shown in Figures 33 to 36. The example target wait times are R-TWT4, which is a restricted TWT with TWT ID "4", B-TWT5, which is a broadcast TWT with TWT ID "5", and I-TWT6, which includes an individual TWT with TWT ID "6".

[0142]

[0201] 29 illustrates an example embodiment 270 of scheduling R-TWT for SCS traffic streams during the SCS setup procedure. The figure shows communication between AP1 272 in MLD1 and STA1 274 in MLD2.

[0143]

[0202] As shown, initiating an SCS setup (276) including an R-TWT, STA1 sends an SCS request frame (278) to AP1 asking to establish SCS2. The format of the SCS request frame may be the same as that shown in Figure 12, whereby the SCS Descriptor List field in the SCS request frame may carry a modified SCS Descriptor element (shown in Figure 23) for SCS2.

[0144]

[0203] 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. STA1 may then include a modified TWT element in the modified SCS descriptor element of SCS2 to indicate an R-TWT membership request for R-TWT1. It is also possible that STA1 is allowed to not include the modified TWT element in the SCS descriptor element of SCS2. If the modified TWT element is included, example parameter settings in the modified TWT element may be as described below.

[0145]

[0204] The Negotiation Type subfield in the Control field of the modified TWT element is set to "3" to indicate that it is for providing membership management. The modified Broadcast Parameter Set field may be used in the TWT element, whereby the Broadcast TWT ID field in the Broadcast TWT Information field in the modified Broadcast Parameter Set field is set to the TWT ID of R-TWT1 to indicate that the modified Broadcast Parameter Set field is for R-TWT1.

[0146]

[0205] The Request subfield in 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 in the Request Type field in the Modified Broadcast Parameter Set field of R-TWT1 is set to “Request TWT”, “Suggest TWT”, or “Demand TWT” to indicate that STA1 requests R-TWT1 membership including a set of proposed TWT parameters in the Modified Broadcast Parameter Set field for R-TWT1.

[0147]

[0206] Set the Broadcast TWT Recommendation subfield in the Request Type field in the Modified Broadcast Parameter Set field of R-TWT1 to "4" to indicate that the request is for an R-TWT. Set the Target Wake Time field in the Modified Broadcast Parameter Set field of R-TWT1 to the TSF time on link 1 at which STA1 proposes to start the first R-TWT1 SP for SCS2. Non-AP STAs may set it to zero to allow the AP to decide. Set the TWT Wake Interval Mantissa and TWT Wake Interval Exponent fields in the Modified Broadcast Parameter Set field of R-TWT1 to the interval between R-TWT1 SPs proposed by STA1. Non-AP STAs may set it to zero to allow the AP to decide.

[0148]

[0207] Set the Nominal Minimum TWT Wake Duration field in the Modified Broadcast Parameter Set field of R-TWT1 to one R-TWT1 SP time proposed by STA1. Non-AP STAs can set it to zero and let the AP decide. Set the Link ID subfield in the Modified Broadcast Parameter Set field to Link 1.

[0149]

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

[0150]

[0209] The Negotiation Type subfield in the Control field of the TWT element is set to "3" to indicate that it is for membership management.

[0151]

[0210] In the modified TWT element, a modified broadcast parameter set field may be used, whereby the Broadcast TWT ID field in the Broadcast TWT Information field in the modified broadcast parameter set field is set to the TWT ID of R-TWT1 to indicate that the modified broadcast parameter set field is for R-TWT1.

[0152]

[0211] The request subfield in 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 is for responding to R-TWT1’s membership request.

[0153]

[0212] The TWT Setup Command subfield in the Request Type field in the Modified Broadcast Parameter Set field of R-TWT1 is set to "Accept TWT" to indicate that AP1 accepts R-TWT1's membership request.

[0154]

[0213] Set the TWT Broadcast TWT Recommendation subfield in the Request Type field in the modified broadcast parameter set field of R-TWT1 to indicate that the response is for R-TWT. Set the Target Wake Time field in the modified broadcast parameter set field of R-TWT1 to the TSF time on link 1 to initiate the first R-TWT1 SP for SCS2 at that time. Set the TWT Wake Interval Mantissa and TWT Wake Interval Exponent fields in the modified broadcast parameter set field of R-TWT1 to the interval between R-TWT1 SPs.

[0155]

[0214] 1. Set the Nominal Minimum TWT Wake Duration field in the Modified Broadcast Parameter Set field of R-TWT1 to one R-TWT1 SP time. Set the Link ID subfield in the Modified Broadcast Parameter Set field of R-TWT1 to Link 1. The figure shows an example of a triggerable R-TWT1 SP (282). AP1 can obtain channel access to the R-TWT1 SP (284) and begin transmitting DL PPDUs (288) and (292) carrying the SCS2 traffic stream to STA1 during the R-TWT1 SP and receive acknowledgments (e.g., Block Acknowledgements (BA)) (290) and (294).

[0156]

[0215] In some examples, the R-TWT SP Time should not be greater than the transmission time required by the SCS traffic stream that is scheduled to transmit during the R-TWT SP. For example, in this case, if STA1 is the only member of the R-TWT1 SP to transmit the SCS2 traffic stream, the R-TWT1 SP Time should be equal to the transmission time required by the SCS2 traffic stream. For example, the R-TWT1 SP Time per second should be equal to the medium time indicated in the RTA-TSPEC element during SCS2 setup.

[0157]

[0216] If one and only one R-TWT is scheduled for traffic transmission for an SCS, the R-TWT interval (286) (the interval between two consecutive SPs of the same R-TWT) should be between the minimum and maximum service intervals for that SCS (indicated in the RTA-TSPEC element during SCS setup). For example, interval = (minimum service interval + maximum service interval) / 2. As shown in the figure, the R-TWT1 interval (the interval between R-TWT1 SPs) should be between the minimum and maximum service intervals for SCS2. The figure shows the interval (286) between an R-TWT1 SP (284) and a subsequent R-TWT1 SP (296).

[0158]

[0217] 30 illustrates an example embodiment 310 illustrating the case where R-TWT is not scheduled for SCS traffic streams during the SCS setup procedure. The figure shows communication between AP1 272 in MLD1 and STA1 274 in MLD2.

[0159]

[0218] The figure shows the use of separate SCS setup and R-TWT setup (312). STA1 sends an SCS request frame (314) to AP1 asking it to establish SCS2. The format of the SCS request frame may be the same as that shown in Figure 12, whereby the SCS descriptor element for SCS2 in the frame may be as shown in Figure 23.

[0160]

[0219] STA1 may 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", it may include a modified TWT element in the modified SCS descriptor element of SCS2 to indicate an R-TWT membership request for R-TWT1 or other R-TWTs.

[0161]

[0220] In some cases, STA1 may not include a modified TWT element in the modified SCS descriptor element of SCS2. Note that if the R-TWT requirement field is set to "not required", the SCS descriptor element does not include a modified TWT element. If the R-TWT requirement field is set to "optional" and the SCS descriptor element of SCS2 includes a modified TWT element, the parameters in the modified TWT element may be set as described below.

[0162]

[0221] The Negotiation Type subfield in the Control field of the TWT element may be set to "3" to indicate that it is for membership management.

[0163]

[0222] Within the modified TWT element, a modified broadcast parameter set field may be present, whereby the Broadcast TWT ID field within the Broadcast TWT Information field within the modified broadcast parameter set field is set to the TWT ID of R-TWT1 to indicate that the modified broadcast parameter set field is for R-TWT1.

[0164]

[0223] The request subfield in 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 is for responding to R-TWT1’s membership request.

[0165]

[0224] 1. Set the TWT Setup Command subfield in the Request Type field in the modified broadcast parameter set field of R-TWT1 to “Accept TWT” to indicate that AP1 accepts the R-TWT1 membership request. Set the TWT Broadcast TWT Recommendation subfield in the Request Type field in the modified broadcast parameter set field of R-TWT1 to indicate that the response is for R-TWT. Set the Target Wake Time field in the modified broadcast parameter set field of R-TWT1 to the TSF time on link 1 to initiate the first R-TWT1 SP for SCS2 at that time. Set the TWT Wake Interval Mantissa and TWT Wake Interval Exponent fields in the modified broadcast parameter set field of R-TWT1 to the interval between R-TWT1 SPs. Set the Nominal Minimum TWT Wake Duration field in the modified broadcast parameter set field of R-TWT1 to one R-TWT1 SP time. Set the Link ID subfield in the modified broadcast parameter set field of R-TWT1 to link 1.

[0166]

[0225] When AP1 receives the SCS request frame from STA1, it can decide whether to accept the request and send back an SCS response frame. The format of the SCS response frame (316) can be the same as that shown in Figure 14, whereby the SCS status list field in the frame carries the modified SCS status field of SCS2 as shown in Figure 27. The SCS status field of SCS2 can include a modified TWT element to indicate the R-TWT setup result for the SCS1 traffic stream if STA1 requested the setup of R-TWT for SCS2.

[0167]

[0226] In this example, the AP accepts the SCS request but does not schedule an R-TWT for transmission of the SCS2 traffic stream at that time, for example, as illustrated in the following scenario:

[0168]

[0227] STA1 requests membership in an R-TWT other than R-TWT1, but AP1 does not accept the membership request. Instead, AP1 sends an SCS response frame including a TWT element back to STA1 to suggest that AP1 request membership for R-TWT1. The parameter settings in the modified TWT element can be as described below.

[0169]

[0228] The Negotiation Type subfield in the Control field of the TWT element may be set to "3" to indicate that it is for membership management purposes. In the modified TWT element, there may be a modified Broadcast Parameter Set field whereby the Broadcast TWT ID field in the Broadcast TWT Information field in the Broadcast Parameter Set field is set to the TWT ID of R-TWT1 to indicate that the Broadcast Parameter Set field is for R-TWT1. The Request subfield in 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 to SCS2. The TWT Setup Command subfield in the Request Type field in the modified Broadcast Parameter Set field of R-TWT1 is set to "Dictate TWT" to indicate that AP1 does not accept the R-TWT1 membership request to SCS2, but the parameters in the modified Broadcast Parameter Set field include proposed parameters for retransmitting the R-TWT setup request. 1. Set the TWT Broadcast TWT Recommendation subfield in the Request Type field in the Modified Broadcast Parameter Set field of R-TWT1 to indicate that R-TWT1 is an R-TWT. 2. Set the Target Wake Time field in the Broadcast Parameter Set field of R-TWT1 to the TSF time on link 1 to initiate the first R-TWT1 SP to SCS2 at that time. 3. Set the TWT Wake Interval Mantissa and TWT Wake Interval Exponent fields in the Broadcast Parameter Set field of R-TWT1 to the interval between R-TWT1 SPs. 4. Set the Nominal Minimum TWT Wake Duration field in the Broadcast Parameter Set field of R-TWT1 to one R-TWT1 SP time.

[0170]

[0229] After successful establishment of SCS2, STA1 may send a TWT setup frame to request membership of an R-TWT, such as R-TWT1 (318). AP1 may then decide to accept or reject the request as specified in IEEE 802.11ax. The format of the TWT setup frame may be the same as that shown in FIG. 16, whereby the format of the TWT elements in the frame may be as shown in FIG. 28. It should be understood that the R-TWT setup (R-TWT request (318) and R-TWT response (320)) may be performed independently at any time.

[0171]

[0230] An example of a triggerable R-TWT1 SP is shown in the figure, in which AP1 is shown obtaining channel access for a first R-TWT1 SP (282) for SCS2, initiating an R-TWT1 SP (284), transmitting DL PPDUs (288) and (292) carrying the SCS2 traffic stream to STA1 during the R-TWT1 SP, and receiving BAs (290) and (294) from STA1.

[0172]

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

[0173]

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

[0174]

[0233] 31 illustrates an example embodiment 350 of scheduling multiple R-TWTs for one SCS traffic stream during the SCS setup procedure. The figure shows communication between AP1 352, STA2 354 in MLD1, and STA1 356 in MLD2.

[0175]

[0234] As shown, having performed an SCS setup (358) including an R-TWT, STA2 sends an SCS request frame (360) to AP1 to ask for establishing SCS1. The format of the SCS request frame may be the same as that shown in Figure 12, whereby the SCS Descriptor List field in the frame may carry a modified SCS Descriptor element for SCS1 as shown in Figure 23.

[0176]

[0235] STA2 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 SCS1 in the SCS request frame. STA2 may then include a modified TWT element in the modified SCS descriptor element of SCS1 that includes multiple broadcast TWT parameter set fields (one field for R-TWT1 and another field for R-TWT3) to indicate an 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.

[0177]

[0236] When AP1 receives the SCS request frame from STA2, it can determine whether to accept the request. In this example, AP1 accepts the SCS request and schedules R-TWT1 and R-TWT3 for transmission of the SCS1 traffic stream. AP1 sends an SCS response frame (362) back to STA2. The format of the SCS response frame can be the same as that shown in FIG. 14, whereby the SCS status list field in the frame carries a modified SCS status field for SCS1 as shown in FIG. 27. The modified SCS status field for SCS1 includes a modified TWT element that includes multiple modified broadcast TWT parameter set fields (one field for R-TWT1 and the other field for R-TWT3) to indicate that R-TWT1 and R-TWT3 are scheduled to transmit the SCS1 traffic stream.

[0178]

[0237] The figure shows an example of a triggerable R-TWT1 SP (364). In this example, STA2 and STA1 are members of R-TWT1 and schedule their traffic transmissions for SCS1 and SCS2 to transmit during the R-TWT1 SP. AP1 gets channel access and sends a Buffer Status Report Poll (BSRP) frame (368) to STA2 requesting STA2's buffer status. STA2 reports its buffer status by sending back a Buffer Status Report (BSR) frame (370). AP1 then first sends a DL PPDU (372) carrying the SCS2 traffic stream to STA1 during the R-TWT1 SP. This can be done because the UP for SCS2 is a higher priority than the UP for SCS1. STA1 responds with a block acknowledgement (374). AP1 then sends a trigger frame (376) to STA2 to trigger a UL transmission (378) for the SCS1 traffic stream according to the buffer status of the SCS1 traffic stream, and AP1 responds with a BA (380) to terminate the first R-TWT3 SP (365) for SCS1.

[0179]

[0238] Similarly, upon initiation of the R-TWT3 SP (382), AP1 schedules the UL transmission of the SCS1 traffic stream during the R-TWT3 SP. As shown, AP1 sends a BSRP (384) to STA2 to receive a BSR (386) back from STA2, after which AP1 generates a basic trigger (388) to trigger STA2 to later transmit a UL PPDU (390).

[0180]

[0239] In many instances, the R-TWT SP Time should not be greater than the transmission time required by the SCS traffic streams that are scheduled to transmit during the R-TWT SP. For example, in this case, if STA1 and STA2 are members of the R-TWT1 SP for transmitting SCS2 and SCS1 traffic streams, the R-TWT1 SP Time should be equal to the transmission time required by the SCS2 and SCS1 traffic streams. For example, the R-TWT1 SP Time per second should be equal to the sum of the medium times indicated in the RTA-TSPEC elements during SCS2 and SCS1 setup.

[0181]

[0240] When multiple R-TWTs are scheduled for traffic transmission of an SCS, the R-TWT SPs should be scheduled for time intervals set between the minimum and maximum service intervals (indicated in the RTA-TSPEC element during SCS setup) of that SCS. As shown in the figure, the interval (392) between two consecutive R-TWT SPs (here shown as R-TWT1 and R-TWT3) (even if the two SPs are from different R-TWTs) should be between the minimum and maximum service intervals of SCS1. For example, the interval of R-TWT1 = the interval of R-TWT3 = (minimum service interval of SCS1 + maximum service interval of SCS1). The interval between R-TWT1 SP and its neighbor R-TWT3 SP is between the minimum and maximum service intervals of SCS1, for example (minimum service interval of SCS1 + maximum service interval of SCS1) / 2. Note that SCS2 is established as shown in Figure 29 or Figure 30.

[0182]

[0241] 32 illustrates an example embodiment 410 of an SCS setup procedure for setting up R-TWTs on other links for transmission of SCS traffic streams. The figure shows both sides 412, 413 of a 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.

[0183]

[0242] As shown, STA3 sends an SCS request frame (416) to AP1 448 to ask for establishment of SCS3 in an SCS+R-TWT setup process (414). The format of the SCS request frame may be the same as that shown in Figure 12, whereby the SCS Descriptor List field in the frame carries an SCS Descriptor element for SCS3 as shown in Figure 23.

[0184]

[0243] STA3 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 SCS3 in the SCS request frame. STA3 may then include a modified TWT element in the modified SCS descriptor element of SCS3 to indicate an 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. If a modified TWT element is included, an example of parameter settings in the modified TWT element for an R-TWT2 setup request may be as shown below:

[0185]

[0244] 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. In the TWT element, a modified Broadcast Parameter Set field may be present, whereby the Broadcast TWT ID field in the Broadcast TWT Information field in the modified Broadcast Parameter Set field is set to the TWT ID of R-TWT2 to indicate that the modified Broadcast Parameter Set field is for R-TWT2.

[0186]

[0245] The Request subfield in the Request Type field in the Modified Broadcast Parameter Set field of R-TWT2 is set to a first state (e.g., “1”) to indicate an R-TWT2 membership request. The TWT Setup Command subfield in the Request Type field in the Modified Broadcast Parameter Set field of R-TWT2 is set to “Request TWT”, “Suggest TWT”, or “Demand TWT” to indicate that MLD3 requests R-TWT2 membership including a set of suggested TWT parameters in the Modified Broadcast Parameter Set field for R-TWT2. The TWT Broadcast TWT Recommendation subfield in the Request Type field in the Modified Broadcast Parameter Set field of R-TWT2 is set to “4” to indicate that the request is for an R-TWT. The Target Wake Time field in the Modified Broadcast Parameter Set field of R-TWT2 is set to the TSF time on link 2 at which STA5 proposes to initiate the first R-TWT2 SP to SCS3. Non-AP STAs can set it to zero and let the AP decide.

[0187]

[0246] Set the TWT Wake Interval Mantissa and TWT Wake Interval Exponent fields in the Modified Broadcast Parameter Set field of R-TWT2 to the interval between R-TWT2 SPs proposed by MLD3. Non-AP STAs may also set it to zero to let the AP determine the interval.

[0188]

[0247] Set the Nominal Minimum TWT Wake Duration field in the Modified Broadcast Parameter Set field of R-TWT2 to one R-TWT2 SP time suggested by MLD3. Non-AP STAs can set it to zero and let the AP decide. Set the Link ID subfield in the Modified Broadcast Parameter Set field to Link 2.

[0189]

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

[0190]

[0249] The Negotiation Type subfield in the Control field of the TWT element is set to "3" to indicate that it is for membership management. The presence of the Modified Broadcast Parameter Set field in the Modified TWT element sets the Broadcast TWT ID field in the Broadcast TWT Information field in the Modified Broadcast Parameter Set field to the TWT ID of R-TWT2 to indicate that the Modified Broadcast Parameter Set field is for R-TWT2.

[0191]

[0250] Set the Request subfield in the Request Type field in the modified broadcast parameter set field of R-TWT2 to a second state (e.g., “0”) to indicate that the modified broadcast parameter set field is for responding to the R-TWT2 membership request. Set the TWT Setup Command subfield in the Request Type field in the modified broadcast parameter set field of R-TWT2 to “Accept TWT” to indicate that MLD1 accepts the R-TWT2 membership request. Set the TWT Broadcast TWT Recommendation subfield in the Request Type field in the modified broadcast parameter set field of R-TWT2 to indicate that the response is for R-TWT.

[0192]

[0251] 1. Set the Target Wake Time field in the modified broadcast parameter set field of R-TWT2 to the TSF time on link 2 and initiate the first R-TWT2 SP to SCS3 at that time. 2. Set the TWT Wake Interval Mantissa and TWT Wake Interval Exponent fields in the modified broadcast parameter set field of R-TWT2 to the interval between R-TWT2 SPs. 3. Set the Nominal Minimum TWT Wake Duration field in the modified broadcast parameter set field of R-TWT2 to one R-TWT2 SP time. 4. Set the Link ID subfield of the modified broadcast parameter set field of R-TWT2 to link 2.

[0193]

[0252] The figure shows an example of a triggerable R-TWT2 SP (420). AP2 450 is able to obtain channel access in the interval between R-TWT2 SPs (424) and begins transmitting DL PPDUs (428), (432) carrying the SCS3 traffic stream to STA5 during the R-TWT2 SP (426). STA5 responds to the PPDUs with BAs (430) and (434).

[0194]

[0253] As shown, after the interval between R-TWT2 SPs, another R-TWT2 SP (436) begins.

[0195]

[0254] 33 illustrates an example embodiment 470 of an R-TWT setup procedure (484) for setting up R-TWTs on multiple links using modified TWT elements on one link. The figure shows communication 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.

[0196]

[0255] As shown, STA3 sends an R-TWT request (setup) frame (486) to AP1 on link 1 to request membership in R-TWT4, which is an R-TWT in which an SP is scheduled over multiple different links. The format of the TWT request frame may be the same as that shown in FIG. 16, whereby the TWT elements in the frame may be as shown in FIG. 28.

[0197]

[0256] The R-TWT request frame (486) may carry multiple modified broadcast TWT parameter sets fields of R-TWT4 in the TWT parameter information field in one TWT element to indicate that the SP is a membership request for R-TWT4s to be scheduled on multiple different links. The link ID field in the modified broadcast TWT parameter sets field of the R-TWT4 indicates the link on which the R-TWT4 scheduling indicated in the modified broadcast TWT parameter sets field is proposed to be scheduled. The target wake time field in the modified broadcast TWT parameter sets field of the 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 sets field of the R-TWT4. The TWT wake interval and nominal minimum TWT wake duration may be set the same in all modified broadcast TWT parameter sets fields. Also, the TWT setup command field in the request type field of all broadcast TWT parameter sets fields of the R-TWT4 is set to the same value.

[0198]

[0257] When AP1 receives the 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 back an R-TWT response frame (488) to STA3. The format of the R-TWT setup (response) frame can be the same as that shown in FIG. 16, whereby the TWT elements in the frame can be as shown in FIG. 28. The TWT parameter information field in one TWT element can include multiple modified broadcast TWT parameter set fields of R-TWT4 to indicate a membership response of R-TWT4. The target wake time field in the modified broadcast TWT parameter set field 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 field. For example, as shown in the figure, the target wake time field (490) in the modified broadcast TWT parameter set field of the R-TWT4 on link 1 should be set to the TSF time of link 1 initiating the first R-TWT4 SP on link 1. The target wake time field (492) in the modified broadcast TWT parameter set field of the R-TWT4 on link 2 is preferably set to the TSF time of link 2 initiating the first R-TWT4 SP on link 2. The TWT wake interval and nominal minimum TWT wake duration are preferably set the same in all modified broadcast TWT parameter set fields of the R-TWT4. Also, the TWT setup command field in the request type field of all modified broadcast TWT parameter set fields of the R-TWT4 are set to the same value.

[0199]

[0258] The figure shows an example of a triggerable R-TWT4 SP. AP1 and AP2 can obtain channel access at the R-TWT4 SP (496) as illustrated in the figure, and during the R-TWT4 SP, start transmitting DL PPDUs (498), (500), (506), and (508) simultaneously to STA3 and STA5 on both Link1 and Link2, and respond back to the AP with BAs (502), (504), (510), and (512).

[0200]

[0259] The figure also shows the spacing (494) between R-TWT4 SPs and indicates where to start the next R-TWT4 SP (514).

[0201]

[0260] 34 illustrates an example embodiment 530 of a broadcast TWT setup procedure that uses modified TWT elements on one link to set up a broadcast TWT on multiple links. The figure shows communication 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.

[0202]

[0261] As shown, during B-TWT setup (532), STA3 sends a B-TWT request (setup) frame (534) to AP1 on link 1 to request membership in B-TWT5. B-TWT5 is a broadcast TWT where the SP is scheduled over multiple different links. The format of the TWT request frame may be the same as that shown in FIG. 16, whereby the TWT elements in the frame may be as shown in FIG. 28.

[0203]

[0262] The B-TWT request frame (534) may incorporate multiple modified broadcast TWT parameter sets fields of B-TWT5 in a TWT parameter information field within one TWT element to indicate that the SP is requesting membership for B-TWT5 to be scheduled on multiple different links. The link ID field in the modified broadcast TWT parameter sets field of B-TWT5 indicates the link on which B-TWT5 scheduling is indicated in the modified broadcast TWT parameter sets field as proposed to be scheduled. The target wake time field in the modified broadcast TWT parameter sets 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 sets field of B-TWT5. The TWT wake interval and nominal minimum TWT wake duration may be set the same in all modified broadcast TWT parameter sets fields of B-TWT5. Also, the TWT setup command field in the request type field of all broadcast TWT parameter sets fields of B-TWT5 is set to the same value.

[0204]

[0263] When AP1 receives the B-TWT request frame from STA3, it can determine 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 can be the same as that shown in FIG. 16, whereby the TWT elements in the frame can be as shown in FIG. 28.

[0205]

[0264] In the TWT parameter information field in one TWT element, multiple modified broadcast TWT parameter set fields of B-TWT5 may be present to indicate a membership response of B-TWT5. The target wake time field in the modified broadcast TWT parameter set field 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 in the modified broadcast TWT parameter set field. The TWT wake interval and nominal minimum TWT wake duration may be set to the same value in all modified broadcast TWT parameter set fields of B-TWT5. Also, the TWT setup command field in the request type field of all modified broadcast TWT parameter set fields of B-TWT5 is set to the same value.

[0206]

[0265] The figure shows an example of B-TWT5 SP (542), (544). In this example, AP1 and AP2 are shown obtaining channel access and transmitting DL PPDUs (546), (548), (554), and (556) simultaneously to STA3 and STA5 on both Link1 and Link2 during the B-TWT5 SP.

[0207]

[0266] The figure also shows the spacing (542) between B-TWT4 SPs, and indicates where to start the next B-TWT4 SP (562).

[0208]

[0267] 35 illustrates an example embodiment 590 of wake TBTT and wake interval negotiation using modified TWT elements. The figure shows communication 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.

[0209]

[0268] As shown, during TBTT negotiation (592), STA3 sends a TWT request (setup) frame (594) to AP1 on link 1 to request negotiation of wake TBTT and wake interval on link 1 and link 2. The format of the TWT request frame may be the same as that shown in FIG. 16, whereby the modified TWT element in the frame may be as shown in FIG. 27, except that the Broadcast TWT Parameter Set field of FIG. 28 is replaced with an Individual TWT Parameter Set field as specified in IEEE 802.11ax. The negotiation type field of the control field of the modified TWT element is set to a first state (e.g., "1") to indicate a negotiation of wake TBTT and wake interval.

[0210]

[0269] The TWT request frame (594) may carry multiple modified individual TWT parameter set fields (one modified individual TWT parameter set field carries one individual TWT parameter set field as specified in IEEE 802.11ax and one Link ID field) in the modified TWT parameter information field in the TWT element to indicate negotiation of wake TBTT and wake interval on multiple links. The Link ID field in each modified individual TWT parameter set field indicates the link on which the parameters in the same modified individual TWT parameter set field are proposed to be set by the non-AP. 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.

[0211]

[0270] When AP1 receives the TWT request (setup) frame from STA3, it decides 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 can be the same as that shown in FIG. 16, whereby the TWT element in the frame can be similar to that in FIG. 28, except that the Broadcast TWT Parameter Set field in FIG. 28 is replaced with an Individual TWT Parameter Set field as specified in IEEE 802.11ax. The Negotiation Type field in the control field of the modified TWT element is set to a first state (e.g., “1”) to indicate a negotiation of the wake TBTT and wake interval. The TWT Response frame may carry multiple modified individual TWT parameter set fields in the TWT parameter information field in the modified TWT element (one modified individual TWT parameter set field carries one individual TWT parameter set field as specified in IEEE 802.11ax and one Link ID field) to indicate negotiation of wake TBTT and wake interval on multiple links. The Link ID field in each modified individual TWT parameter set field indicates the link on which the parameters in the same modified individual TWT parameter set field are set by the AP and on which non-AP STAs are 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.

[0212]

[0271] The first TBTT (598) on link 1, set to the target wake time (TWT), indicates the time when STA3 needs to wake up (request 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 in the modified individual TWT parameter set field that includes 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). It can be seen that after the TBTT (598), it starts the listen interval (606) for the beacon (B-TWT IE) (608).

[0213]

[0272] The first TBTT (600) on link 2, set to the target wake time, indicates the time when STA5 needs to wake up (request 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 in the modified individual TWT parameter set field that includes the link ID field set for 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 can be seen that after the TBTT (608), it starts the listen interval (602) for the beacon (B-TWT IE) (604).

[0214]

[0273] The figure shows an example of a triggerable B-TWT4 SP (610). In this example, AP1 and AP2 can obtain channel access and send trigger frames (612) and (614) (e.g., basic trigger frames or UAPSD triggers) to STA3 and STA5, respectively. STA3 and STA5 then send back PS-Poll frames (616) and (618) to indicate that STA3 and STA5 are awake and ready to receive traffic. AP1 and AP2 then send acknowledgement BA (multi-user BA or Ack) (620) and (622) to begin sending DL MU PPDUs (624), (626) to STA3 and STA5, respectively, during the R-TWT2 SP and receive acknowledgement (BA) (628) and (630) from the APs.

[0215]

[0274] Note that during the channel time between the beacon (B-TWT IE) on a link and the trigger frame, STAs on that link can go to sleep, as illustrated by beacons (632), (634), (636), and (638).

[0216]

[0275] 36 illustrates an example embodiment 650 of an individual TWT setup using modified TWT elements. The figure shows communication 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.

[0217]

[0276] As shown, during I-TWT setup (652), STA3 sends a TWT request (setup) frame (654) to AP1 on link 1 to request individual TWT setup on link 1 and link 2. The format of the TWT request frame may be the same as that shown in FIG. 16, whereby the modified TWT element in the frame may be as shown in FIG. 28, except that the broadcast TWT parameter set field of FIG. 28 is replaced with an individual TWT parameter set field as specified in IEEE 802.11ax. The negotiation type field in the control field of the modified TWT element is set to a second state (e.g., "0") to indicate an individual TWT setup negotiation.

[0218]

[0277] The TWT request frame may carry multiple modified individual TWT parameter set fields (one modified individual TWT parameter set field carries one individual TWT parameter set field as specified in IEEE 802.11ax and one Link ID field) in the modified TWT parameter information field in the TWT element to indicate negotiation of individual TWTs (denoted as I-TWT6) on multiple links. The Link ID field in each modified individual TWT parameter set field indicates the link on which the parameters in the same modified individual TWT parameter set field are proposed by the non-AP. 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.

[0219]

[0278] When AP1 receives the 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 can be the same as that shown in FIG. 16, for example, whereby the TWT element in the frame can be similar to that in FIG. 28, except that the broadcast TWT parameter set field in FIG. 28 is replaced with an individual TWT parameter set field as specified in IEEE 802.11ax. The negotiation type field in the control field of the modified TWT element is set to a first state (e.g., “1”) to indicate an individual TWT setup negotiation. The TWT Response frame may carry multiple modified individual TWT parameter set fields in the TWT parameter information field in the modified TWT element (one modified individual TWT parameter set field carries one individual TWT parameter set field as specified in IEEE 802.11ax and one Link ID field) to indicate the negotiation of individual TWT setup on multiple links. The Link ID field in each modified individual TWT parameter set field indicates the link on which the parameters in the same modified individual TWT parameter set field are to be configured by the AP and should be followed by non-AP STAs. 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.

[0220]

[0279] The first TBTT on link 1 set to the target wake time indicates the time STA3 needs to wake up (request wake) for the initiation of the first I-TWT6 SP (658) on link 1. This is set in the target wake time field in the modified individual TWT parameter set field that includes 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).

[0221]

[0280] The first TBTT on link 2 set to the target wake time indicates the time STA5 needs to wake up (request wake) to start the first I-TWT6 SP (660) on link 2. This is set in the target wake time field in the modified individual TWT parameter set field that includes 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).

[0222]

[0281] The figure shows an example of an I-TWT6 SP (661). In this example, AP1 and AP2 can obtain channel access and send trigger frames (662) and (664) (e.g., basic trigger frames or U-APSD triggers) to STA3 and STA5, respectively, as illustrated. STA3 and STA5 then send back PS-Poll frames (666) and (668) to indicate that STA3 and STA5 are awake and ready to receive traffic. AP1 and AP2 then send BAs (670) and (672) for acknowledgement and begin sending DL PPDUs (674) and (676) to STA3 and STA5, respectively, during the R-TWT2 SP, followed by acknowledgements (e.g., BAs) (678) and (680).

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

[0283] This section describes an alternative SCS setup procedure for R-TWT membership that differs from Section 3.3.

[0224]

[0284] In this section, we consider a scenario where the SCS setup involves multi-link (ML) operation, while the R-TWT setup is a link-level operation. Thus, the SCS setup procedure (i.e., the SCS setup frame exchange) can occur over any number of links, while the R-TWT setup procedure (i.e., the R-TWT setup frame exchange) can occur only over the link on which the R-TWT is scheduled.

[0225] 3.4.1. Alternative SCS Setup Procedure Operation

[0286] 37 and 38 show an example embodiment 710 in which a non-AP MLD sends an SCS request frame indicating to the SCS in the frame that R-TWT scheduling is required (requested).

[0226]

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

[0227]

[0288] Next, in block 714, it is determined whether the non-AP MLD received a frame indicating that the AP MLD accepted the SCS request. If the SCS request was not accepted, in block 718, the SCS setup fails and the process ends.

[0228]

[0289] On the other hand, if the SCS setup is accepted, the SCS is successfully established and the non-AP MLD waits for a response from the AP MLD to assign R-TWT membership on any possible link (the link on which the non-AP MLD is associated with the AP MLD) in block 716. Note that the non-AP MLD does not send an R-TWT request frame to the SCS on any link when waiting for a response to the SCS's R-TWT membership.

[0229]

[0290] Next, check 720 of FIG. 38 determines whether a STA associated with a non-AP MLD has received a frame indicating that the AP MLD has accepted membership of the R-TWT.

[0230]

[0291] If the condition is not met, in block 722, the non-AP MLD may send an R-TWT membership request frame for the SCS traffic stream or another SCS request frame (including the R-TWT request). Thus, if the AP MLD accepts the SCS request but the non-AP MLD does not receive a frame allocating R-TWT membership before the timeout, the non-AP MLD may send an R-TWT membership request for the SCS or resend an SCS request frame for the SCS traffic stream. Note that in some cases, the non-AP MLD may resend the SCS request frame through a different link. Also, if the non-AP MLD does not receive a frame indicating that the AP MLD accepted the SCS request (within the timeout), the SCS setup has failed. The non-AP MLD may resend an SCS request frame for the SCS traffic stream according to the current SCS setup rules.

[0231]

[0292] On the other hand, if block 720 determines that the R-TWT membership is accepted, the STA becomes a member STA of the R-TWT (724) and frames from the SCS traffic stream are permitted or prioritized to transmit during the SP of the R-TWT. Note that in at least one embodiment / mode / case, the AP MLD assigns membership 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.

[0232]

[0293] Also, in at least one embodiment / mode / case, frame exchanges of the SCS setup procedure are transmitted, for example, over link 1, while frames allocating R-TWT membership are transmitted over a link other than link 1, for example link 2, link 3, etc.

[0233]

[0294] FIG. 39 illustrates an example embodiment 750 in which an AP MLD sends an SCS response frame to assign membership to an SCS.

[0234]

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

[0235]

[0296] In check 754, it is determined whether the AP MLD accepted the SCS request. If the AP MLD did not accept the SCS request, in block 756, the AP MLD generates an SCS response frame to reject the SCS request. It should be noted that one reason why the AP MLD can reject the SCS is that the AP MLD cannot schedule an R-TWT SP on any link for the SCS traffic stream. The AP MLD can indicate the reason for the rejection in the SCS response frame. For example, the reason can be indicated in a status field as shown in FIG. 14.

[0236]

[0297] On the other hand, if the condition of check 754 is satisfied, the AP MLD responds (758) to the non-AP MLD with an SCS response frame to accept the SCS request. The AP MLD then transmits (760) a frame to assign R-TWT membership on at least one link for the SCS traffic stream within the timeout interval. In at least one embodiment / mode / case, the frame format for assigning R-TWT membership can be the same as IEEE 802.11be (as shown in FIG. 16), whereby the TWT element can be replaced by using a modified format as shown in FIG. 41. It is noted that in certain examples, the AP MLD can assign multiple R-TWT memberships for the same SCS traffic stream. In certain examples, multiple R-TWTs for the same SCS traffic stream can also be allowed to be scheduled on different links.

[0237] 3.4.2. SCS Descriptor Including R-TWT Frame Format

[0299] 40 illustrates an example embodiment 770 of an SCS Descriptor element that includes an R-TWT Request field within a QoS Characteristics element. The fields within the SCS Descriptor element may be the same as those of IEEE 802.11be [P802.11be_D1.31], except that it has one field (e.g., the R-TWT Request field) to indicate whether R-TWT is required for the SCS traffic stream.

[0238]

[0300] The QoS characteristic element field may be the same as specified in IEEE 802.11be, except that at least a new R-TWT request field is added to this element, which may be present in the control information field of the QoS characteristic element.

[0239]

[0301] The R-TWT request field is set by the non-AP MLD to indicate whether R-TWT scheduling is necessary (requested) for the transmission of frames from the SCS traffic stream. This field may contain a one-bit indication. If this field is set to a first state (e.g., "1"), the non-AP MLD requests to schedule an R-TWT SP for the transmission of the SCS traffic stream. If the AP MLD receives this field and accepts the SCS request, it will send an unsolicited TWT response frame to the non-AP MLD to assign R-TWT membership for the transmission of the SCS traffic stream on at least one link within the timeout period, aiming to satisfy the QoS requirement of the SCS traffic stream. It should be noted that the timeout can be predetermined or negotiated by the AP and the non-AP MLD. On the other hand, if this field is set to a second state (e.g., "0"), the AP MLD does not need to schedule an R-TWT SP for the SCS traffic stream. When the non-AP MLD needs to (decides to) schedule an R-TWT SP for an SCS traffic stream, it initiates an R-TWT membership negotiation with the AP MLD over the link.

[0240]

[0302] FIG. 41 illustrates an example embodiment 790 of the modified TWT element seen in FIG. 40. All fields in the modified TWT element may be the same as those in the TWT element as shown in FIG. 5, except that a 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 the membership of a non-AP STA, the SCS traffic stream indicated in the SCSID field of the non-AP STA is given higher priority to transmit during the R-TWT SP indicated in the modified Broadcast TWT Parameter Set field.

[0241] 3.4.3. Example of SCS Setup Requesting R-TWT Scheduling

[0304] This section provides some examples of SCS setup procedures that include requesting R-TWT scheduling.

[0242]

[0305] 42 illustrates an example embodiment 810 of an SCS setup procedure that includes requesting R-TWT scheduling in an example where AP1 schedules an R-TWT SP for an SCSx traffic stream on link 1. The figure illustrates communication 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.

[0243]

[0306] MLD3 intends to set up an SCS traffic stream (denoted SCSx) with MLD1. In this example, SCSx is a DL traffic stream. STA3, associated with MLD3, obtains 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, with its SCS Descriptor List field carrying an SCS Descriptor element as shown in FIG. 40. The SCS Descriptor element includes an indication that an R-TWT is required (requested) for transmission of the SCSx traffic stream.

[0244]

[0307] After receiving the SCS request frame for SCSx, AP1 responds with an SCS response frame (818) and decides to accept the SCSx traffic stream. Upon successful establishment (820) of the SCSx traffic stream, MLD3 starts counting down its backoff (BO) timer (822) to wait for an R-TWT response frame from MLD1 to assign R-TWT membership to the SCSx traffic stream before timing out.

[0245]

[0308] In this example, MLD1 decides to assign membership of R-TWT (denoted as R-TWTy) on link 1 for SCSx traffic stream. AP1, which is associated with MLD1, then transmits an unsolicited TWT response frame (i.e., TWT setup frame) (824) to assign / accept R-TWTy membership for STA3. The frame format of the TWT response frame may be as shown in FIG. 16, which carries modified TWT elements as shown in FIG. 41. The SCSID subfield in the modified broadcast TWT parameter set field that accepts membership of R-TWTy should be set to the SCS ID of SCSx to indicate that this R-TWTy membership is for SCSx.

[0246]

[0309] STA3 then becomes a member STA of the R-TWTy (826) and waits (828) for the first R-TWTy SP (832) where frames of the SCSx traffic stream are allowed to be transmitted or have higher priority for transmission. As shown in the figure, AP1 transmits PPDUs (830), (836) for the SCSx traffic stream during the R-TWTy SP on link 1, and STA3 responds with acknowledgments (BA) (834) and (838).

[0247]

[0310] 43 illustrates an example embodiment 850 of scheduling R-TWT SPs for SCSx traffic streams on different links. The figure shows communication 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.

[0248]

[0311] Compared with 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, while the AP membership assignment for R-TWTy occurs on link 1.

[0249]

[0312] MLD3 intends to set up an SCS traffic stream (denoted 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 sends an SCS request frame (854) to AP2 to set up the SCSx traffic stream. The format of the SCS request frame may be as shown in FIG. 11, with its SCS Descriptor List field carrying an SCS Descriptor element as shown in FIG. 40. Within the SCS Descriptor element there is an indication that an R-TWT is required (requested) for transmission of the SCSx traffic stream.

[0250]

[0313] After receiving the SCS request frame for SCSx, AP2 decides to accept the SCSx traffic stream by responding with an SCS response frame (856). With the SCSx traffic stream successfully established (858), MLD3 waits for an R-TWT response frame (862) from MLD1 to assign R-TWT membership to the SCSx traffic stream before timing out.

[0251]

[0314] In this example, MLD1 decides to assign the SCSx traffic stream a membership in R-TWT (denoted as R-TWTy) on link 1. AP1, which is associated with MLD1, then contends (860) for the channel and transmits an unsolicited TWT response frame (i.e., 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, which carries the modified TWT elements as shown in FIG. 41. The SCSID subfield in the modified broadcast TWT parameter set field for accepting the R-TWTy membership should be set to the SCS ID of SCSx to indicate that this R-TWTy membership is for SCSx.

[0252]

[0315] STA3 then becomes a member STA of the R-TWTy (864) and waits (866) for the R-TWTy SP (868) where the transmission of a frame for the SCSx traffic stream is allowed to transmit or is given higher priority for transmission. As shown in the figure, AP1 triggers (870) the transmission of a PPDU (872) for the SCSx traffic stream during the R-TWTy SP on link 1.

[0253]

[0316] 44 illustrates an example embodiment 890 in which MLD1 schedules R-TWT SPs for SCSx traffic streams on multiple links. The figure shows communication 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.

[0254]

[0317] Compared with FIG. 43, in this example, the SCSx traffic stream is a P2P traffic stream, and the SCS setup procedure for SCSx is performed on link 2, while the AP assigns membership to R-TWTy and R-TWTz on link 1 and link 2, respectively.

[0255]

[0318] MLD3 intends to set up (892) an SCS traffic stream (denoted 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 an SCSx traffic stream. The format of the SCS request frame may be as shown in FIG. 11, with its SCS Descriptor List field carrying an SCS Descriptor element as shown in FIG. 40. Within the SCS Descriptor element, there is an indication that an R-TWT is required (requested) for transmission of the SCSx traffic stream.

[0256]

[0319] After receiving the SCS request frame for SCSx, AP2 responds with an SCS response frame (896) and decides to accept the SCSx traffic stream. With the SCSx traffic stream successfully established (898), AP2 starts waiting for an R-TWT response frame from MLD1 to assign R-TWT membership to the SCSx traffic stream before a timeout occurs.

[0257]

[0320] In this example, MLD1 decides to assign the SCSx traffic stream membership in two R-TWTs (denoted R-TWTy and R-TWTz) on Link 1 and Link 2, respectively. AP1 associated with MLD1 then starts counting down its back-off timer (900) and sends an unsolicited TWT response frame (i.e., TWT setup frame) to assign / accept R-TWTy membership of STA3 over Link 1. Meanwhile, AP2 associated with MLD1 counts down its back-off timer (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.

[0258]

[0321] The frame format of the TWT Response frame may be as shown in Figure 16, which carries the modified TWT elements as shown in Figure 41. The SCSID subfield in the modified Broadcast TWT Parameter Set field for accepting membership of R-TWTy (or R-TWTz) should be set to the SCS ID of SCSx to indicate that this R-TWTy (or R-TWTz) membership is for SCSx.

[0259]

[0322] STA3 then becomes a member STA of R-TWTy on link 1 (908). During the R-TWTy SP, frames of the SCSx traffic stream are allowed to transmit or have higher priority to transmit. As shown in the figure, after an interval (912), AP1 transmits a MU-RTS TXS trigger frame (916) (as specified in IEEE 802.11be) to share a TXOP with STA3, and STA3 starts transmitting PPDUs (920) of the SCSx traffic stream after responding with a CTS (918) during the R-TWTy SP on link 1.

[0260]

[0323] STA5 becomes a member STA of R-TWTz on link 2 (910). During the R-TWTz SP, after an interval (914), frames of the SCSx traffic stream are allowed to transmit or have higher priority to transmit. As shown in the figure, AP2 transmits a MU-RTS TXS trigger frame (922) to share a TXOP with STA5, and STA5 starts transmitting PPDUs (926) of the SCSx traffic stream after responding with a CTS (922) during the R-TWTz SP on link 2.

[0261]

[0324] Note that a P2P (or DL / UL) SCS traffic stream may indicate that it can only be transmitted over certain links due to the Link ID field (or Link Bitmap field) (or TID to Link mapping) in the Control Information field of the QoS characteristic element of the SCS traffic stream. The SCS traffic stream can only be transmitted over its Tunneled Direct Link Setup (TDLS) link if it is P2P. The AP MLD can schedule R-TWT SP for the transmission of the SCS traffic stream only over those specific links.

[0262]

[0325] 45 illustrates an example embodiment 950 in which MLD3 does not receive R-TWT membership for SCSx before timing out. The figure shows communication 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.

[0263]

[0326] MLD3 intends to set up an SCS traffic stream (denoted 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 sends an SCS request frame (954) to AP2 to set up the SCSx traffic stream. The format of the SCS request frame may be as shown in FIG. 11, with its SCS Descriptor List field carrying an SCS Descriptor element as shown in FIG. 40. The SCS Descriptor element includes an indication that an R-TWT is required (requested) for transmission of the SCSx traffic stream.

[0264]

[0327] After receiving the 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 it waits for an R-TWT response frame from MLD1 (958) to assign R-TWT membership to SCSx. The R-TWT response is not received by MLD3 (960) within the configured timeout period (958).

[0265]

[0328] After the timeout (958), MLD3 starts counting down its BO timer (962) to restart the SCS setup procedure for the SCSx traffic stream. The restart can be performed on any link. In this example, the restart is on link 1 and involves another SCS setup process (964) with STA3 sending an SCS request (966) in response to which an SCS response (968) is received.

[0266] 4. General Scope of the Embodiments

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

[0267]

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

[0268]

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

[0269]

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

[0270]

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

[0271]

[0335] From the description herein, it will be understood that the present disclosure includes multiple implementations of the techniques, including but not limited to the following.

[0272]

[0336] An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit, the wireless communication circuit as a wireless station (STA) that is a separate STA or as a STA in a multi-link device (MLD), the wireless communication circuit for operating as either a normal STA or an access point (AP) STA to wirelessly communicate with other wireless stations (STAs) using a carrier sense multiple access / collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN); (b) a processor coupled to the wireless communication circuit for operating on the WLAN; and (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs, the instructions, when executed by the processor, performing steps of a wireless communication protocol for the wireless communication circuit, the steps including: (i) transmitting, by a STA operating as a non-AP STA, a stream classification service (SCS) request frame to an AP station to request a reserved restricted target wait time (R-TWT); (d)(ii) receiving the SCS request frame from the non-AP STA, where the AP, upon receiving the SCS request frame, determines whether to accept the request; (d)(iii) transmitting an SCS response frame by the AP to the non-AP STA to indicate a decision on the request; and (d)(iv) scheduling SCS traffic to be transmitted with increased priority by the AP and the non-AP STA during a R-TWT service period (SP) if the request is accepted, where the SCS traffic is selected from a group of communication traffic consisting of downlink (DL), uplink (UL) and peer-to-peer (P2P).

[0273]

[0337] 1. An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit, the wireless communication circuit as a wireless station (STA) that is a separate STA or as a STA in a multi-link device (MLD), the wireless communication circuit operating as either a normal STA or an access point (AP) STA for wirelessly communicating with other wireless stations (STAs) using a carrier sense multiple access / collision avoidance (CSMA / CA) mechanism over a wireless local area network (WLAN); (b) a processor coupled to the wireless communication circuit for operating on the WLAN; and (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs, the instructions, when executed by the processor, performing steps of a wireless communication protocol for the wireless communication circuit, the steps including: (d)(i) utilizing a target wait time (TWT) parameter set field incorporating a link identification (ID) field in a TWT element to indicate a link for which the modified TWT parameter set field is set; and (d)(ii) a non-AP STA for communicating with the non-AP STA. (d)(iii) a step of the AP sending a TWT response frame on one link using the modified TWT parameter set field in the TWT element to indicate a decision on the request; and (d)(iv) a step of the non-AP STA receiving the decision from the AP in the TWT setup frame and performing TWT scheduling for frame exchanges with the AP as instructed by the AP.

[0274]

[0338] An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit, the wireless communication circuit as a wireless station (STA) that is a separate STA or as a STA in a multi-link device (MLD), the wireless communication circuit operating as either a normal STA or an access point (AP) STA for wirelessly communicating with other wireless stations (STAs) using a carrier sense multiple access / collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN); (b) a processor coupled to the wireless communication circuit for operating on the WLAN; and (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs, the instructions, when executed by the processor, performing steps of a wireless communication protocol for the wireless communication circuit, the steps including: (d) (i) transmitting, by a non-AP STA, a stream classification service (SCS) request frame including a QoS characteristic element to an AP station to request a restricted target wait time (R-TWT) for the SCS; (d)(ii) receiving the SCS request frame from the non-AP STA, where upon receiving the SCS request frame, the AP determines whether to accept the request; (d)(iii) transmitting an SCS response frame by the AP to the non-AP STA to indicate a decision on the request; (d)(iv) if the SCS response frame accepts the SCS request, transmitting a TWT response frame by the AP to assign R-TWT membership to schedule transmission of SCS traffic during a corresponding R-TWT service period (SP); and (d)(v) if the request is accepted, scheduling SCS traffic to be transmitted with increased priority by the AP and the non-AP STA during the corresponding R-TWT SP.

[0275]

[0339] An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit, the wireless communication circuit as a wireless station (STA) that is a separate STA or as a STA in a multi-link device (MLD), the wireless communication circuit operating as either a normal STA or an access point (AP) STA for wirelessly communicating with other wireless stations (STAs) using a carrier sense multiple access / collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN); (b) a processor coupled to the wireless communication circuit for operating on the WLAN; and (c) a non-transitory memory storing instructions executable by the processor for communicating with other STAs, the instructions, when executed by the processor, performing steps of a wireless communication protocol for the wireless communication circuit, the steps including: (d)(i) transmitting, by a non-AP STA, a stream classification service (SCS) request frame including a QoS characteristic element to an AP station to request the SCS to initiate an SCS setup in addition to scheduling a transmission; and (d)(ii) transmitting, by the non-AP STA, a stream classification service (SCS) request frame including a QoS characteristic element to an AP station to request the SCS to initiate an SCS setup in addition to scheduling a transmission. an apparatus comprising: (d) receiving an SCS request frame from a STA, the AP determining, upon receiving the SCS request frame, whether to accept the request; (d)(iii) transmitting an SCS response frame by the AP to the non-AP STA to indicate a decision regarding 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.

[0276]

[0340] A wireless communication device / method for performing packet transmission, in which CSMA / CA is applied to the system / device, including: (a) a non-AP STA sends an SCS request frame to request to initiate SCS setup and R-TWT setup with the AP; (b) the AP sends an SCS response frame to indicate a decision on the request; and (c) if the request is accepted, schedule the SCS traffic to transmit during the R-TWT SP.

[0277]

[0341] An apparatus or method of any preceding implementation, wherein the R-TWT SP is triggerable.

[0278]

[0342] The apparatus or method of any of the preceding implementations, wherein the non-AP sends the SCS request frame including a TWT element to request R-TWT setup to an SCS.

[0279]

[0343] The apparatus or method of any of the preceding implementations, wherein the AP sends the SCS response frame including a TWT element to indicate the result of the R-TWT setup to the SCS.

[0280]

[0344] An apparatus or method of any of the preceding implementations, wherein the total R-TWT SP time per second scheduled by the AP is not allowed to exceed the time required by traffic to be transmitted or prioritized during the R-TWT SP.

[0281]

[0345] The apparatus or method of any of the preceding implementations, wherein the AP that schedules the R-TWT can set the interval between two consecutive R-TWT SPs for an SCS traffic stream to be between a minimum service interval and a maximum service interval for the SCS traffic stream.

[0282]

[0346] An apparatus or method of any of the preceding implementations, wherein parameters in the modified TWT parameter set field are set based on a timing synchronization function (TSF) time value on the link indicated in the link identification (ID) field.

[0283]

[0347] An apparatus or method of any of the preceding implementations, wherein the TWT setup frame carries a TWT element, whereby multiple modified TWT parameter set fields in the TWT element have the same TWT ID but different link IDs, indicating TWTs where the SP is scheduled on different links.

[0284]

[0348] An apparatus or method of any of the preceding implementations, wherein the TWT setup frame carries multiple TWT elements, whereby parameters in the modified TWT parameter set field for links within the same TWT and different TWT elements represent a range of parameters for the TWT on the link.

[0285]

[0349] The apparatus or method of any of the preceding implementations, wherein the TWT response frame may be transmitted by AP MLD on any link on which an R-TWT SP is scheduled for an SCS traffic stream.

[0286]

[0350] An apparatus or method of any of the preceding implementations, wherein the TWT response frame can be transmitted by AP MLD within a timeout.

[0287]

[0351] An apparatus or method of any of the preceding implementations, wherein a non-AP MLD should not send a TWT request frame for an SCS traffic stream that requires R-TWT scheduling within a timeout after the SCS traffic stream is successfully established.

[0288]

[0352] An apparatus or method of any of the above implementations, wherein the non-AP MLD retransmits an SCS request frame if it does not receive a TWT response frame for an SCS traffic stream requesting R-TWT scheduling within a timeout after the SCS traffic stream is successfully established.

[0289]

[0353] An apparatus or method of any of the above implementations, wherein a non-AP MLD sends a TWT request frame for an SCS traffic stream if it does not receive a TWT response frame for the SCS traffic stream within a timeout after successfully establishing the SCS traffic stream requiring R-TWT scheduling.

[0290]

[0354] An apparatus or method of any of the preceding implementations, wherein the AP MLD schedules the R-TWT SP to transmit the SCS traffic stream.

[0291]

[0355] An apparatus or method of any of the preceding implementations, wherein the AP MLD triggers transmission of an uplink (UL) or peer-to-peer (P2P) SCS traffic stream in a time interval whose length is set between the minimum and maximum service intervals of the SCS traffic stream.

[0292]

[0356] An apparatus or method of any of the preceding implementations, wherein a non-AP requesting SCS setup can set all fields of a TSPEC element in a frame to request SCS.

[0293]

[0357] An apparatus or method of any of the preceding implementations, wherein a non-AP requesting SCS setup for UL traffic may request SCS by setting an excess bandwidth allowance field in a TSPEC element in a frame.

[0294]

[0358] An apparatus or method of any of the preceding implementations, wherein a non-AP requesting SCS setup for DL ​​traffic can reserve an excess bandwidth allowance field in a TSPEC element in a frame to request SCS.

[0295]

[0359] An apparatus or method of any of the preceding implementations, wherein an AP requesting SCS setup can reserve a medium time field of a TSPEC element in a frame to request the SCS.

[0296]

[0360] An apparatus or method of any of the preceding implementations, wherein the AP is capable of accepting the SCS by setting a medium time field of a TSPEC element in the frame.

[0297]

[0361] An apparatus or method of any of the preceding implementations, wherein the non-AP can send an SCS request frame including a TWT element to request an R-TWT setup to the SCS.

[0298]

[0362] An apparatus or method of any of the preceding implementations, wherein the non-AP may transmit an SCS response frame including a TWT element to indicate the result of the R-TWT setup to the SCS.

[0299]

[0363] An apparatus or method of any of the preceding implementations, wherein the AP that schedules the R-TWT can schedule additional R-TWT SP time if a new SCS is established.

[0300]

[0364] An apparatus or method of any of the preceding implementations, wherein an AP that schedules the R-TWT can reduce the R-TWT SP time if an existing SCS is removed.

[0301]

[0365] An apparatus or method of any of the preceding implementations, wherein an AP that schedules an R-TWT can update the R-TWT SP time if an existing SCS is changed.

[0302]

[0366] An apparatus or method of any of the preceding implementations, wherein the total R-TWT SP time scheduled by the AP per second cannot exceed an upper limit.

[0303]

[0367] An apparatus or method of any of the preceding implementations, wherein an AP that schedules an R-TWT can set the interval between two consecutive R-TWT SPs to be longer than the maximum value of all minimum SI fields of the TSPEC of an SCS that has traffic scheduled to be transmitted during the R-TWT SP.

[0304]

[0368] An apparatus or method of any of the preceding implementations, wherein an AP that schedules an R-TWT can 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 SCSs that have traffic scheduled to transmit during the R-TWT SPs.

[0305]

[0369] An apparatus or method of any of the preceding implementations, wherein an AP that schedules the R-TWTs can set the interval between two consecutive R-TWT SPs as a submultiple of the beacon interval.

[0306]

[0370] An apparatus or method of any of the preceding implementations, wherein an AP that schedules an R-TWT can set the R-TWT ID to a unique value at the MLD level if the AP is affiliated with the MLD.

[0307]

[0371] The AP that schedules the R-TWT sets the R-TWT ID to a unique value at the STA level and sets the tuple<R-TWT ID、リンクID> The apparatus or method of any of the preceding implementations, wherein the R-TWT can be identified using

[0308]

[0372] An apparatus or method of any of the preceding implementations, wherein an AP that schedules an R-TWT can set the interval between two consecutive R-TWT SPs to be between the maximum SI field and the minimum SI field of the TSPEC of an SCS having traffic scheduled to be transmitted during the R-TWT SP.

[0309]

[0373] Any and all implementations of the techniques 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.

[0310]

[0374] As used herein, the term "implementation" is intended to include, but is not limited to, an embodiment, example, or other form of implementing the techniques described herein.

[0311]

[0375] As used herein, the singular terms "a," "an," and "the" may include plural references unless the context clearly dictates otherwise. Reference to an item in the singular does not mean "one and only one" unless expressly stated otherwise, but rather means "one or more."

[0312]

[0376] Phrasal constructs within this disclosure such as "A, B and / or C" describe where either A, B, or C can be present, or any combination of the items A, B, and C. Phrasal constructs such as "at least one of" followed by a group of listed elements indicate that at least one of the group elements is present, and, where applicable, includes any possible combinations of the listed elements.

[0313]

[0377] Reference herein to "an embodiment," "at least one embodiment," or similar embodiment terminology indicates that a particular feature, structure, or characteristic described in connection with the described embodiment is included in at least one embodiment of the present disclosure. Thus, these various embodiment phrases do not necessarily all refer to the same embodiment, or to a specific embodiment that differs from all other embodiments described. The embodiment phrase should be interpreted to mean that the particular features, structures, or characteristics of a given embodiment can be combined in any suitable manner into one or more embodiments of the disclosed devices, systems, or methods.

[0314]

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

[0315]

[0379] Relative terms such as first and second, top and bottom, etc. may be used only to distinguish one entity or operation from another and do not necessarily require or imply that any such actual relationship or order exists between such entities or operations.

[0316]

[0380] The terms "comprises," "comprising," "has," "having," "includes," "including," "contains," "containing," or any other variations of these terms, are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus that comprises, includes, contains, or has a list of elements may include other elements not specifically listed or inherent to such process, method, article, or apparatus, rather than including only those elements. An element introduced by "comprises...a," "has...a," "includes...a," or "contains...a" does not, in the absence of further constraints, exclude the presence of additional identical elements within the process, method, article, or apparatus that comprises, includes, contains, or has that element.

[0317]

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

[0318]

[0382] In addition, amounts, ratios, and other numerical values ​​may be expressed in range format in this specification. Such range formats are used as a shorthand for convenience, and include numerical values ​​explicitly specified as the limits of the range, but should be understood to flexibly include all individual numerical values ​​or subranges within the range as if each of these numerical values ​​and subranges were explicitly set forth. For example, a ratio within the range of about 1 to about 200 should be understood to include the explicitly recited limits of about 1 and about 200, but also include individual ratios such as about 2, about 3, about 4, and subranges such as about 10 to about 50, about 20 to about 100, etc.

[0319]

[0383] The term "coupled," as used herein, is defined as connected, although not necessarily directly, and not necessarily mechanically connected. A device or structure that is "configured" in a particular way is configured in at least that way, but may also be configured in other ways not recited.

[0320]

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

[0321]

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

[0322]

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

[0323]

[0387] It will be understood that practice in some jurisdictions may require the deletion of one or more portions of this disclosure after filing. Thus, the reader should refer to the application as originally filed for the original content of this disclosure. Any deletion of the original content of this disclosure should not be construed as an abandonment, loss, or public disclosure of the subject matter of the originally filed application.

[0324]

[0388] The following claims are hereby incorporated into this disclosure, with each claim standing on its own as separately claimed subject matter.

[0325]

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

[0326]

[0390] All structural and functional equivalents of the elements of the embodiments of the present disclosure known to those skilled in the art are expressly incorporated herein by reference and are intended to be included in the scope of the claims. Moreover, no element, component, or method step of the present disclosure is intended to be publicly disclosed, regardless of whether they are explicitly recited in the claims. No claim element herein should be construed as a "means-plus-function" element unless the element is explicitly recited using the phrase "means for". No claim element herein should be construed as a "step-plus-function" element unless the element is explicitly recited using the phrase "step for".

[0327] Example of SCS in R-TWT Scheduling AP [Table 1]

[0328] Other TWT Examples [Table 2] [Explanation of symbols]

[0329] 10 Example of embodiment 12 Circuits 14 External I / O connections / buses 16 Internal Bus 18 CPUs / Processors 20 Memory 22 Modem 24,28 RF Module 26a, 26b, 26c, ... 26n, 29 Antenna 40 Example of embodiment 50 CPU 52 Memory (RAM) 54 Modem 56 RF circuit 58 Bus 60a, 60b, 60c, ..., 60n antennas 62 CPU 64 Memory (RAM) 72,74,76 MLD 72 MLD #1 74 MLD #2 76 MLD #3 78 AP1 80 AP2 82STA1 84STA2 86STA3 88STA4 90STA5 92,94,98 Link 1 96,100 Link 2 110 Example of embodiment 112 A non-AP STA sends a request to the AP to set up an SCS, including an R-TWT setup request for the SCS. 114 Was the SCS setup request accepted by the AP? 116 SCS has been successfully established and SCS traffic can be distinguished from other traffic. 118 Was the R-TWT setup request to the SCS accepted by the AP? 120 SCS traffic is not scheduled to transmit during the R-TWT SP. 122 A non-AP STA becomes a member of the R-TWT and its SCS traffic is scheduled to transmit during the R-TWT SP. 124 SCS setup failed 126 If a non-AP STA receives the recommended SCS parameter settings from the AP, it can resend another SCS setup request. 130 Example of embodiment 132 The AP receives an SCS request frame containing an R-TWT setup request from a non-AP. 134 The AP sends an SCS response frame containing an R-TWT setup response to the non-AP. 136 Did the AP accept the SCS request and the R-TWT setup request? 138 Non-AP STAs become members of the R-TWT and traffic belonging to the SCS is scheduled to transmit during the R-TWT SP. Traffic belonging to the 140 SCS is not allowed to be transmitted during the R-TWT SP or has low priority. 150 Example of embodiment 170 Example of embodiment 190 Example of embodiment 230 Example of embodiment 250 Example of embodiment 270 Example of embodiment 272 AP1 274STA1 SCS setup including 276 R-TWT 278 SCS request 280 SCS Response 282 First R-TWT1 SP for SCS2 284 R-TWT1 SP 286 R-TWT1 SP spacing 288 DL PPDU 290 BA 292 DL PPDU 294 BA 296 R-TWT1 SP 310 Example of embodiment 312 Separate SCS setup and R-TWT setup 314 SCS request 316 SCS Response 318 R-TWT request 320 R-TWT Response 350 Example of embodiment 352 AP1 354 STA2 356 STA1 SCS setup including 358 R-TWT 360 SCS requests 362 SCS Response 1st R-TWT1 SP against 364 SCS1 1st R-TWT3 SP for 365 SCS1 368 BSRP 370 BSR 372 DL PPDU 374 BA 376 Basic Triggers 378 UL PPDU 380 BA 382 R-TWT3 SP 384 BSRP 386 BSR 388 Basic Triggers 390 UL PPDU 392 R-TWT SP spacing 410 Example of embodiment 412,413 Both sides of the communication SCS setup including 414 R-TWT 416 SCS request 418 SCS Response 1st R-TWT2 SP for 420 SCS3 424 R-TWT2 SP spacing 426 R-TWT2 SP 428,432 DL PPDU 430,434 BA 436 R-TWT2 SP 440 MLD3 442 STA3 444 STA5 446 MLD1 448 AP1 450 AP2 470 Example of embodiment 472 MLD3 474 MLD1 476 STA3 478 STA5 480AP1 482 AP2 484 R-TWT setup 486 R-TWT request 488 R-TWT Response 490 First R-TWT4 SP 492 1st R-TWT4 SP 494 R-TWT4 SP spacing 496 R-TWT4 SP 498,500,506,508 DL PPDU 502, 504, 510, 512 BA 514 R-TWT4 SP 530 Example of embodiment 532 B-TWT setup 534 B-TWT request 536 B-TWT Response 538 1st B-TWT5 SP 540 1st B-TWT5 SP 542 B-TWT5 SP Spacing 544B-TWT5SP 546,548,554,556 DL PPDU 590 Example of embodiment 592 TBTT Negotiation 594 TWT request 596 TWT Response 598 Link 1 1st TBTT 600 1st TBTT of Link 2 602 Listen Interval 604 Beacon 606 Listen Interval 608 Beacon 610B-TWT4SP 612,614 Trigger Frame 616,618 PS-Poll 620,622 BA 624,626 DL MU PPDU 628,630 BA 632,634,636,638 Beacons 650 Example of embodiment 652 I-TWT setup 654 TWT request 656 TWT Response 658 1st I-TWT6 SP on Link 1 660 1st I-TWT6 SP on Link 2 661 I-TWT6 SP 662,664 Trigger Frame 666,668 PS-Poll 670,672 BA 674,676 DL PPDU 678,680 BA 710 Example of embodiment 712 A non-AP MLD sends a frame to an AP MLD to set up an SCS and indicates in the frame that R-TWT is required for the SCS. 714 Has the non-AP MLD received a frame indicating that its SCS request was accepted by the AP MLD? 716 Once the SCS is successfully established, the non-AP MLD waits for a response from the AP MLD to allocate membership for the R-TWT on any available link. 718 SCS setup failed 720 Did a non-AP MLD receive an R-TWT membership for SCS from an AP MLD on the link within the timeout? 722 A non-AP MLD can send an R-TWT membership request or an SCS request frame for an SCS traffic stream. 724 Non-AP MLD (or associated STAs on that link) become members of the R-TWT and traffic belonging to the SCS is allowed / prioritized to transmit during the R-TWT SP on that link. 750 Example of embodiment 752 AP MLD receives a request frame to set up an SCS from a non-AP MLD, and in the frame, the SCS requires R-TWT scheduling. 754 AP MLD accepted SCS request? 756 AP MLD sends SCS response frame to reject SCS request 758 The AP MLD responds to the non-AP MLD with an SCS response frame to accept the SCS request. 760 AP MLD sends frames to assign R-TWT membership on at least one link to SCS within the timeout. 770 Example of embodiment 790 Example of embodiment 810 Example of embodiment 812 MLD3 813a STA3 813b STA5 814 SCS Setup 816 SCS request 818 SCS Response 820 SCSx traffic stream establishment successful 822 BO 824 TWT Response 826 STA3 is a member STA of R-TWTy, and frames from SCSx are prioritized for transmission during R-TWTy. 828 First R-TWTy SP 830,836 PPDU 832 1st R-TWTy SP 834,838 BA 840 MLD1 841a AP1 841b AP2 850 Example of embodiment 852 SCS Setup 854 SCS request 856 SCS Response 858 SCSx traffic stream establishment successful 860 BO 862 R-TWT Response 864 STA3 is a member STA of R-TWTy, and frames from SCSx are prioritized for transmission during R-TWTy 866 R-TW Ty SP 868 R-TW Ty SP 870 Trigger 872 PPDU 890 Example of embodiment 892 SCS Setup 894 SCS request 896 SCS Response 898 SCSx traffic stream established successfully 900 BO 902 BO 906 TWT Response 908 STA3 is a member STA of R-TWTy, and frames from SCSx are prioritized for transmission during R-TWTy. 910 STA5 is a member STA of R-TWTz, and frames from SCSx are prioritized for transmission during R-TWTz. 912 First R-TWTy SP 914 First R-TWTz SP 916 MU-RTS TXS 918 CTS 920 P2P PPDU 922 MU-RTS TXS 926 P2P PPDU 950 Example of embodiment 952 SCS Setup 954 SCS request 955 SCS Response 956 SCSx traffic stream establishment successful 958 Timeout 960 R-TWT response was not received by the MLD3 within the configured timeout period 962 BO 964 Alternative SCS setup process 966 SCS request 968 SCS Response

Claims

1. 1. An apparatus for wireless communication in a network, the apparatus comprising: (a) a wireless communication circuit, the wireless communication circuit being as a wireless station (STA) that is a separate STA or as a STA in a multi-link device (MLD), the wireless communication circuit operating as either a normal STA or an access point (AP) STA for wirelessly communicating with other wireless stations (STAs) using a carrier sense multiple access / collision avoidance (CSMA / CA) mechanism on a wireless local area network (WLAN); (b) a processor coupled to the wireless communication circuitry for operating on the WLAN; (c) a non-transitory memory storing instructions executable by said processor for communicating with other STAs; Equipped with (d) the instructions, when executed by the processor, perform steps of a wireless communication protocol for the wireless communication circuit, the steps comprising: (i) sending a stream classification service (SCS) request frame including a QoS characteristic element by a non-AP STA to an AP station to request the SCS to initiate SCS setup in addition to scheduling a restricted target wait time (R-TWT); (ii) receiving the SCS request frame from the non-AP STA, where upon receiving the SCS request frame, the AP determines whether to accept the request; (iii) transmitting, by the AP, an SCS Response frame to the non-AP STA indicating a decision on the request; (iv) if the SCS response frame accepts the SCS request, transmitting a TWT response frame by the AP to assign R-TWT membership to schedule transmission of SCS traffic during a corresponding R-TWT Service Period (SP); (v) if the request is accepted, scheduling SCS traffic to be transmitted with increased priority by the AP and the non-AP STAs during the corresponding R-TWT SP; Including, An apparatus comprising:

2. 2. The apparatus of claim 1, wherein the TWT response frame can be transmitted by AP MLD on any link on which an R-TWT SP is scheduled for an SCS traffic stream.

3. The device of claim 1 , wherein the TWT response frame can be transmitted by an AP MLD within a timeout.

4. The apparatus of claim 1, characterized in that a non-AP MLD should not transmit a TWT request frame for an SCS traffic stream that requires R-TWT scheduling within a timeout after successful establishment of the SCS traffic stream.

5. The apparatus of claim 1, characterized in that the non-AP MLD retransmits an SCS request frame if it does not receive a TWT response frame for an SCS traffic stream within a timeout after successful establishment of the SCS traffic stream requesting R-TWT scheduling.

6. The apparatus of claim 1, characterized in that the non-AP MLD transmits a TWT request frame for an SCS traffic stream if it does not receive a TWT response frame for the SCS traffic stream within a timeout after successful establishment of the SCS traffic stream requiring R-TWT scheduling.

Images