Communication apparatus and communication method supporting priority traffic

Abstract

The present disclosure provides a communication device and a communication method for supporting priority traffic.SOLUTION: A communication device of the present disclosure comprises a receiver configured to receive, from another communication device, a network allocation vector (NAV) setting legacy frame for setting a quiet period during one of one or more prioritized service periods (SPs) in which transmission of a frame of a traffic type different from a traffic type specified by the another communication device is restricted, and a circuit configured to, when receiving the NAV setting legacy frame, not set the NAV of the communication device regardless of whether the NAV setting legacy frame is addressed to the communication device.SELECTED DRAWING: Figure 19

Description

[Technical Field]

[0001] The present disclosure relates to a communication apparatus and method for accommodating prioritized traffic, more specifically low latency traffic, in an extremely high throughput wireless local area network (EHT WLAN). [Background technology]

[0002] In the standardization of next-generation wireless local area networks (WLANs), a new radio access technology that requires backward compatibility with IEEE 802.11a / b / g / n / ac / ax technologies is being considered by the IEEE 802.11 Working Group and named IEEE 802.11be Very High Throughput (EHT) WLAN.

[0003] 802.11be EHT WLANs are proposed to enable better integration of low-latency traffic, with the aim of providing significant peak throughput and capacity increases over 802.11ax high-efficiency (HE) WLANs, particularly for cell-edge STAs. Summary of the Invention [Problem to be solved by the invention]

[0004] However, efficient procedures for priority and low latency traffic have not been discussed much so far.

[0005] Therefore, what is needed is a communication apparatus and method that provides a viable technical solution for prioritized traffic in the context of EHT WLANs. Furthermore, other desirable features and characteristics will become apparent from the following detailed description and appended claims, considered in conjunction with the accompanying drawings and the Background section of this disclosure. [Means for solving the problem]

[0006] Non-limiting exemplary embodiments facilitate providing a communications apparatus and method for accommodating prioritized traffic, and more particularly, low latency traffic, in the context of an EHT WLAN.

[0007] In a first embodiment, the present disclosure provides a communications device comprising: a receiver that, in operation, receives notification of one or more priority service periods (SPs) from another communications device, each SP being a period during which only frames belonging to a traffic type specified by the other communications device are permitted to be transmitted; and circuitry that, in operation, determines whether to transmit at least one frame of the specified traffic type in one of the one or more SPs, and, in response to determining that there are no frames of the specified traffic type to transmit, refrains from transmitting during one of the one or more SPs.

[0008] In a second embodiment, the present disclosure provides a communication method performed by a communication device, the communication method including the steps of receiving notification of one or more priority service periods (SPs) from another communication device, each SP being a period during which only frames belonging to a traffic type specified by the other communication device are allowed to be transmitted; determining whether to transmit at least one frame of the specified traffic type in one of the one or more SPs; and refraining from transmitting during one of the one or more SPs in response to determining that there are no frames of the specified traffic type to transmit.

[0009] It should be noted that the general or specific embodiments may be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any combination thereof.

[0010] Further benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings. These benefits and / or advantages may be obtained individually by the various embodiments and features of the specification and drawings, and it is not necessary for all of these features to be present in order to obtain one or more of such benefits and / or advantages. [Brief explanation of the drawings]

[0011] Embodiments of the present disclosure will be better understood and readily apparent to those of ordinary skill in the art upon reading the following description, given by way of example only, and upon reference to the drawings in which: [Figure 1A] 1 shows a schematic diagram of uplink and downlink single-user (SU) multiple input multiple output (MIMO) communication between an access point (AP) and a station (STA) in a MIMO wireless network. [Figure 1B] 1 shows a schematic diagram of downlink multi-user (MU) communication between an AP and multiple STAs in a MIMO wireless network. [Figure 1C] 1 shows a schematic diagram of trigger-based uplink MU communication between an AP and multiple STAs in a MIMO wireless network. [Figure 2A] 2 shows a flow diagram illustrating individual TWT-based communication between an AP 202 and two STAs. [Figure 2B] 2 shows a flow diagram illustrating broadcast TWT-based communication between an AP 202 and two STAs. [Figure 3] 1 shows a flowchart illustrating a communication method for supporting prioritized traffic, according to various embodiments of the present disclosure. [Figure 4A] 1 shows a flow diagram illustrating communications corresponding to priority traffic according to an example of a first embodiment of the present disclosure. [Figure 4B]1 shows a flow diagram illustrating communications corresponding to priority traffic according to another example of the first embodiment of the present disclosure; [Figure 5] 10 illustrates an exemplary format of a Broadcast TWT element indicating an Extended TWT SP. [Figure 6] 10 shows a flow diagram illustrating communications corresponding to priority traffic according to yet another example of the first embodiment of the present disclosure; [Figure 7A] 1 shows an exemplary format of a Request To Send (RTS) frame. [Figure 7B] 1 shows an exemplary format of a CTS (Clear To Send) frame. [Figure 8] 7A and 7B show exemplary Frame Control fields for the RTS and CTS frames. [Figure 9] 1 illustrates an exemplary format of a TWT Information frame. [Figure 10] 10 shows a flow diagram illustrating communications corresponding to priority traffic according to a second embodiment of the present disclosure. [Figure 11] 1 shows an exemplary Basic Trigger frame. [Figure 12] 10 shows a flow diagram illustrating communications accommodating prioritized traffic according to a third embodiment of the present disclosure. [Figure 13] 1 illustrates an exemplary TWT Setup frame. [Figure 14] 10 illustrates a prioritized Uplink OFDMA-based Random Access (UORA) procedure according to a fourth embodiment of the present disclosure. [Figure 15] 1 shows an exemplary UORA Parameter element. [Figure 16]1 shows a flowchart illustrating a priority UORA procedure according to one embodiment of the present disclosure. [Figure 17] 10 shows an illustrated flow diagram for priority traffic according to a fourth embodiment of the present disclosure; [Figure 18] 1 illustrates a configuration of a communication device (eg, an AP) according to various embodiments of the present disclosure. [Figure 19] 1 illustrates a configuration of a communication device (eg, a non-AP or a STA) according to various embodiments of the present disclosure.

[0012] Those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some elements in the illustrations, block diagrams, or flow charts may be exaggerated relative to other elements to facilitate an accurate understanding of embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0013] Some embodiments of the present disclosure will now be described, by way of example only, with reference to the following figures in which like reference numbers and characters indicate similar or equivalent elements:

[0014] In the following paragraphs, a particular exemplary embodiment is described with reference to prioritized traffic, more specifically low latency traffic, of one or more access points (APs) and one or more stations (STAs) in an EHT WLAN.

[0015] In the context of IEEE 802.11 (Wi-Fi) technology, a station (also synonymously referred to as a STA) is a communication device capable of using the 802.11 protocol. Based on the definition in IEEE 802.11-2016, a STA can be any device that includes an IEEE 802.11-compliant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM).

[0016] An STA may be, for example, a laptop, desktop personal computer (PC), personal digital assistant (PDA), access point, or Wi-Fi phone in a wireless local area network (WLAN) environment. An STA may be stationary or mobile. In a WLAN environment, the terms "STA," "wireless client," "user," "user device," and "node" are often used synonymously.

[0017] Similarly, an AP (also known synonymously as a Wireless Access Point (WAP) in the context of IEEE 802.11 (Wi-Fi) technology) is a communications device that allows STAs in a WLAN to connect to a wired network. APs are typically connected to a router (through the wired network) as standalone devices, but APs can also be integrated with or used within a router.

[0018] As mentioned above, a STA in a WLAN may otherwise function as an AP, and vice versa. This is because a communication device in the context of IEEE 802.11 (Wi-Fi) technology may include both STA and AP hardware elements. In this manner, the communication device can switch between STA mode and AP mode based on the conditions and / or requirements of the actual WLAN. In various embodiments below, a non-AP STA may refer to a STA in a WLAN that is not implemented as an AP.

[0019] In a MIMO wireless network, "multiple" refers to multiple antennas used simultaneously for transmission over a wireless channel and multiple antennas used simultaneously for reception. In this regard, "multiple-input" refers to multiple transmitter antennas that input wireless signals into a channel, and "multiple-output" refers to multiple receiver antennas that receive wireless signals from the channel into a receiver. For example, in an N×M MIMO network system, N is the number of transmitter antennas and M is the number of receiver antennas, and N may or may not be equal to M. For purposes of brevity, this disclosure will not further discuss the number of transmitter antennas and the number of receiver antennas.

[0020] In a MIMO wireless network, single-user (SU) and multi-user (MU) communications can be deployed between communication devices such as APs and STAs. MIMO wireless networks offer advantages such as spatial multiplexing and spatial diversity, which achieve higher data rates and robustness by using multiple spatial streams. According to various embodiments, the term "spatial stream" may be used interchangeably with the term "space-time stream" (or STS).

[0021] FIG. 1A shows a schematic diagram of SU communication 100 between an AP 102 and a STA 104 in a MIMO wireless network. As shown, the MIMO wireless network can include one or more STAs (e.g., STA 104, STA 106, etc.). If the SU communication 100 in a channel occurs over the entire channel bandwidth, it is referred to as full-bandwidth SU communication. If the SU communication 100 in a channel occurs over a portion of the channel bandwidth (e.g., one or more 20 MHz subchannels in the channel are punctured), it is referred to as punctured SU communication. In the SU communication 100, the AP 102 transmits multiple space-time streams using multiple antennas (e.g., four antennas as shown in FIG. 1A), with all space-time streams directed to a single communication device (i.e., STA 104). For simplicity, the multiple space-time streams directed to STA 104 are depicted as a combined data transmission arrow 108 directed to STA 104.

[0022] SU communication 100 can be configured for bidirectional transmission. As shown in FIG. 1A, in SU communication 100, STA 104 can transmit multiple space-time streams using multiple antennas (e.g., two antennas as shown in FIG. 1A), with all space-time streams directed to AP 102. For simplicity, the multiple space-time streams directed to AP 102 are shown as a combined data transmission arrow 110 directed to AP 102.

[0023] Thus, the SU communication 100 shown in FIG. 1A allows for both uplink and downlink SU transmissions in a MIMO wireless network.

[0024] 1B shows a schematic diagram of downlink MU communication 112 between an AP 114 and multiple STAs 116, 118, and 120 in a MIMO wireless network. The MIMO wireless network may include one or more STAs (e.g., STA 116, STA 118, STA 120, etc.). The MU communication 112 may be orthogonal frequency division multiple access (OFDMA) communication or MU-MIMO communication. In the case of OFDMA communication in a channel, the AP 114 simultaneously transmits multiple streams to the STAs 116, 118, and 120 in the network in different resource units (RUs) within the channel bandwidth. In the case of MU-MIMO communication in a channel, the AP 114 simultaneously transmits multiple streams to the STAs 116, 118, and 120 in the same(s) RU(s) within the channel bandwidth using multiple antennas through spatial mapping or precoding techniques. When RUs performing OFDMA or MU-MIMO communication occupy the entire channel bandwidth, the OFDMA or MU-MIMO communication is referred to as full-band OFDMA or full-band MU-MIMO communication. When RUs performing OFDMA or MU-MIMO communication occupy a portion of the channel bandwidth (e.g., one or more 20 MHz subchannels within the channel are punctured), the OFDMA or MU-MIMO communication is referred to as punctured OFDMA or MU-MIMO communication. For example, two space-time streams may be directed to STA 118, another space-time stream may be directed to STA 116, and yet another space-time stream may be directed to STA 120. For simplicity, the two space-time streams directed to STA 118 are shown as bundled data transmission arrow 124, the space-time stream directed to STA 116 is shown as data transmission arrow 122, and the space-time stream directed to STA 120 is shown as data transmission arrow 126.

[0025] To enable uplink MU transmissions, trigger-based communication is provided in a MIMO wireless network. In this regard, FIG. 1C illustrates a schematic diagram of trigger-based uplink MU communication 128 between an AP 130 and multiple STAs 132, 134, and 136 in a MIMO wireless network.

[0026] Because multiple STAs 132, 134, 136 participate in this trigger-based uplink MU communication, the AP 130 must coordinate the simultaneous transmissions of the multiple STAs 132, 134, 136.

[0027] 1C , the AP 130 simultaneously transmits trigger frames 139, 141, and 143 to the STAs 132, 134, and 136 to indicate user-specific resource allocation information (e.g., the number of space-time streams, the starting STS number, and the assigned RUs) that each STA can use. In response to the trigger frames, the STAs 132, 134, and 136 can simultaneously transmit their respective space-time streams to the AP 130 according to the user-specific resource allocation information indicated in the trigger frames 139, 141, and 143. For example, two space-time streams are directed from the STA 134 to the AP 130, another space-time stream is directed from the STA 132 to the AP 130, and yet another space-time stream is directed from the STA 136 to the AP 130. For simplicity, the two space-time streams directed from STA 134 to AP 130 are shown as a combined data transmission arrow 140, the space-time stream directed from STA 132 to AP 130 is shown as data transmission arrow 138, and the space-time stream directed from STA 136 to AP 130 is shown as data transmission arrow 142.

[0028] In 802.11 WLAN, due to the packet / PPDU (physical layer protocol data unit) based transmission and distributed MAC (medium access control) scheme, there is no time scheduling (e.g., periodic time slot allocation for data transmission similar to TDMA (time division multiple access)). Scheduling of frequency and spatial resources is performed on a packet basis. In other words, resource allocation information is PPDU-based.

[0029] According to various embodiments, an EHT WLAN supports non-triggered communication, as shown in Figures 1A and 1B, and triggered communication, as shown in Figure 1C. In non-triggered communication, a communication device transmits a PPDU to one other communication device or two or more other communication devices without an explicit request. In triggered communication, a communication device transmits a PPDU to one other communication device or two or more other communication devices only after receiving a requesting trigger frame.

[0030] Three main latency ranges (categories) have been identified for low-latency applications: (a) 10-50 milliseconds (ms) for applications such as interactive video and autonomous vehicles; (b) 1-10 ms for applications such as augmented reality / virtual reality (AR / VR) and gaming; and (c) <1 ms for TSN-like (time-sensitive network-like) applications. Another approach has been proposed: enhancing the TWT mechanism for latency-sensitive traffic. This could be particularly advantageous in environments with few or no legacy 802.11 devices, for example in the 6 GHz band.

[0031] In the United States, the Department of Homeland Security / Emergency Communications Division (DHS / ECD) Priority Communications Program allows national security and emergency preparedness (NSEP) and public safety users to communicate over public communications networks during times of congestion, such as during disasters and emergencies, such as floods, earthquakes, hurricanes, terrorist attacks, etc. NSEP traffic is another target that may benefit from this disclosure.

[0032] In particular, NSEP priority access provides authorized users with priority access to system resources during periods of network congestion to increase the probability of successful communication. Priority access includes preferential treatment in obtaining channel access and allocating network resources. This service is available only to designated authorized devices, which are typically a small fraction of the total number of devices operating in the area.

[0033] A non-AP STA requests NSEP priority access by sending a request to the AP, which verifies the non-AP STA's authorization to use NSEP priority access, e.g., using locally stored validation information or by contacting the NSEP service provider via the SSPN interface, and sends a response to the requesting non-AP STA.

[0034] Target wake time (TWT) was first introduced in 802.11ah and enhanced by 802.11ax. The TWT mechanism allows STAs to agree on a common wake scheduling with the AP and wake up only when necessary. The primary purpose of the TWT mechanism is to minimize contention among STAs within a basic service set (BSS) and to shorten the awake period for power-saving STAs. The TWT Session Period (SP) is the period during which a STA is awake to receive or transmit data.

[0035] A TWT agreement is a final agreement between the AP and the STA reached after negotiation to define the details of the TWT SP(s) to which the STA belongs (e.g., the time(s) the station must wake up). A TWT agreement allows a STA to participate in multiple TWT SPs and wake up periodically. A TWT agreement may allow DL, UP, or both types of transmission, subject to negotiation and further instructions that the AP may provide, for example, through a Trigger frame, at the start of each TWT SP.

[0036] The TWT mechanism includes individual TWT and broadcast TWT, which can be implemented by individual TWT agreement and broadcast TWT agreement between the AP and STA(s), respectively.

[0037] 2A shows a flow diagram 200 illustrating individual TWT-based communication between an AP 202 and two STAs (STA1 204, STA2 206). To initiate a TWT session, there is first a negotiation phase in which the AP and the STA (e.g., STA1 204) agree on a common set of parameters, such as: · Target Wake Time (TWT): The next time (e.g., next TWT 213) (unit: microseconds) that a station participating in TWT-based communication should wake up for a TWT SP. TWT Wake Interval: The time interval between subsequent TWT sessions of the station. When TWT is periodic, the value is greater than 0. · Minimum TWT Wake Duration: The minimum duration to stay awake from the start time of the TWT SP so that it can receive frames from other station(s). · TWT Channel: A channel that a station can temporarily use as its primary channel. TWT Protection: A mechanism employed to protect the TWT SP from external station transmissions such as RTS (Request To Send) / CTS (Clear to Send).

[0038] During the negotiation phase, the following aspects are also defined: Initially, the TWT agreement can be: Explicit: TWT parameters are required to be advertised before each new session or SP. Implicit: The parameters of periodic sessions or subsequent TWT SPs are allowed to be calculated implicitly, depending on the initial TWT SP or the initial parameter set, until a new set is received.

[0039] Furthermore, there may be different TWT behaviors inside the TWT SP. Trigger-enabled: The AP transmits a Trigger frame (eg, Trigger frame 217) during a TWT SP (eg, Trigger-enabled TWT SP 232) to schedule a station's transmission. Non-Trigger-enabled: When the use of Trigger frames is not required, each station can autonomously decide when to transmit within a TWT session. Protected: TWT SP starts with an RTS (Request To Send) / CTS (Clear To Send) exchange. Announced: A STA is required to send a message announcing its presence in order to obtain downlink (DL) data buffered at the AP. Unannounced: The AP can send DL traffic to active STAs within the target wake time without waiting for a previous frame from the STA, assuming that the STAs in the TWT SP must be awake at the start of the TWT SP.

[0040] Returning to Figure 2A, to create a new TWT TP, STA1 204 can generate and send a TWT request frame 208 to AP 202. The TWT request frame contains a request for a TWT SP and specifies a parameter set for the TWT SP. The request frame can be one of the following types: Suggest: The set of parameter values ​​included in the request is what STA1 204 would like to use, but STA1 204 would also consider accepting a different set. Request: STA1 204 is willing to establish a TWT agreement and invites responding stations to specify a set of TWT parameters. Demand: STA1 204 wants to establish a TWT agreement, but will not accept a different parameter set than that specified in the TWT request frame 208.

[0041] The AP can respond to the TWT request frame 208 by sending a TWT response frame 210 to STA1 204. The TWT response frame 210 can also specify a parameter set for the TWT SP. The response frame type can be one of the following: Accept: The AP 202 accepts the request and a TWT agreement is set up with the parameter values ​​specified in the TWT Response frame 210. Alternate: The AP 202 proposes an alternative set of parameter values. Another set of request and response frames may be required to complete the agreement negotiation phase. Dictate: The AP 202 requests another set of parameters without the possibility of further negotiation. Another set of request and response frames may be required to complete the agreement negotiation phase. · Reject: TWT SP is not accepted.

[0042] Returning to Figure 2A, the response frame type of the TWT response frame 210 is Accept, a TWT agreement is set up between the AP 202 and STA1 204, and STA1 204 can go to sleep until the next TWT TP is initiated at 230.

[0043] An AP can have multiple TWT agreements, each with a different station, and some of the agreements may overlap in time. Different STAs can be scheduled by the AP for simultaneous transmission or must contend for the medium via random access. Furthermore, in the TWT grouping mechanism, the AP can specify time-division multiple access-like (TDMA-like) scheduling from the start of a common TWT SP by providing a transmission time for each group and each station within the group. In this case, the AP 202 sends another TWT response frame 212 to STA2 206 in the BSS to provide the transmission time and parameter set for the TWT SP 232 and schedule STA2 206 for simultaneous transmission in the TWT SP 232. A TWT agreement is then similarly set up between the AP 202 and STA2 206, and STA2 206 can transition to a sleep (doze) state until the next TWT TP is initiated at 230.

[0044] A contention-based channel access procedure, e.g., an enhanced distributed channel access (EDCA) procedure, is illustrated by blocks 216 and 224. At the start of the TWT SP 232 at 230 after both STA1 204 and STA2 206 wake up, the AP 202 can transmit a Trigger frame 217 to enable the STAs to transmit during the trigger-based TWT SP 232. Upon receiving the Trigger frame 217, STA1 204 generates and transmits a power saving (PS)-Poll frame 218 to request any pending frames buffered from the AP 202. Meanwhile, STA2 206 simultaneously generates and transmits a quality of service (QoS) Null frame 220 carrying an empty data frame, requesting no data from the AP 202. After receiving the PS-Poll frame 218 and the QoS Null frame 220 , the AP 202 can send a Multi-STA BlockAck frame 222 to STA1 204 and STA2 206 .

[0045] The AP 202 may then transmit a DL MU PPDU 225 to STA1 204 and STA2 206. The DL MU PPDU 225 may include any pending frames and buffered data requested by STA1 204. Upon receiving the DL MU PPDU 225, STA1 204 and STA2 206 may generate and transmit respective BlockAck frames 226, 228 to the AP 202. Next, upon completion of the triggered TWT SP 232 at 231, STA1 204 and STA2 206 may transition to a sleep (doze) state.

[0046] FIG. 2B shows a flow diagram 240 illustrating broadcast TWT-based communication between an AP 242 and two STAs (STA1 244, STA2 246). In broadcast TWT operation, the AP 242 can set up a shared TWT session for a group of STAs (e.g., STA1 244, STA2 246) and periodically specify a TWT parameter set in a Beacon frame (e.g., Beacon frame 255). STAs (e.g., STA1 244, STA2 246) in the TWT broadcast agreement are required to wake up only to receive Beacon frames containing an indication of the TWT broadcast session to which they belong (e.g., triggered TWT SP 261). Note that the AP 242 can advertise an existing TWT broadcast agreement so that stations can request membership in an existing TWT session or send a request to create a new session.

[0047] STA1 244 can generate and transmit a TWT request frame 248 to the AP 242 to request participation in a broadcast TWT agreement. Such a request can be transmitted in response to a join request solicited by the AP 242 from all relevant stations in the BSS that support TWT. As with an individual TWT agreement, during the negotiation phase, STA1 244 can request, propose, or solicit a parameter set for a broadcast TWT SP (e.g., a triggered TWT SP 261), and the AP can then respond by transmitting a TWT response frame 250 to accept or reject the request or propose an alternative parameter set. In most cases, the TWT parameters are determined by the AP 242.

[0048] During the agreement setup phase, STA1 244 can optimally negotiate the other two basic parameters. Next target beacon transmission time: the next transmission time of a Beacon frame containing TWT information related to STA1 244, i.e. related to the broadcast TWT SP (e.g., triggered TWT SP 261) to which STA1 belongs. In this case, the first target beacon transmission time (first TBTT 251) of the Beacon frame 255 is negotiated during the setup phase. Listen Interval: The interval (e.g., listen interval 257) between subsequent beacons (e.g., Beacon frames 280) that convey TWT information relevant to STA1 244.

[0049] The STAs then transition to a doze state and wake up when the next associated beacon is scheduled. In this case, STA1 244 wakes up after the first TBTT 251, when the first Beacon frame 255 is scheduled. STA2 246 may also belong to the TWT SP 261 and therefore may wake up to receive the Beacon frame 255. The Beacon frame 255 may carry information about the broadcast TWT session that allows participating STAs, such as STA1 244 and STA2 246, to follow the session schedule. This information may include the Broadcast TWT 256 (i.e., the time when participating STAs, such as STA1 244 and STA2 246, should wake up for the Broadcast TWT SP), the TWT wake interval, and the minimum TWT wake duration (e.g., the triggered TWT SP 261). Upon receiving Beacon frame 255, STA1 204 and STA1 246 may go to sleep until the broadcast TWT TP begins.

[0050] A contention-based channel access procedure, such as an enhanced distributed channel access (EDCA) procedure, is illustrated by blocks 266 and 270. After both STA1 244 and STA2 246 wake up, at the beginning of the TWT SP 261, the AP 242 can transmit a Trigger frame 262 to enable the STAs to transmit during the trigger-based TWT SP 261. Upon receiving the Trigger frame 262, STA1 244 can generate and transmit a PS-Poll frame 264 to request pending frames buffered in the AP 242. Meanwhile, STA2 246 can simultaneously generate and transmit a QoS Null frame 266 carrying an empty data frame, requesting no data from the AP 242. After receiving the PS-Poll frame 264 and the QoS Null frame 266, the AP 242 can transmit a Multi-STA BlockAck frame 268 to STA1 244 and STA2 246.

[0051] The AP 242 can then transmit a DL MU PPDU 271 to STA1 244 and STA2 246. The DL MU PPDU 271 may include any pending frames and buffered data requested by STA1 244. Upon receiving the DL MU PPDU 271, STA1 244 and STA2 246 can generate and transmit respective BlockAck frames 272, 274 to the AP 242. Then, when the triggered TWT SP 232 ends, STA1 244 and STA2 246 can transition to a sleep (doze) state until the next TWT SP begins.

[0052] Additionally, AP 242 may also use another Beacon frame 278 to broadcast updates regarding the TWT parameter sets for the TWT SP so that STA1 244 and STA2 246 can update appropriately.

[0053] Details of the TWT agreement regarding the TWT mode and TWT parameters can be conveyed in a TWT element that can be included in a TWT request / response frame exchanged between the AP and the STA during the negotiation and TWT setup process. The TWT request / response frames (e.g., TWT request frames 208, 248 and TWT response frames 210, 212, 250) can include a set of parameters for setting up the TWT agreement, such as the TWT and TWT wake interval for individual TWTs, the next target beacon (e.g., the first TBTT) and listen interval for broadcast TWTs, and a signal field that specifies the operation mode of the TWT SP, such as whether the TWT parameters are explicitly advertised or implicitly calculated based on the first SP, whether the TWT SP is enabled in a triggered manner using a Trigger frame, and whether the STA needs to announce its presence to retrieve buffered data from the AP.

[0054] The TWT element included in the TWT request / response frame may further include a Broadcast TWT ID used to identify a broadcast TWT agreement: A value of 0 in the Broadcast TWT ID subfield of the TWT element indicates a broadcast TWT whose membership corresponds to all STAs that are members of the BSS corresponding to the BSSID of the management frame carrying the TWT element and are allowed to include Trigger frames with RA-RUs (Random Access Resource Units) for unassociated STAs, while a value of 1 indicates that negotiation with the STA is required.

[0055] Additionally, the Broadcast TWT Recommendation field of the TWT element can indicate restrictions on frames transmitted during a Broadcast TWT SP. Table 1 summarizes the restrictions on frames transmitted during a Broadcast TWT SP. [Table 1]

[0056] Note that in the 802.11ax specification, the recommendation provided in the Broadcast TWT Recommendation field is merely a recommendation, i.e., a STA scheduled for TWT should not transmit frames that do not meet the recommendation in the Broadcast TWT Recommendation subfield in Table 9-299a (Broadcast TWT Recommendation field of the Broadcast TWT element) during the corresponding TWT SP(s).

[0057] There is no discussion on how to ensure that priority traffic (e.g., low latency traffic) can gain access to the medium with a high probability during its assigned TWT SP. To be able to effectively use the TWT mechanism for low latency traffic, the following needs to be addressed: 1. A signaling mechanism to restrict channel access (from unspecified traffic) within the extended TWT (e.g. based on Traffic Identifier (TID) / Access Category (AC)). 2. Protection of enhanced TWT SPs from legacy STAs (notably, TWT is optional in 11ax and not recognized in 11n / 11ac).

[0058] An object of the present disclosure is to substantially overcome the existing problems in order to provide a communication apparatus and a communication method for supporting prioritized traffic, more specifically, low latency traffic, in an EHT WLAN. It is assumed that the present disclosure assumes that the AP has a means for implementing a signaling mechanism (e.g., using a modified Traffic Specification (TSPEC) / Traffic Stream (TS)) to collect the characteristics / needs of prioritized traffic (e.g., low latency, NSEP) of non-AP STAs.

[0059] 3 shows a flowchart 300 illustrating a communication method for prioritizing traffic, according to various embodiments of the present disclosure. In step 302, receiving notification of one or more priority service periods (SPs) from another communication device is performed. Each SP is a period during which only frames belonging to a traffic type specified by the other communication device are permitted to be transmitted. In step 304, determining whether to transmit at least one frame of the specified traffic type during one of the one or more SPs is performed. In step 306, in response to determining that there are no frames of the specified traffic type to transmit, refraining from transmission during one of the one or more SPs.

[0060] According to the present disclosure, a mechanism is proposed that allows only designated traffic to be transmitted within pre-allocated time / frequency resources. In various embodiments of the present disclosure, such pre-allocated time / frequency resources are referred to as Priority Service Periods (SPs). In other words, non-AP STAs are restricted (not permitted) from transmitting undesignated traffic within the Priority Service Periods.

[0061] For example, a non-AP STA may include a receiver that receives notification of one or more preferred SPs from an AP, where the preferred SP is a period during which only frames belonging to a traffic type specified by the AP are allowed to be transmitted, and circuitry that is configured to determine whether to transmit at least one frame of the traffic type specified by the AP in the preferred SP, which circuitry may be further configured to, in response to determining that there are no frames of the specified traffic to transmit in the preferred SP, refrain from transmitting during the preferred SP by the non-AP STA.

[0062] Under such a mechanism, an AP advertises the existence of a preferred SP in a broadcast frame (e.g., a Beacon frame), and only frames belonging to designated traffic (e.g., low latency traffic) and related frames (e.g., Trigger frames, ACKs, BlockAcks (BAs), etc.) are allowed to be transmitted within the preferred SP. As a further constraint, only frames by STAs that have negotiated membership in the preferred SP are allowed to be transmitted during the extended preferred SP.

[0063] In one embodiment, a STA may negotiate membership in one or more preferred SPs by sending a request for membership in the preferred SP to an AP, where the STA's circuitry may be configured to generate a request signal to the AP specifying a parameter set of the preferred SP, such as a minimum wake-up duration, a wake interval, a target wake time, a channel, etc., and the STA's receiver may then receive a response signal from the AP accepting or rejecting the request or proposing an alternative parameter set. The STA's circuitry may be further configured to determine that it is associated with the preferred SP when the response signal indicates acceptance of the parameter set and to set itself up with the parameter set for transmission during the preferred SP.

[0064] In another embodiment, a STA may negotiate membership in one or more preferred SPs by receiving a request to join the preferred SP solicited by the AP, a receiver in the STA may receive a request signal from the AP specifying a parameter set for the preferred SP, such as a minimum wake-up duration, a wake interval, a target wake time, a channel, etc., and circuitry in the STA may be configured to generate a response signal indicating acceptance of the parameter set. The circuitry in the STA may be further configured to determine that it is associated with the preferred SP and to set itself up with the parameter set for transmission during the preferred SP.

[0065] In various embodiments below, when a STA is associated with a preferred SP(s), it means that the STA has successfully negotiated with the AP, has been granted membership in the preferred SP(s) by the AP, and the STA is a member of the preferred SP(s).

[0066] Upon successful negotiation, a non-AP STA granted membership to a preferred SP by the AP is permitted to transmit frames belonging to designated traffic (e.g., low latency traffic) and related frames (Trigger frames, ACKs, BAs, etc.) in the preferred SP. All non-AP STAs in a BSS are expected to be aware of all preferred SPs supported by their associated APs and to refrain from attempting to transmit during preferred SPs of which they are not a member or when they do not have designated traffic to transmit (even if they are a member of an SP). Advantageously, this improves the probability of channel access for designated traffic within a BSS.

[0067] Additionally, the present disclosure proposes a mechanism for restricting channel access (especially from pre-EHT (very high throughput) legacy STAs). According to the present disclosure, a receiver of the STA can further receive a legacy frame from the AP during the preferred SP that carries a network allocation vector (NAV) exclusion field, and the circuitry is further configured to, in response to determining that the STA is associated with (is a member of) the preferred SP, refrain from setting the STA's NAV, regardless of whether the legacy frame is addressed to the STA.

[0068] In various embodiments below, EHT+ STA refers to future generation 802.11 devices (i.e., EHT or 11be or later). When operating in power save mode, non-AP STAs may also choose to remain in doze mode across preferred SPs of which they are not members.

[0069] In other words, at the start of a preferred service period, the AP can transmit a NAV-setting (modified) legacy frame (e.g., an RTS frame and / or a CTS frame) carrying a special signal (e.g., a 1-bit) that, when received within the preferred service period of which the STA is a member, indicates to the EHT (or EHT+) STA that it should not set its NAV, even if the legacy frame is not addressed to the STA. It should be understood that any NAV-setting legacy frame may be used (RTS / CTS being the most common example). For example, if an extended Quiet Time Period (QTP) is used as the preferred service period, a Quiet Time Period Setup frame may be used as the NAV-setting legacy frame and may include a bit that informs STAs that negotiated QTP that they are exempt from setting their NAV.

[0070] Any EHT / EHT+ non-AP STA receiving this modified frame within a preferred SP of which it is a member will not set its NAV even if the frame is not addressed to it and will be allowed to transmit the designated traffic via any available access mechanism (e.g., EDCA, Triggered Uplink Access (TUA), UL OFDMA-based random access (UORA), etc.) Advantageously, the preferred SP is protected from legacy STAs.

[0071] Furthermore, to provide prioritized channel access to designated traffic of aperiodic nature, the UORA is customized as a "prioritized UORA." According to the present disclosure, a receiver of the STA may receive from the AP a normal OFDMA Contention Window (OCW) range for the normal UORA and a preferred OCW range. The circuitry of the STA may be further configured to calculate parameters of the preferred UORA based on the received preferred OCW range. The receiver may further receive one or more Trigger frames, each of which allocates one or more RA-RUs and specifies designated traffic types that are allowed to be transmitted in the STA's response frame. Advantageously, aperiodic traffic can be prioritized even outside the preferred SP.

[0072] For purposes of illustrating the present disclosure, various embodiments below use an extended target wake time (TWT) as the priority service period (SP). It should be understood that other specific times or sets of times defined by the AP during which STA(s) are permitted to access and communicate with the AP may also be used. Various existing 802.11 mechanisms / protocols, such as TWT, QTP (quiet period), S-APSD (Scheduled Automatic Power Save Delivery), or RAW (restricted access window), can be enhanced to function as a priority SP. New protocols for prioritized traffic can also be defined. For example, the quiet period protocol used in 802.11ax to set up a quiet period for communication between a pair of STAs in a peer-to-peer manner can be enhanced to accommodate communication between multiple STAs, such as between an AP and multiple associated STAs.

[0073] In the following paragraphs, a first embodiment of the present disclosure related to extended TWT, restrictions, legacy protection, and TWT parameter updates will be described with reference to an AP and STAs serving prioritized traffic.

[0074] According to a first embodiment of the present disclosure, a mechanism is provided to restrict channel access (from unspecified traffic) within an extended TWT (targeting EHT STAs and EHT+ STAs in the same BSS). Under such a mechanism, an AP advertises the existence of an extended TWT SP in a broadcast frame (e.g., a Beacon frame). Within the extended TWT SP, only frames belonging to specified traffic (e.g., low latency traffic or NSEP traffic) and related frames (e.g., Trigger frames, ACKs, BAs, etc.) are allowed to transmit. As a further transmission restriction, only frames from STAs that have negotiated membership in the extended TWT SP are allowed to transmit during the extended TWT SP.

[0075] Similarly, non-AP STAs can negotiate membership to the extended TWT SP with the AP through an exchange of TWT request / response frames. Upon successful negotiation, a non-STA granted membership to the extended TWT SP by the AP is associated with the TWT SP and is permitted to transmit frames belonging to designated traffic (e.g., low latency traffic) and related frames (Trigger frames, ACKs, BAs, etc.) within the extended TWT SP.

[0076] Since information about Extended TWT SPs is broadcast by the AP in every Beacon frame, all non-AP STAs in a BSS are expected to be aware of all Extended TWT SPs supported by their associated APs and to refrain from attempting to transmit during an Extended TWT SP if they are not a member or if they are a member of a TWT SP but do not have the specified traffic. One way to implement this is as follows: when a STA wakes up for an Extended TWT SP, it checks whether it is a member of the TWT SP and whether it has traffic to transmit that belongs to the specified traffic type; if not, it sets its NAV for the duration of the TWT SP, thereby restricting EDCA transmissions (from other traffic types).

[0077] Because the AP and all associated non-AP STAs are expected to be aware of all Extended TWT SPs offered by the AP, all transmission opportunities (TXOPs) acquired by either the AP or non-AP STAs in the BSS immediately prior to the start of an Extended TWT SP are expected to end before the start of the Extended TWT SP.

[0078] Note, however, that this differs from the basic 802.11 rules: currently, non-AP STAs do not need to be aware of TWT SPs of which they are not a member, and therefore non-AP STAs are free to attempt to transmit among TWT SPs of which they are not a member.

[0079] The concept of allocating the medium based on time / frequency to devices, or even traffic types, exists in other communication technologies and has been attempted in the past with 802.11 (e.g., HCF controlled channel access (HCCA) or restricted access window (RAW)), but these have not been successfully utilized due to significant signaling overhead and / or operational complexity. TWT has relatively low complexity and overhead and has been widely adopted since 802.11ax. With minor modifications, TWT can be extended to provide prioritized service to designated traffic.

[0080] 4A shows a flow diagram 400 illustrating communications corresponding to prioritized traffic according to an example of the first embodiment of the present disclosure. A contention-based channel access procedure, e.g., an EDCA procedure, is indicated by blocks 408, 410, 414, 418, 422, 424, 432, and 434. For simplicity, acknowledgement frames (e.g., ACK frames, BlockAck frames) are not explicitly shown, but it should be understood that they are present if necessary. The AP 402 can transmit a Beacon frame 409 to advertise the existence of the extended TWT SPs 421 and 429, which allow only low-latency traffic. A STA, such as STA1 404, that needs access to the channel during the extended TWT SPs 421 and 429 can then negotiate membership in the extended TWT SPs 421 and 429 with the AP 402 through an exchange of TWT request / response frames. Specifically, during the TWT negotiation phase 412, STA1 404 transmits a TWT request frame to the AP 402 requesting membership in the extended TWT SPs 421, 429, and the AP 402 then transmits a TWT response frame to STA1 404 granting membership. During the TWT negotiation phase 412, STA1 404 can request, propose, or solicit a set of TWT parameters in the extended TWT SPs 421, 429, and the AP 402 can accept, reject, or propose an alternative configuration. A first TBTT 416 can also be negotiated during the negotiation phase 412. STA1 is therefore now authorized to access the channel during the extended TWT SPs 421, 429 to exchange low-latency traffic. The Broadcast TWT ID field of the TWT element included in the TWT request frame or TWT response frame is set to a value other than 0 (for example, 1) to indicate a broadcast TWT.

[0081] STA1 can transition to a doze state and wakes up after a first TBTT 416 to receive a Beacon frame 419 from the AP 402. The Beacon frame 419 can include a Broadcast TWT element that contains further TWT information such as a Broadcast TWT (e.g., Broadcast TWT1 420), a TWT wake interval 430, and a minimum TWT wake-up duration (shown as dashed boxes in Extended TWT SPs 421, 429). The TWT element further indicates that the period is an Extended TWT and that only low latency traffic is allowed to be transmitted during this TWT SP.

[0082] STA1 goes to sleep after receiving Beacon frame 419 and can wake up for a broadcast TWT1 SP 421. Because STA1 is a member of the TWT TP and has low latency (LL) traffic to send, when waking up for the extended TWT SP, the STA does not set its NAV. During this first extended TWT SP 421, AP 402 and STA1 404 exchange low latency traffic, such as a low latency downlink (LLDL) signal 423 and a low latency uplink (LLUL) signal 425, respectively.

[0083] STA1 404 may go to sleep after the end of the first extended TWT SP 421. STA1 404 may wake up for the next broadcast TWT1 SP 429 according to the TWT wake interval 430 specified either in the negotiation phase or in the Beacon frame 419. During this second extended TWT SP 429, the AP 402 and STA1 404 transmit an LLDL PPDU 433 and an LLUL PPDU 435, respectively.

[0084] On the other hand, a third party STA, such as STA2 406, that has not negotiated membership with AP 402 and is therefore not a member of the extended TWT SP, is not allowed to access the channel during the extended TWT SPs 421, 429, as indicated by dashed boxes 426, 436. This can be achieved by STA2, when it wakes up for the extended TWT SPs 421, 429, checking whether it is a member of the extended TWT SP, and since it is not, setting its NAV for the duration of the TWT SP.

[0085] Note that ACK / BA are not shown in the figure, but are assumed to be present if applicable. As mentioned above, it is assumed that the AP has collected the low-latency traffic characteristics / needs of non-AP STAs, e.g., using TSPEC. In this example, if STA2 is a member of the TWT SP but does not have low-latency traffic to transmit, STA2 may not begin transmitting other traffic during the TWT SP. Alternatively, instead of the entire TWT SP, only a portion of it (e.g., the first half of the SP, or the period indicated by the Nominal Minimum TWT Wake Duration) may be "reserved" for specified traffic from member STAs, i.e., only a portion of the TWT SP is restricted to other traffic types or third-party STAs. This can be achieved by a STA, when it wakes up for an extended TWT SP, checking whether it is a member of the TWT SP and whether it has traffic to transmit that belongs to the specified traffic type. Otherwise, the STA sets its NAV for the period reserved for the specified traffic (e.g., the first half of the SP, or the period indicated by the nominal minimum TWT wake duration of the TWT SP).

[0086] Note that HE Subchannel Selective Transmission (SST) operation allows non-AP STAs to park on non-primary channels (e.g., secondary 20 MHz or secondary 80 MHz channels) during triggered TWT SP. HE SST non-AP STAs and HE SST APs can set up SST operation by negotiating triggered TWT as defined in 26.8.2 (Individual TWT Agreement). This may be further enhanced by 11be to allow SST operation within 320 MHz.

[0087] 4B shows a flow diagram 440 illustrating communications corresponding to prioritized traffic according to another example of the first embodiment of the present disclosure. In this example, an extended broadcast TWT SP is overlaid on an individual TWT SP to prevent third-party STAs from transmitting during the TWT SP. To further reduce contention within the extended TWT SP, multiple STAs can be scheduled to different subchannels within the TWT SP using SST.

[0088] A contention-based channel access procedure, e.g., an EDCA procedure, is illustrated by blocks 450, 454, 458, 460, 464, and 476. In this embodiment, STA1 444 can create a new TWT session by sending a TWT request frame 451 to the AP 442, and the AP 442 can respond with a TWT response frame that grants STA1 444 membership in the newly created TWT SP. A set of TWT parameters, such as a first TWT 456, is negotiated through the exchange of TWT request / response frames, setting up a TWT agreement for an individual TWT SP between the AP 442 and STA1 444. STA1 can then transition to a sleep state until a TWT SP is initiated after the first TWT 456.

[0089] The AP 402 can send an unsolicited TWT response frame 459 to STA2 446 to set up another TWT agreement for an individual TWT SP that is overlaid on the individual TWT SP with STA1 444. The unsolicited TWT response frame 459 includes a transmission time and a set of TWT parameters for the TWT SP to schedule STA2 446 for simultaneous transmission within the TWT SP. In this embodiment, STA1 444 and STA2 446 are scheduled to the secondary 20 MHz subchannel (S20 MHz) and primary 20 MHz subchannel (P20 MHz), respectively, within the TWT SP using SST.

[0090] The AP 442 then transmits a Beacon frame 461 advertising the presence of the extended Broadcast TWT SPs 463, 475. The Beacon frame 461 may include a Broadcast TWT element containing further TWT information, such as the Broadcast TWT (e.g., Broadcast TWT1 462), the TWT wake interval and minimum TWT wake-up duration (shown by the dashed boxes in the extended TWT SPs 463, 475), and the designated traffic type (low latency). Furthermore, both STA1 444 and STA2 446 may wake up to receive the Beacon frame 461 and return to sleep. A third-party STA (e.g., STA3) also receives the information of the extended TWT SPs through the TWT element in the Beacon frame 461.

[0091] In this embodiment, the extended broadcast TWT SP 463, 475 is overlaid on top of the individual TWT SPs of STA1 444 and STA2 446. STA1 444 and STA2 446 wake up for the broadcast TWT1 SP 463. Both STA1 and STA2 are members of the TWT SP and neither sets their NAV because they have low latency traffic to send, while a third party STA (e.g., STA3) may not wake up for the TWT SP and, even if it did, would set its NAV for the duration of the TWT SP because it is not a member of the TWT SP. During this first extended TWT SP 463, the AP 402 simultaneously transmits a set of LLDL PPDUs and Trigger Frames (TFs) 467, 466 to each of STA1 444 and STA2 446 using the S20 MHz subchannel and the P20 MHz subchannel, respectively, and STA1 444 and STA2 446 respond with LLDL PPDUs 469, 470 using the S20 MHz subchannel and the P20 MHz subchannel, respectively, as scheduled.

[0092] STA1 444 and STA2 446 may transition to a sleep state after the end of the first extended TWT SP 463. According to the TWT wake interval 474 specified in either the negotiation phase 452 or the Beacon frame 461, STA1 444 and STA2 446 may wake up for the next broadcast TWT1 SP 475. During this second extended TWT SP 475, the AP 402 again transmits a set of LLDL PPDUs and Trigger frames (TFs) 479, 478 to each of STA1 444 and STA2 446 using the S20 MHz and P20 MHz subchannels, respectively, and STA1 444 and STA2 446 respond with LLDL PPDUs 481, 482 using the S20 MHz and P20 MHz subchannels, respectively, as scheduled.

[0093] On the other hand, third party STAs such as STA3 448 that have not negotiated membership with AP 442 and are therefore not members of the TWT SP or Extended TWT SP are not permitted to access the channel during Extended TWT SPs 463, 475, as indicated by dashed boxes 472, 484. This can be achieved, for example, by such STAs setting their NAVs to cover the duration of the TWT SP.

[0094] The TWT element can be included in any frame exchanged between the AP and the STA during the negotiation process of the broadcast TWT SP. All details of the TWT agreement between the AP and the STA are conveyed within the TWT element. According to the present disclosure, the TWT element is modified to indicate the extended TWT SP.

[0095] 5 illustrates an exemplary format of a Broadcast TWT element 500 indicating an Enhanced TWT SP. The TWT element 500 may consist of an Element ID field, a Length field, a Control field 502, and a TWT Parameter Information field 504. The Control field 502 is further composed of an NDP (Null Data Packet) Paging Indicator field, a Wake Duration Unit field, and an Enhanced TWT field.

[0096] The TWT Parameter Information field is further comprised of a Request Type field 508, a Target Wake Time field, a Nominal Minimum TWT Wake Duration field, a TWT Wake Interval Mantissa field, and a Broadcast TWT Info field 510. The Request Type field 508 is further comprised of a Broadcast TWT Recommendation field 512, and the Broadcast TWT Info field 510 is further comprised of an Allowed Traffic Type field 514, a Broadcast TWT ID field 516, and a Broadcast TWT Persistence field.

[0097] The Enhanced TWT field 506 can be a single bit set to 1 to indicate it is an enhanced TWT. The meaning of the Broadcast TWT Recommendation field 512 corresponding to each value is shown in Table 2. In particular, a value of 4 in the Broadcast TWT Recommendation field indicates that priority SP restrictions apply. In a TWT SP, different types of traffic can be allowed based on the value of the Allowed Type field 514, as shown in Table 3. In particular, a value of 0 in the Allowed Traffic Type field indicates that low latency traffic is allowed during a TWT SP, while a value of 1 in the Allowed Traffic Type field indicates that other priority traffic (e.g., NSEP) is allowed. The Broadcast TWT ID field is set to a value other than 0 to indicate a broadcast TWT. [Table 2] [Table 3]

[0098] Alternatively, the allowed traffic type (three spare bits are available) can be mapped to the TID of the designated traffic, e.g., 0 = TID 6 (AC_VO), 1 = TID 9 (new TID for low latency), 2 = TID 11 (new TID for NSEP traffic).

[0099] As explained above, one way to ensure that STAs refrain from transmitting traffic that does not belong to the designated traffic during an extended TWT SP is to define a rule that, when a STA wakes up for an extended TWT SP, it checks whether it is a member of the TWT SP and has traffic to transmit that belongs to the designated traffic type. If not, the STA sets its NAV for the duration of the TWT SP, thus restricting any EDCA transmissions (from other traffic types). While entirely possible, adhering to such a rule requires all STAs to be aware of all extended TWT SPs advertised by their associated APs and to set their NAV correctly at the start of each extended TWT SP. However, the above is only possible for EHT (11be) and EHT+ STAs that understand the TWT elements for extended TWT; legacy (pre-EHT) STAs do not follow such a NAV setting rule. According to the present disclosure, an alternative method is also proposed. To protect channel access from legacy (pre-EHT (Very High Throughput)) STAs, Network Allocation Vector (NAV) setting legacy frames, such as RTS and CTS frames, carrying a special signal (e.g., 1 bit) called the NAV Exclusion field are used to indicate to EHT (or EHT+) STAs that when such a NAV setting legacy frame is received within an Enhanced TWT SP of which the EHT (or EHT+) STA is a member, the EHT (or EHT+) STA should not set its NAV (basic NAV and intra-BSS NAV) even if the frame is not the destination of the EHT (or EHT+) STA.

[0100] In this case, either RTS / CTS or CTS-to-Self (sent by the AP and addressed to itself) can be used for such a protection mechanism. Alternatively or additionally, since a TWT SP may be longer than the protection provided by the duration field in the CTS frame, an exchange of multiple RTS / CTS or CTS-to-Self frames within a single TWT SP can be used to protect the entire TWT SP.

[0101] 6 shows a flow diagram 600 illustrating communications corresponding to prioritized traffic according to yet another example of the first embodiment of the present disclosure. In this example, STA1 604 and STA2 606 are EHT (or EHT+) STAs that have negotiated membership with the AP 602 (members of the extended TWT SPs 613, 629) and are therefore allowed to access the channel during the extended TWT SPs 613, 629. Meanwhile, STA3 608 is a legacy (pre-EHT) STA from which the channel for prioritized traffic (e.g., low latency traffic) must be protected.

[0102] A contention-based channel access procedure, e.g., an EDCA procedure, is illustrated by blocks 610, 614, 630, and 642. The AP 602 transmits a Beacon frame 611 that may advertise the presence of extended broadcast TWT SPs 613 and 629. The Beacon frame 611 includes a Broadcast TWT element that includes TWT parameter information such as the Broadcast TWT (e.g., Broadcast TWT1 612), the TWT wake interval, and the minimum TWT wake-up duration (depicted by the dashed boxes in the extended TWT SPs 613 and 629). After receiving the Beacon frame 611, STA1 604, STA2 606, and STA3 608 may transition to a doze state.

[0103] After broadcast TWT1 612, STA1 604, STA2 606, and STA3 608 can wake up. During the first extended TWT SP 613, the AP 602 can send a NAV setting legacy frame 615 (in this case, an RTS frame) addressed to STA1 604. Because the RTS frame 615 is addressed to STA1 604, STA1 604 does not set its NAV upon receiving the RTS frame 615.

[0104] According to this disclosure, STA2 606 is a member of Extended TWT SP 613, so STA2 606 also does not set its own NAV due to the presence of the NAV Exclusion field, even though the RTS frame 615 is not addressed to STA2 606. The NAVs of STA1 and STA2 are indicated by blank bars 616.

[0105] On the other hand, STA3 608 is not a member of the extended TWT SP 613, so STA3 608 sets its own NAV despite the presence of the NAV exclusion field because the RTS frame 615 is not addressed to STA3 608. STA3's NAV is indicated by the dark bar 619.

[0106] STA1 604 transmits a CTS frame 620 in response to receiving the RTS frame 615, in which the value of the NAV Exclusion field is copied from the NAV Exclusion field of the RTS frame 615. The AP 602 may first transmit an LLDL PPDU 622 to STA2 606 and then transmit a Trigger frame 624 to STA1 604 to schedule STA1's transmission. Upon receiving the Trigger frame 624, STA1 604 then transmits an LLDL PPDU 626 to the AP 602. STA1 604, STA2 606, and STA3 608 may transition to a doze state after the end of the first extended TWT SP 613.

[0107] At the start of the next TWT1 SP 629, STA1 604, STA2 606, and STA3 608 can wake up. The AP 602 can send another NAV-setting legacy frame 632 (in this case, a CTS-to-self frame 632 addressed to itself) with the NAV exclusion field set to 1. Because the CTS-to-self frame 632 is addressed to the AP 602, these STAs will not set their NAV upon receiving the CTS-to-self frame 632, as indicated by the blank bar 634, since both STAs are members of the extended TWT SP 629 and have their NAV exclusion fields set to 1.

[0108] Meanwhile, because STA3 608 is not a member of the extended TWT SP 629, STA3 608 sets its own NAV even though the CTS-to-self frame 632 carries a NAV exclusion field set to 1. STA3's NAV is indicated by a dark bar 637. The AP can then send a Trigger frame 642 to STA1 604 to schedule STA1's transmission. Upon receiving the Trigger frame 642, STA1 604 transmits a LLUL PPDU 644 to the AP 602. In this way, the access channel is protected from legacy STAs (i.e., STA3 608). STA1 604, STA2 606, and STA3 608 can transition to a doze state after the second extended TWT SP 629 ends.

[0109] Note that a single bit in an extended broadcast TWT SP (e.g., reserved bit #15 in the Request type field) indicates that TWT protection is enabled for that TWT SP. If the transmission of the specified traffic (e.g., low latency) is completed well before the end of the protected period (indicated by the duration field of the eCTS frame), the AP may also send a CF-End frame (with RA set to the broadcast address) to release the NAV of the third-party STA.

[0110] Furthermore, note that in deployments where there are no pre-11ax legacy STAs (e.g., in the 6 GHz band), MU-RTS / CTS exchanges can be used instead to protect extended TWT SPs. While this protection (i.e., using NAV configuration frames carrying the NAV exclusion field) is targeted at legacy STAs, even EHT / EHT+ non-AP STAs can benefit from this mechanism because they do not need to keep track of all extended TWT SPs in the BSS and can leave the protection of extended TWT SPs to the AP (e.g., using eRST / eCTS frames), thus simplifying the operation for non-AP STAs.

[0111] 7A and 7B show exemplary formats of an RTS frame 700 and a CTS frame 704. The RTS frame 700 consists of a Frame Control field 702, a Duration field, a Receiver Address (RA) field, a Transmitter Address (TA) field, and a Frame Check Sequence (FCS) field. The CTS frame 704 consists of a Frame Control field 706, a Duration field, an RA field, and an FCS field.

[0112] Figure 8 shows exemplary Frame Control fields 702, 706 of the RTS frame 700 and CTS frame 706 of Figures 7A and 7B. The Frame Control field consists of a Protocol Version field, a Type field, a Subtype field, a To Differentiated Services (DS) field, a From DS field, a More Fragments field, a Retry field, a Power Management field, a More Data field, a Protected Frame field, and a +HTC (High Throughput Control) field.

[0113] In the RTS / CTS frame, any one of the fields that are unused in the Control frame, such as the To DS field, the From DS field, the More Fragments field, and the Retry field, may be used to indicate the removal of NAV protection to the EHT / EHT+ STA (e.g., set to 1). In various embodiments below, such an unused field that is set to 1 to indicate the removal of NAV protection may be referred to as a NAV Exclusion field.

[0114] If an EHT / EHT+ STA receives an extended RTS frame 700 with the NAV exclusion field set to, for example, a value of 1, the STA shall set the same NAV exclusion field and value in the extended CTS frame it sends in response. Furthermore, if an EHT / EHT+ STA receives an extended RTS / CTS frame 700, 704 within an extended TWT SP of which it is a member, the STA shall not set its NAV (basic NAV and intra-BSS NAV) even if the RTS / CTS frame is not addressed to it. Under this mechanism, legacy STAs will not understand this special signal (NAV exclusion field) and will set their own NAV. Therefore, priority traffic protection from legacy STAs can be achieved.

[0115] Alternatively, the 11be specification may define a rule that even if the RTS / CTS frame does not contain the "NAV Protection" field, a STA that is a member of an extended TWT will not set its NAV if it receives a NAV setting frame (e.g., an RTS / CTS frame) within an extended TWT SP of which it is a member, even if the frame is not addressed to it.

[0116] Additionally, the AP scheduling the TWT can update the TWT parameters (e.g., Allowed Traffic Type) of an existing TWT agreement for a subsequent TWT SP by sending a TWT Information frame carrying the Allowed Traffic Type field to one of the member STAs of the Extended Broadcast TWT SP. For example, if an NSEP event is triggered, a subsequent Extended TWT SP originally scheduled for low latency traffic can be converted to an Extended TWT SP for NSEP traffic.

[0117] 9 shows an example format of a TWT Information frame 900. The TWT Information frame consists of a Frame Control field, a Duration field, three Address fields (RA, TA, BSSID), a Sequence Control field, an HT Control field, a Category field (set to Unprotected S1G Action), an Action field (set to TWT Information), a TWT Information field, an Allowed Traffic Type field, and an FCS field. The Frame Control field, the Duration field, the three Address fields (RA, TA, BSSID), the Sequence Control field, and the HT Control field can be grouped as a MAC header. The Category field, the Action field, the TWT Information field, and the Allowed Traffic Type field can be grouped as a frame body. Table 4 shows the allowed traffic types for different values ​​of the Allowed Traffic Type field. [Table 4]

[0118] When a member STA of an enhanced broadcast TWT SP receives a TWT information frame carrying an Allowed Traffic Type field, it updates its own record of the TWT SP to reflect the new specified traffic type.

[0119] In the following paragraphs, a second embodiment of the present disclosure related to restricted Trigger frames will be described with reference to APs and STAs serving priority traffic.

[0120] According to the second embodiment of the present disclosure, traffic restrictions are not directly signaled in the extended TWT. Instead, they are signaled using a separate frame transmitted within the extended TWT SP. In fact, the TWT element for the TWT SP may not have any indication that it is an extended TWT. For example, an extended TWT is always a triggered TWT, and a Trigger frame transmitted within the extended TWT signals the traffic restrictions. Under this mechanism, the Trigger frame within the extended TWT prioritizes resource allocation to STAs with designated traffic. Furthermore, scheduling of Trigger frames containing resource allocations for other traffic types can be performed only after member STAs signal (e.g., through buffer status reports) that all of their designated traffic has been transmitted.

[0121] 10 shows a flow diagram 1000 illustrating communications accommodating prioritized traffic according to a second embodiment of the present disclosure. A contention-based channel access procedure, e.g., an EDCA procedure, is illustrated by blocks 1010, 1016, 1032, 1034, 1036, 1038, and 1040. In this example, STA1 1004, STA2 1006, and STA3 1018 are all negotiating membership to an extended TWT SP. Furthermore, STA1 1004 is configured for low-latency traffic only, STA2 1006 is configured for low-latency and NSEP traffic, and STA3 1008 is configured for NSEP traffic only.

[0122] The AP 1002 transmits a Beacon frame 1012 that may advertise the existence of an extended Broadcast TWT SP 1015, 1053. The Beacon frame 1012 includes a Broadcast TWT element that includes TWT parameter information such as a Broadcast TWT (e.g., Broadcast TWT1 1014), a TWT wake interval, and a minimum TWT wake-up duration (depicted by dashed boxes in the extended TWT SP 1015, 1053). STA1 1004, STA2 1006, and STA3 1008 are members of the TWT SP. After receiving the Beacon frame 1012, STA1 1004, STA2 1006, and STA3 1008 can transition to a doze state.

[0123] STA1 1004, STA2 1006, and STA3 1008 can wake up at the start of a first extended TWT SP 1015, and the AP 1002 can send a Trigger frame 1017 to STA1 1004 and STA2 1006 to allocate RUs for low-latency traffic. Upon receiving the Trigger frame 1017, STA1 1004 and STA2 1006 can then send their respective first response frames, e.g., LLUL PPDUs 1018 and 1020, to the AP 1002. The AP 1002 can respond to the LLUL PPDU 1020 with an LLDL PPDU 1022 to STA2 1006. The AP can then send another Trigger frame 1024 to STA1 1004 and STA2 1006 to allocate RUs for low-latency traffic. Upon receiving this other Trigger frame 1024, STA1 1004 and STA2 1006 transmit their respective second response frames, e.g., LLUL PPDUs 1026 and 1028, to the AP 1002. STA3 1008 does not have low latency traffic to transmit and therefore is not allocated resources at the start of the TWT SP.

[0124] Note that the TF in the extended TWT prioritizes resource allocation to STAs with low latency traffic (e.g., STA1 1004 and STA2 1006). The NSEP signals of STA2 and STA3 can be allowed to transmit after all designated traffic has been transmitted and there is unused time left in the extended TWT SP 1015, in which case the AP 1002 can transmit a TF allocating RUs for the NSEP traffic.

[0125] When an NSEP event is triggered, a STA can request priority access for NSEP traffic from the AP. For example, after the first Extended TWT SP 1015 ends, STA2 1006 can send an NSEP request to the AP 1002 to notify it that an NSEP event has been triggered and to request that the allowed traffic type be updated to NSEP traffic. This triggers NSEP priority access for the channel. The AP 1002 can then send an NSEP response frame to STA1 1004 to notify it that only NSEP frames are allowed in subsequent Extended TWT SPs. In this case, STA1 1004, which is configured for low latency traffic, will not be allocated RUs by the AP during subsequent Extended TWT SPs, such as the second Extended TWT SP 1053.

[0126] At the start of the second extended TWT SP 1053, the AP 1002 may transmit a Trigger frame 1041 to STA2 1006 and STA3 1008 to allocate RUs for NSEP traffic. After receiving the Trigger frame 1041, STA2 1006 and STA3 1008 then transmit their respective first uplink frames (e.g., NSEP frames 1042 and 1044) to the AP 1002. The AP 1002 may also transmit a downlink NSEP frame 1046 to STA2 1006. The AP may then transmit another Trigger frame 1048 to STA2 1006 and STA3 1008 to allocate RUs for NSEP traffic. After receiving the other Trigger frame 1048, STA2 1006 and STA3 1008 transmit their respective second uplink frames (e.g., NSEP frames 1050 and 1052) to the AP 1002.

[0127] 11 shows an exemplary Basic Trigger frame 1100. The Basic Trigger frame 1100 consists of a Frame Control field, a Duration field, an RA field, a TA field, a Common field, one or more User Info fields, a Padding field, and an FCS field. The Frame Control field, Duration field, RA field, and TA field can be grouped as a MAC header. The Common field further consists of a Trigger Type field (set to Basic type) and a UL HE-SIG-A2 Reserved field. Each of the one or more User Info fields can consist of an AID 12 field and a Trigger Dependent User Info field 1102, which includes a MAC Protocol Data Unit (MPDU) MU Spacing Factor field, a TID Aggregation Limit field, a Traffic Restrictions field 1104, and a Preferred Access Category (AC) field 1106. When the Traffic Restrictions field 1104 is set to 1, the Preferred AC field signals the allowed traffic type. Table 5 shows the allowed traffic type depending on the value of the Preferred AC field. [Table 5]

[0128] When a non-AP STA receives a Basic Trigger frame 1100 containing an AID 12 field that matches its own AID, it is permitted to transmit frames belonging to the permitted traffic type in a response frame (e.g., a TB PPDU) to the Basic Trigger frame 1100. This non-AP STA shall not transmit frames belonging to other traffic types.

[0129] Alternatively, the reserved bit used as the Traffic Restrictions field and two bits of the Preferred AC field (total of three bits) can be mapped to the TID of the designated traffic, e.g., 0 = TID6 (AC_VO), 1 = TID9 (new TID for low latency), 2 = TID11 (new TID for NSEP traffic). When a non-AP STA receives a Basic Trigger frame containing an AID 12 field that matches its own AID, it is allowed to transmit only frames belonging to the designated TID in the TB PPDU sent in response to the Basic Trigger frame. Non-AP STAs shall not transmit frames belonging to other TIDs.

[0130] As another option, the Trigger Dependent User Info field of the basic Trigger frame can include one additional octet to convey traffic restrictions (eg, the TID of the specified traffic).

[0131] In the following paragraphs, a third embodiment of the present disclosure related to multi-link support will be described with reference to APs and STAs serving prioritized traffic.

[0132] A Multi-Link Device (MLD) is a device that accommodates multiple STAs of the same type (AP or non-AP STAs) and allows simultaneous communication over multiple wireless links. A Non-simultaneous transmit and receive link pair (NSTR) is a link pair for which the MLD indicates limitations on simultaneous transmissions on the link pair due to possible transmit / receive interference between the links (e.g., when the MLD transmits on one link of the pair, it cannot receive on the other link because the two links are close in frequency).

[0133] The extended TWT SPs on multiple different links of an MLD can be negotiated (with the AP MLD) independently on each link, or if the TSF and beacon transmission time (TBTT) between the links of an AP MLD are synchronized, the extended TWT SPs on multiple different links can also be negotiated together through a single negotiation on any of the links.

[0134] An NSTR non-AP multilink device (MLD) assigned to an extended TWT SP on a first link should avoid transmissions during TWT SPs on other links that cause co-device interference to the first link. To support this, the AP MLD and non-AP MLD can negotiate time-overlapping extended TWT SPs (with the same or different TWT IDs) on multiple different links. In particular, when the AP MLD transmits DL prioritized traffic during an extended TWT SP on a first link, the AP MLD can ensure that the non-AP MLD does not simultaneously transmit an UL PPDU on the second link of the NSTR link pair by either (i) transmitting a DL PPDU on the second link to the non-AP MLD or other non-AP STAs, or (ii) triggering an UL PPDU on the second link from other non-AP STAs.

[0135] 12 shows a flow diagram 1200 illustrating communications corresponding to prioritized traffic according to a third embodiment of the present disclosure. In this embodiment, the AP-MLD 1202 transmits a first Beacon frame 1216 to the non-AP MLD 1208 via a first link (i.e., from AP1 1204 to STA1 1210). The AP-MLD 1202 then transmits a second Beacon frame 1222 to the non-AP-MLD 1208 via a second link (i.e., from AP2 1206 to STA2 1212). The first and second Beacon frames 1216, 1222 may advertise the presence of an extended TWT SP (under Broadcast TWT ID1 and Broadcast TWT ID2, respectively) and TWT parameter information (e.g., Broadcast TWT1 and Broadcast TWT2, respectively). In the first extended TWT SP 1225, the AP-MLD 1202 can transmit a Trigger frame 1227 to the non-AP-MLD 1208 via the first link. In response to the Trigger frame 1227, the non-AP-MLD 1208 transmits a response frame (e.g., LLUL PPDU 1228) to the AP-MLD 1202 via the first link under priority traffic. Meanwhile, the AP-MLD 1202 is not permitted to simultaneously transmit an LLDL PPDU 1231 via the second link because this frame is highly likely to be lost due to interference from the uplink frame 1228. This is because an UL transmission (e.g., LLUL PPDU 1228) on one link of the NSTR link pair would cause a DL PPDU (e.g., LLDL PPDU 1231) on the other link to fail, which should be avoided.

[0136] For example, in a second extended TWT SP 1227, the AP-MLD 1202 may transmit two LLDL PPDUs 1229, 1231 to the non-AP-MLD 1208 via a first link and a second link, respectively (the transmissions on the first link and the second link may not be synchronized due to different EDCA procedures 1228, 1230). The AP-MLD 1202 may then transmit a Trigger frame 1233 to another non-AP-MLD or non-AP STA (not shown) via the first link. The AP-MLD 1202 may then receive an UL PPDU from the other non-AP STA / MLD via the first link, and simultaneously the AP-MLD 1202 may transmit an LLDL PPDU 1237 addressed to the non-AP-MLD 1208. In this case, STA2 1212 is able to receive DL PPDU 1237 correctly because STA1 1210 is not transmitting at the same time.

[0137] 13 shows an example TWT setup frame 1300 that may be used to simultaneously negotiate TWT agreements on multiple links. This setup frame may consist of a Frame Control field, a Duration field, three Address fields (RA, TA, BSSID), a Sequence Control field, an HT Control field, a Category field (set to Unprotected S1G Action), an Action field (set to TWT Setup), a Dialog Token field, one or two TWT Element fields 1302, a Multi-link Element field 1304, and an FCS field. The Frame Control field, the Duration field, the three Address fields, the Sequence Control field, and the HT Control field may be grouped as a MAC header. The Category field, Action field, Dialog Token field, TWT Element field 1302, and Multi-link Element field 1304 can be grouped as a frame body.

[0138] The TWT Element field 1302 conveys information about the TWT SP of the link on which the TWT Setup frame is transmitted. The Multi-link Element field 1304 consists of an Element ID field, a Length field, an Element ID Extension field, a Multi-Link Control field (including a Type field 1306 and a Presence Bitmap field), and one or more Link Info fields. The Type field of the Multi-Link Control field is set to Multi-Link TWT Setup. The Link Info field further consists of a Link ID field, a TWT Element field (which conveys one or two TWT elements) 1308, and a Timing Synchronization Offset (TSF) Offset field 1310. The TWT Element field 1308 in the Link Info field carries information about the TWT SP of the link corresponding to the Link ID. The TSF Offset field 1310 relates to the difference in TSF between the link on which the TWT Setup frame is transmitted and the link corresponding to the Link ID. Such a TWT Setup frame 1300 carrying multi-link elements is used to set up extended TWT SPs on multiple different links together through a single negotiation on any of the links.

[0139] In the following paragraphs, a fourth embodiment of the present disclosure related to prioritized uplink OFDMA-based random access (UORA) will be described with reference to an AP and STAs serving prioritized traffic.

[0140] To address priority access for aperiodic designated traffic, a UORA is customized as a "prioritized UORA" so that UORA access to the prioritized random access resource unit (RA-RU) is restricted to the designated traffic. In particular, a prioritized RA-RU is an RA-RU to which traffic restrictions apply (e.g., the Traffic Restrictions field 1104 of the Basic Trigger frame 1100 is set to 1), and the prioritized RA-RU is considered as an eligible RA-RU only for STAs that meet the traffic restrictions for the RA-RU. The prioritized OFDMA backoff (POBO) of an eligible STA can count down for all eligible RA-RUs, including the prioritized RA-RU, but the OFDMA backoff (OBO) of an ineligible STA cannot count down for the prioritized RA-RU. If either the POBO or OBO is 0, the STA wins the UORA contention.

[0141] 14 illustrates a prioritized UORA procedure according to a fourth embodiment of the present disclosure. In this case, STA1 and STA2 are configured for low-latency traffic, and therefore, STA1 and STA2 are prioritized over STA3 in UORA contention. There are prioritized RA-RUs in RU1 and RU5 and normal RA-RUs in RU2-RU4, which are assigned to the STAs (STA1, STA2, STA3) by the AP in the Trigger frame.

[0142] STA1 has an initial POBO of 5, while STA2 has an initial POBO of 4. For STA1 and STA2 configured for designated low latency traffic, the number of eligible RA-RUs is 5 because STA1 and STA2 can access the priority RA-RU and the normal RA-RU. Therefore, STA1 and STA2 have a high probability of obtaining a UORA.

[0143] STA1's POBO counts down from 5 to 0 for five eligible RA-RUs (RU1 to RU5). As a result, STA1 wins the UORA contention and randomly selects one RA-RU (e.g., RU1) (from RU1 to RU5) to transmit in the response frame (TB PPDU). Similarly, STA2's POBO counts down from 5 to 0 for five eligible RA-RUs (RU1 to RU5). As a result, STA2 wins the UORA contention and randomly selects one RA-RU (e.g., RU3) (from RU1 to RU5) to transmit in the response frame (TB PPDU).

[0144] On the other hand, STA3, which is configured for non-low latency traffic, has an initial OBO of 4. Since STA3 can normally access only RA-RUs (R2 to R4), the number of RA-RUs is 3. The OBO of STA3 is counted down from 5 or more to 2. As a result, STA3 cannot win the UORA contention, and traffic from STA3 is restricted.

[0145] Instead of indicating an RA-RU as preferred by signaling traffic restrictions in the Trigger frame, a spare AID other than 0 (e.g., 2044) can be used to represent a preferred RA-RU. In such a case, a STA that has designated traffic to transmit and is not assigned a fixed RU in the Trigger frame can regard both the normal RA-RU (the RU with AID 0) and the preferred RA-RU (e.g., the RU with AID 2044) as eligible RA-RUs for UORA contention, and a STA that does not have designated traffic to transmit can also regard the normal RA-RU (the RU with AID 0) as an eligible RA-RU.

[0146] Furthermore, preferred UORA parameters can be used for designated traffic (e.g., low-latency traffic). In particular, the AP advertises the OFDMA Contention Window (OCW) range for the designated traffic in addition to the OFDMA OCW range for general UORA access in the UORA Parameter element.

[0147] 15 illustrates an exemplary UORA Parameter element 1500. The UORA Parameter element 1500 is comprised of an Element ID field, a Length field, an Element ID Extension field, an OCW Range field 1502, and a Prioritized OCW Range field 1504. The Prioritized OCW Range field 1504 is further comprised of a P_EOCWmin field and a P_EOCWmax field, which, together with the POCW and POBO for prioritized UORA access, are used to calculate P_OCWmin and P_OCWmax according to Equations 1 and 2, respectively. Note that OCWmin, OCWmax, OCW, and OBO are used for default UORA access.

number

[0148] The relationship between P_OCWmin / P_OCWmax and OCWmin / OCWmax can be calculated based on Equations 3 and 4.

number

[0149] POBO is a randomly selected integer in the range from 0 to POCW. By setting P_OCWmin and P_OCWmax smaller than OCWmin and OCWmax, the AP ensures that the specified traffic type has a high probability of gaining UORA access.

[0150] Alternatively or additionally, a STA with designated traffic to transmit may be allowed to subtract its OBO by a value greater than 1 (e.g., 2) for each priority or normal RA-RU during UORA contention, resulting in the OBO of such a STA becoming 0 with a much higher probability than normal traffic.

[0151] In the prioritized UORA procedure, the non-AP EHT STA sets the value of POCW to P_OCWmin obtained from the most recent POCWmin indicated in the Prioritized OCW Range field in the UORA Parameter Set element from the EHT AP, or to default (if no UORA Parameter Set element was received), and initializes its POBO counter to an integer value randomly chosen from a uniform distribution in the range from 0 to POCW.

[0152] If an EHT STA has a pending priority frame to the AP, upon receiving a Trigger frame containing at least one eligible RA-RU, it will contend for the priority UORA and transmit an EHT TB PPDU as shown in the flowchart.If the STA has a pending priority frame to transmit, in addition to the normal eligible RA-RU, the priority RA-RU will also be considered as an eligible RA-RU.

[0153] If the EHT TB PPDU is not successfully transmitted in the selected RA-RU, the non-AP EHT STA updates its POCW to 2×POCW+1 when POCW is less than the value of POCWmax and randomly selects its POBO counter within the range of 0 to POCW. If POCW reaches POCWmax in successive retransmission attempts, POCW remains at the value of POCWmax until POCW is reset.

[0154] 16 shows a flowchart illustrating a preferred UORA procedure 1600 according to one embodiment of the present disclosure. In step 1602, the STA receives a preferred OCW range from the AP and determines whether it has a preferred frame to transmit. If yes, execute step 1604. If no, execute a general UORA in step 1606 and the process may end. In step 1604, determine whether POBO is greater than 0. If it is determined that POBO is not greater than 0, execute step 1608. If yes, the process skips to step 1612.

[0155] In step 1608, POBO is initialized to a random value in the range of 0 to POCW. Then, in step 1610, it is again determined whether POBO is greater than 0. If it is determined that POBO is greater than 0, step 1612 is executed. If not, the process skips to step 1620. In step 1612, it is determined whether POBO is less than or equal to the number of eligible RA-RUs. If yes, POBO is set to 0, and then step 1618 is executed. If it is determined that POBO is not less than or equal to the number of eligible RA-RUs, POBO is set according to the difference between POBO and the number of eligible RA-RUs (POBO=POBO-number of eligible RA-RUs), and then step 1618 is executed.

[0156] In step 1618, it is determined whether POBO is 0. If it is determined that POBO is not 0, the process may end. If yes, execute step 1620. In step 1620, randomly select any one of the eligible RA-RUs (priority RA-RU or normal RA-RU). In step 1622, the UL MU PPDU is transmitted, and the process may end.

[0157] FIG. 17 shows an illustrated flow diagram 1700 for prioritized traffic according to a fourth embodiment of the present disclosure. If the AP recognizes that one or more associated STAs have prioritized traffic that is not periodic in nature, it may attempt to provide such STAs with prioritized channel access by transmitting Trigger frames allocating prioritized RA-RUs at regular intervals (e.g., smaller than the interval between consecutive extended TWT SPs). A contention-based channel access procedure, e.g., an EDCA procedure, is illustrated by blocks 1710, 1716, 1730, 1738, and 1746. The AP 1702 transmits a Beacon frame 1712 that may advertise the presence of an extended Broadcast TWT SP 1715. The Beacon frame 1712 includes a Broadcast TWT IE that includes TWT parameter information such as the Broadcast TWT (e.g., Broadcast TWT1 1714) and the Minimum TWT Wake-Up Duration (depicted by the dashed box in the Extended TWT SP 1715). After receiving the Beacon 1712, STA1 1704 and STA2 1706, which are configured for low latency traffic, can update their UORA parameters, such as P_OCWmin, P_OCWmax, and POCW, based on the most recent Prioritized OCW Range field in the UORA Parameter Set element in the Beacon frame 1712.

[0158] In the extended TWT SP 1715, the AP 1702 may transmit a Trigger frame 1717 including a prioritized RA-RU to STA1 1704, STA2 1706, and STA3 1708 to allocate RUs for prioritized traffic (e.g., low-latency traffic). In this embodiment, STA1 1704 and STA2 1706 have prioritized traffic to transmit and transmit their first uplink frames (e.g., LLUL PPDUs 1718, 1720) using prioritized UORAs. Meanwhile, STA3 does not have prioritized traffic to transmit and therefore uses a normal UORA and cannot win the UORA contention. The AP may then transmit another Trigger frame 1724 to STA1 1704, STA2 1706, and STA3 1708. Similarly, STA1 1704 and STA2 1706 have prioritized traffic to send and transmit their respective second response frames (e.g., LLUL PPDUs 1726, 1728) using prioritized UORAs, and STA3 still cannot win the UORA contention.

[0159] Next, after the end of the extended TWT SP 1715, the AP 1702 can transmit Trigger frames 1732, 1739, 1747 containing prioritized RA-RUs to STA1 1704, STA2 1706, and STA3 1708. Because STA1 1704 and STA2 1706 are eligible for both prioritized and normal RA-RUs, they have a high probability of winning the UORA contention and transmit in a TB PPDU (e.g., UL PPDUs 1734, 1736, 1740, 1748, 1750, respectively) using one of the RA-RUs (prioritized and normal) in response to the Trigger frames 1732, 1739, 1747. Meanwhile, STA3 uses a normal UORA and has a low probability of winning the UORA contention and transmits in a TB PPDU (e.g., UL PPDU 1744 with normal latency) using only a normal RA-RU.

[0160] FIG. 18 illustrates a configuration of a communications device 1800 (e.g., a standalone AP or an associated AP in AP MLD) according to various embodiments of the present disclosure. The communications device 1800 may include at least one antenna 1802 for transmitting and receiving signals (for simplicity, only one antenna is shown in FIG. 18). The communications device may include a wired I / F module 1812, a wireless I / F module 1802, a power supply 1820, at least one memory 1818, a central processing unit (CPU) 1814 including at least one compressor, and at least one secondary storage device 1816. The wireless I / F module 1802 may further include a MAC sublayer 1806 and a PHY sublayer 1804. The MAC sublayer 1806 includes a preferred service period management module 1808, which manages preferred service periods for associated STAs and maintains a record of all such SPs in a preferred service period record 1810. The wireless I / F module 1812, the CPU 1814, at least one memory 1818, and at least one secondary storage device 1816 can together function as circuitry of the communications device 1800 configured to generate TWT response frames, Trigger frames, Multi-STA BlockAck frames, DL MU PPDUs, Beacon frames, LLDL PPDUs, frames containing TWT elements, RTS / CTS frames, TWT information frames, NSEP response frames, NSEP frames, and TWT setup frames for prioritized traffic (e.g., low latency traffic) as described in this disclosure. The antenna 1802 can then transmit the generated frame(s) or PPDU(s) to other communications devices, e.g., STA(s).The antenna 1802 can receive TWT request frames, PS-Poll frames, QoS Null frames, BlockAck frames, TB PPDUs (e.g., LLUL PPDUs, UL PPDUs), CTS frames, NSEP request frames, NSEP frames, and TWT setup frames for prioritized traffic (e.g., low latency traffic) from other communications devices, such as STA(s), as described in this disclosure. Circuitry of the communications device 1800 can then be configured to process the received frame(s) or PPDU(s).

[0161] 19 illustrates a configuration of a communications device 1900 (e.g., a standalone STA or a non-AP MLD associated STA) according to various embodiments of the present disclosure. The communications device may include a radio I / F module 1904, a power supply 1920, at least one memory 1918, a central processing unit 1914 including at least one compressor, and at least one secondary storage device 1916. The radio I / F module 1904 may further include a MAC sublayer 1908 and a PHY sublayer 1906. The MAC sublayer 1908 may include a preferred service period management module 1910 that manages preferred service periods of which the device is a member and maintains a record of all preferred SPs within the BSS in a preferred service period record 1912. The wireless I / F module 1904, the CPU 1914, at least one memory 1918, and at least one secondary storage device 1916 may together function as circuitry of the communications device 1800 configured to generate TWT request frames, PS-Poll frames, QoS Null frames, BlockAck frames, TB PPDUs (e.g., LLUL PPDUs, UL PPDUs), CTS frames, NSEP request frames, NSEP frames, and TWT setup frames for prioritized traffic (e.g., low latency traffic), as described in this disclosure. The antenna 1802 may then transmit the generated frame(s) or PPDU(s) to other communications devices, such as AP(s). The antenna 1802 can receive TWT response frames, Trigger frames, Multi-STA BlockAck frames, DL MU PPDUs, Beacon frames, LLDL PPDUs, frames containing TWT elements, RTS / CTS frames, TWT information frames, NSEP response frames, NSEP frames, and TWT setup frames for prioritized traffic (e.g., low latency traffic) from other communications devices, such as AP(s), as described in this disclosure. Circuitry of the communications device 1800 can then be configured to process the received frame(s) or PPDU(s).

[0162] As described above, embodiments of the present disclosure provide an advanced communication system, communication method, and communication device for accommodating prioritized traffic, and more specifically, low latency traffic, in an EHT WLAN.

[0163] The present disclosure can be implemented by software, hardware, or software cooperating with hardware. Each functional block used in the above-described embodiments can be implemented, in part or in whole, by an LSI such as an integrated circuit. Each process described in each embodiment can be controlled, in part or in whole, by the same LSI or a combination of LSIs. The LSI can be formed as multiple individual chips, or a single chip can be formed to include some or all of the functional blocks. The LSI can include a data input / output unit coupled to it. Depending on the degree of integration, the LSI can also be referred to as an IC, system LSI, super LSI, or ultra LSI. However, the technology for implementing an integrated circuit is not limited to LSI, and can be implemented using dedicated circuits, general-purpose processors, or dedicated processors. Furthermore, FPGAs (Field Programmable Gate Arrays), which can be programmed after LSI fabrication, and reconfigurable processors, which can reconfigure the connections and settings of circuit cells arranged within the LSI, can also be used. The present disclosure can be implemented using digital or analog processing. If future integrated circuit technologies replace LSI as a result of advances in semiconductor technology or other derivative technologies, the future integrated circuit technologies can be used to integrate functional blocks. Biotechnology can also be applied.

[0164] The present disclosure may be implemented by any type of apparatus, device, or system having communication capabilities, referred to as a communications apparatus.

[0165] A communication device can include a transceiver and processing / control circuitry. The transceiver can include and / or function as a receiver and a transmitter. The transceiver (as a transmitter and receiver) can include an RF (radio frequency) module that includes an amplifier, an RF modulator / demodulator, and one or more antennas.

[0166] Some non-limiting examples of such communications devices include telephones (e.g., mobile phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, notebooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smart watches, tracking devices), game consoles, e-readers, telehealth / telemedicine devices, vehicles (e.g., automobiles, airplanes, ships) that provide communications capabilities, and various combinations thereof.

[0167] Communication devices are not limited to portable or mobile devices, but can also include any type of equipment, device, or system that is non-portable or stationary, such as smart home devices (e.g., appliances, lights, smart meters, control panels), vending machines, and any other "thing" in an "Internet of Things" (IoT) network.

[0168] Communications can include exchanging data, for example, through cellular systems, wireless LAN systems, satellite systems, and various combinations thereof.

[0169] A communications device may include devices such as a controller or a sensor coupled to the communications device to perform the communications functions described in this disclosure. For example, a communications device may include a controller or a sensor that generates control or data signals used by the communications device to perform the communications functions of the communications device.

[0170] The communications apparatus may further include infrastructure facilities, such as base stations, access points, and any other apparatus, device, or system that communicate with or control apparatuses such as the apparatuses in the non-limiting examples above.

[0171] Although some features of various embodiments are described with reference to devices, corresponding features also apply to the methods of various embodiments, and vice versa.

[0172] Those skilled in the art will appreciate that numerous changes and / or modifications may be made to the present disclosure as set forth in the specific embodiments without departing from the spirit or scope of the disclosure as broadly described, and the present embodiments are therefore to be considered in all respects as illustrative and not restrictive.

[0173] According to the present disclosure, the following examples have been described.

[0174] 1. A communications device comprising: a receiver that, in operation, receives notification of one or more priority service periods (SPs) from another communications device, each SP being a period during which only frames belonging to a traffic type specified by the other communications device are permitted to be transmitted; and circuitry that, in operation, determines whether to transmit at least one frame of the specified traffic type in one of the one or more SPs, and, in response to determining that there are no frames of the specified traffic type to transmit, refrains from transmitting during one of the one or more SPs.

[0175] 2. The communications device of Example 1, wherein the circuitry is further configured to generate a first request signal to another communications device specifying a set of parameters for one of the one or more SPs, the first request signal including at least one of a minimum wake-up duration, a wake interval, and a channel, the receiver further receives a first response signal from the other communications device indicating acceptance of the specified set of parameters for one of the one or more SPs, and the circuitry is further configured to, in response to receiving the first response signal, determine that the communications device is associated with one of the one or more SPs and set up using the set of parameters to enable transmission between one of the one or more SPs.

[0176] 3. The communications device of Example 1, wherein the receiver is further configured to receive from another communications device a second request signal specifying a set of parameters for one of the one or more SPs, the second request signal including at least one of a minimum wake-up duration, a wake interval, and a channel, and wherein the circuitry is further configured to generate, in response to receiving the second request signal, a second response signal to the other communications device indicating acceptance of the specified set of parameters for one of the one or more SPs, determine that the communications device is associated with one of the one or more SPs, and set up using the set of parameters to enable transmission between one of the one or more SPs.

[0177] 4. The communications device of Example 1, wherein the circuitry is further configured to: generate a third request signal to another communications device, the third request signal including a request to begin transmitting during one of the one or more SPs; and the receiver further receives a third response signal from the other communications device, the response signal indicating that the communications device is authorized to begin transmitting during one of the one or more SPs.

[0178] 5. The communications device of Example 1, wherein one of the one or more SPs is a Broadcast Target Wake Time Service Period (TWT SP), which conveys indication information of a restriction of one of the one or more SPs and specifies a specified traffic type that is permitted to be transmitted during one of the one or more SPs, and the circuitry is further configured to generate one or more frames of the specified traffic type within one of the one or more SPs.

[0179] 6. The communications device of example 1, wherein the designated traffic type is one of low latency traffic or national security and emergency preparedness traffic.

[0180] 7. The communications device of Example 2 or Example 3, wherein the receiver is further configured to receive a legacy frame carrying a network assignment vector (NAV) exclusion field during one of the one or more SPs, and wherein the circuitry is further configured to, in response to determining that the communications device is associated with one of the one or more SPs, refrain from setting the NAV of the communications device regardless of whether the legacy frame is addressed to the communications device.

[0181] 8. The communications device of Example 7, wherein the legacy frame is a Request To Send (RTS) frame carrying a first NAV exclusion field having a NAV exclusion field value and addressed to the communications device, and the circuitry is further configured to generate a Clear To Send (CTS) frame carrying a second NAV exclusion field set to the NAV exclusion field value.

[0182] 9. The communications device of Example 1, wherein one of the one or more SPs is a Broadcast Target Wake Time Service Period (TWT SP) that conveys indication information of a restriction of one of the one or more SPs, and the receiver further receives one or more Trigger frames that specify designated traffic types that are permitted to be transmitted in the response frame during one of the one or more SPs.

[0183] 10. The communications device of Example 1, wherein the receiver receives from another communications device a normal OFDMA contention window (OCW) range and a preferred OCW range for normal uplink OFDMA (orthogonal frequency division multiple access)-based random access (UORA), and the circuitry is configured to calculate parameters of the preferred UORA based on the received preferred OCW range, and the receiver further receives one or more Trigger frames, each of which allocates one or more random access resource units (RA-RUs) to specify a designated traffic type that is allowed to be transmitted in the response frame.

[0184] 11. A communication method performed by a communication device, the communication method comprising the steps of receiving notification of one or more priority service periods (SPs) from another communication device, each SP being a period during which only frames belonging to a traffic type specified by the other communication device are permitted to be transmitted; determining whether to transmit at least one frame of the specified traffic type in one of the one or more SPs; and refraining from transmitting during one of the one or more SPs in response to determining that there are no frames of the specified traffic type to transmit.

[0185] 12. The communication method of Example 11, further comprising: generating a first request signal to another communication device specifying a set of parameters for one of the one or more SPs, the first request signal including at least one of a wake-up time, a minimum wake-up duration, a wake interval, and a channel; receiving a first response signal from the other communication device indicating acceptance of the specified set of parameters for one of the one or more SPs; and, in response to receiving the first response signal, determining that the communication device is associated with one of the one or more SPs and setting up using the set of parameters to transmit between the one or more SPs.

[0186] 13. The communication method of Example 11, further comprising: receiving a second request signal from another communication device specifying a set of parameters for one of the one or more SPs, the second request signal including at least one of a wake-up time, a minimum wake-up duration, a wake interval, and a channel; and, in response to receiving the second request signal, generating a second response signal to the other communication device indicating acceptance of the specified set of parameters for one of the one or more SPs, determining that the communication device is associated with one of the one or more SPs, and setting up the communication device using the set of parameters to enable transmission between one of the one or more SPs.

[0187] 14. The communication method of Example 11, further comprising: generating a third request signal to another communication device, the third request signal including a request to initiate transmission between one of the one or more SPs; and receiving a third response signal from the other communication device, the response signal indicating that the communication device is authorized to initiate transmission between one of the one or more SPs.

[0188] 15. The communication method of Example 11, further comprising: a Broadcast Target Wake Time Service Period (TWT SP) in which one of the one or more SPs conveys indication information of the restrictions of one of the one or more SPs and specifies a specified traffic type that is permitted to be transmitted during one of the one or more SPs; and generating one or more frames of the specified traffic type within one of the one or more SPs.

[0189] 16. The communication method of example 11, wherein the designated traffic type is one of low latency traffic or national security and emergency preparedness traffic.

[0190] 17. The communication method of Example 12 or Example 13, further comprising: receiving, during one of the one or more SPs, a legacy frame that carries a network assignment vector (NAV) exclusion field; and, in response to determining that the communication device is associated with one of the one or more SPs, refraining from setting the communication device's NAV, regardless of whether the legacy frame is addressed to the communication device.

[0191] 18. The communication method of Example 17, wherein the legacy frame is a Request To Send (RTS) frame carrying a first NAV exclusion field having a NAV exclusion field value and addressed to the communication device, and further comprising generating a Clear To Send (CTS) frame carrying a second NAV exclusion field set to the NAV exclusion field value.

[0192] 19. The communication method of Example 11, further comprising receiving, by one of the one or more SPs, one or more Trigger frames that are Broadcast Target Wake Time Service Periods (TWT SPs) that convey indication information of restrictions on one of the one or more SPs and specify designated traffic types that are permitted to be transmitted in the response frame during one of the one or more SPs.

[0193] 20. The communication method of Example 11, further comprising: receiving, from another communication device, a normal OFDMA contention window (OCW) range and a preferred OCW range for normal uplink OFDMA (orthogonal frequency division multiple access)-based random access (UORA); calculating parameters of the preferred UORA based on the received preferred OCW range; and receiving one or more Trigger frames, each of which allocates one or more random access resource units (RA-RUs) and specifies designated traffic types that are allowed to be transmitted in the response frame.

Claims

1. A communication device, a receiver configured to receive, from another communication device, a network allocation vector (NAV) setting legacy frame for setting a quiet period during one of one or more priority service periods (SPs) during which transmission of frames of a traffic type different from a traffic type specified by the other communication device is restricted; a circuit configured to, when receiving the NAV-setting legacy frame, not set the NAV of the communication device, regardless of whether the NAV-setting legacy frame is addressed to the communication device; A communication device comprising:

2. the circuitry is further configured to generate a first request signal to the other communication device specifying a set of parameters for one of the one or more SPs, the first request signal including at least one of a wake-up time, a minimum wake-up duration, a wake interval, and a channel; the receiver further receiving a first response signal from the other communication device indicating acceptance of the set of parameters; the circuitry is further configured to, in response to receiving the first response signal, determine that the communication device is associated with one of the one or more SPs and set up the communication device using the set of parameters for transmission between the one or more SPs. The communication device according to claim 1 .

3. the receiver further receives a second request signal from the other communication device specifying a set of parameters for one of the one or more SPs, the second request signal including at least one of a wake-up time, a minimum wake-up duration, a wake interval, and a channel; the circuitry is further configured to, in response to receiving the second request signal, generate a second response signal to the other communication device indicating acceptance of the set of parameters, determine that the communication device is associated with one of the one or more SPs, and set up the communication device using the set of parameters for transmission between the one or more SPs. The communication device according to claim 1 .

4. the circuitry generates a third request signal to the other communication device, the third request signal including a request to initiate the transmission between one of the one or more SPs; the receiver further receives a third response signal from the other communication device, the third response signal indicating that the communication device is authorized to begin the transmission during one of the one or more SPs. The communication device according to claim 1 .

5. a Broadcast Target Wake Time Service Period (TWT SP) for the one of the one or more SPs, conveying an indication of restrictions on the one of the one or more SPs and specifying the specified traffic type that is permitted to be transmitted during the one of the one or more SPs; the circuitry being further configured to generate, within one of the one or more SPs, one or more frames of the specified traffic type. The communication device according to claim 1 .

6. the designated traffic type is one of low latency traffic or national security and emergency preparedness traffic; The communication device according to claim 1 .

7. the circuitry is further configured, in response to determining that the communication device is associated with one of the one or more SPs, to not set the NAV of the communication device regardless of whether the NAV-setting legacy frame is addressed to the communication device. The communication device according to claim 1 .

8. the NAV-set legacy frame is a Request To Send (RTS) frame that carries a first NAV exclusion field having a NAV exclusion field value and is addressed to the communication device; the circuitry is further configured to generate a Clear To Send (CTS) frame carrying a second NAV exclusion field set to the NAV exclusion field value. The communication device according to claim 7.

9. a Broadcast Target Wake Time Service Period (TWT SP) in which the one of the one or more SPs conveys an indication of a restriction of the one of the one or more SPs; the receiver further receives, during one of the one or more SPs, one or more Trigger frames that specify the specified traffic types that are permitted to be transmitted in the response frame; The communication device according to claim 1 .

10. the receiver receives from the other communication device a normal OFDMA (Orthogonal Frequency Division Multiple Access) contention window (OCW) range and a preferred OCW range for normal uplink OFDMA-based random access (UORA); the circuitry is configured to calculate a parameter of a preferred UORA based on the received preferred OCW range; the receiver further receives one or more Trigger frames, each of which allocates one or more Random Access Resource Units (RA-RUs) to specify the designated traffic types that are allowed to be transmitted in the response frame. The communication device according to claim 1 .

11. 1. A communication method performed by a communication device, comprising: receiving a network allocation vector (NAV) setting legacy frame from another communication device to set a quiet period during one of one or more priority service periods (SPs) during which transmission of frames of a traffic type different from a traffic type specified by the other communication device is restricted; when receiving the NAV-setting legacy frame, not setting the NAV of the communication device regardless of whether the NAV-setting legacy frame is addressed to the communication device; The communication method further comprises:

12. generating a first request signal to the other communication device specifying a set of parameters for one of the one or more SPs, the first request signal including at least one of a wake-up time, a minimum wake-up duration, a wake interval, and a channel; receiving a first response signal from the other communication device indicating acceptance of the set of parameters; in response to receiving the first response signal, determining that the communication device is associated with one of the one or more SPs; using said set of parameters to set up for transmission between one of said one or more SPs; The communication method of claim 11 further comprising:

13. receiving a second request signal from the other communication device specifying a set of parameters for one of the one or more SPs, the second request signal including at least one of a wake-up time, a minimum wake-up duration, a wake interval, and a channel; in response to receiving the second request signal; generating a second response signal to the other communication device indicating acceptance of the set of parameters; determining that the communication device is associated with one of the one or more SPs; using said set of parameters to set up for transmission between one of said one or more SPs; The communication method of claim 11 further comprising:

14. generating a third request signal to the other communication device, the third request signal including a request to initiate the transmission between one of the one or more SPs; receiving a third response signal from the other communication device, the third response signal indicating that the communication device is authorized to begin the transmission during one of the one or more SPs; The communication method of claim 11 further comprising:

15. a Broadcast Target Wake Time Service Period (TWT SP) in which the one of the one or more SPs conveys an indication of the restrictions of the one of the one or more SPs and specifies the specified traffic type that is allowed to be transmitted during the one of the one or more SPs, and generating one or more frames of the specified traffic type within the one of the one or more SPs; The communication method of claim 11 further comprising:

Images