Wireless communication method using shared TXOP and wireless communication terminal using the same

Abstract

This invention provides a wireless communication method using a shared TXOP and a wireless communication terminal that uses the same. [Solution] A station for a wireless communication system is disclosed. The station includes a transceiver unit and a processor that controls the transceiver unit. The processor receives a trigger frame from an Access Point (AP) that triggers an uplink transmission, the trigger frame allocates a portion of the transmission opportunity (TXOP) acquired by the AP to the station as a shared TXOP, transmits a CTS frame in response to the trigger frame, and switches a first EDCA (enhanced distributed channel access) parameter set used for channel access to a second EDCA parameter set based on the transmission to the AP within the shared TXOP.

Description

Technical Field

[0001] The present invention relates to a wireless communication method using a shared TXOP and a wireless communication terminal using the same.

Background Art

[0002] Recently, as the spread of mobile devices has expanded, wireless LAN (Local Area Network) technology that can provide fast wireless Internet services to them has been in the spotlight. Wireless LAN technology is a technology that enables mobile devices such as smartphones, smart pads, laptop PCs, portable multimedia players, and embedded devices to be wirelessly connected to the Internet at home, in enterprises, or in specific service-providing areas based on wireless communication technology at short distances.

[0003] Since IEEE (Institute of Electrical and Electronics Engineers) 802.11 supported the initial wireless LAN technology using a 2.4 GHz frequency, various technology standards have been put into practical use or are under development. First, IEEE 802.11b uses a frequency in the 2.4 GHz band and supports a communication speed of up to 11 Mbps. IEEE 802.11a, which was commercialized after IEEE 802.11b, uses a frequency in the 5 GHz band instead of the 2.4 GHz band, reducing the impact on interference compared to the rather congested 2.4 GHz band frequency, and uses OFDM (Orthogonal Frequency Division Multiplexing) technology to improve the communication speed up to 54 Mbps. However, IEEE 802.11a has the disadvantage of having a shorter communication distance than IEEE 802.11b. And IEEE 802.11g uses a frequency in the 2.4 GHz band like IEEE 802.11b to implement a communication speed of up to 54 Mbps, satisfies backward compatibility, and has received considerable attention, but is also superior to IEEE 802.11a in terms of communication distance.

[0004] Furthermore, IEEE 802.11n is a technical standard established to overcome the limitations in communication speed that had been pointed out as a vulnerability in wireless LANs. The purpose of IEEE 802.11n is to increase network speed and reliability and extend the operating range of wireless networks. Specifically, IEEE 802.11n supports high throughput (HT) with a data processing speed of up to 540 Mbps or more, and is based on MIMO (Multiple Inputs and Multiple Outputs) technology, which uses multiple antennas at both the transmitter and receiver ends to minimize transmission errors and optimize data speed. In addition, this standard uses a coding method that transmits multiple duplicate copies to improve data reliability.

[0005] As the proliferation of wireless LANs accelerates and the applications using them diversify, there is a growing need for new wireless LAN systems that can support very high throughput (VHT) higher than the data processing speed supported by IEEE 802.11n. Among these, IEEE 802.11ac supports a wide bandwidth (80MHz to 160MHz) at the 5GHz frequency. Although the IEEE 802.11ac standard is defined only in the 5GHz band, early 11ac chipsets are expected to support operation in the 2.4GHz band for backward compatibility with older 2.4GHz band products. Theoretically, this standard allows for a minimum wireless LAN speed of 1Gbps and a maximum single-link speed of 500Mbps. This is achieved by extending the wireless interface concepts accepted in 802.11n, including wider radio frequency bandwidth (up to 160MHz), more MIMO spatial streams (up to 8), multi-user MIMO, and high-density modulation (up to 256QAM). Another method for transmitting data using the 60GHz band instead of the conventional 24GHz / 5GHz band is IEEE 802.11ad. IEEE 802.11ad is a transmission standard that utilizes beamforming technology to provide speeds of up to 7Gbps, making it suitable for streaming large amounts of data and high-bitrate video such as uncompressed HD video. However, the 60GHz frequency band has the disadvantage of being difficult to pass through obstacles, limiting its use to short-range devices.

[0006] Meanwhile, the IEEE 802.11ax (High Efficiency WLAN, HEW) standard has been developed and is nearing completion as a wireless LAN standard for 802.11ac and 802.11ad and beyond, to provide highly efficient and high-performance wireless LAN communication technology in high-density environments where access points (APs) and terminals are densely packed. In an 802.11ax-based wireless LAN environment, it is necessary to provide highly frequency-efficient communication indoors and outdoors in the presence of high-density stations and APs (Access Points), and various technologies have been developed to realize this.

[0007] Furthermore, in order to support new multimedia applications such as high-definition video and real-time games, development has begun on a new wireless LAN standard to increase the maximum transmission speed. The 7th generation wireless LAN standard, IEEE 802.11be (Extremely High Throughput, EHT), is currently under development with the goal of supporting a maximum transmission rate of 30 Gbps in the 2.4 / 5 / 6 GHz band through wider bandwidth, increased spatial streams, and multiple AP coordination. [Overview of the Initiative] [Problems that the invention aims to solve]

[0008] One embodiment of the present invention aims to provide a wireless communication method using a shared TXOP and a wireless communication terminal using the same. [Means for solving the problem]

[0009] A station of a wireless communication system according to one embodiment of the present invention includes a transmitting and receiving unit; and a processor that controls the transmitting and receiving unit. The processor receives a trigger frame from an Access Point (AP) that triggers an uplink transmission, the trigger frame allocates a portion of the transmission opportunity (TXOP) acquired by the AP to the station as a shared TXOP, transmits a CTS frame in response to the trigger frame, and switches the first EDCA (enhanced distributed channel access) parameter set used for channel access to a second EDCA parameter set based on the transmission to the AP within the shared TXOP.

[0010] The processor can switch the first EDCA parameter set to the second EDCA parameter set when a QoS (quality of service) data frame is successfully transmitted to the AP within the shared TXOP.

[0011] The processor can switch the first EDCA parameter set to the second EDCA parameter set when the shared station sends a QoS data frame requesting an immediate response to the AP within TXOP, and the processor receives a response to the QoS data frame requesting an immediate response.

[0012] The processor can switch the first EDCA parameter set to the second EDCA parameter set when the station sends a QoS data frame within the shared TXOP that does not request an immediate response from the AP.

[0013] The second EDCA parameter set may be used in place of the first EDCA parameter set, depending on whether or not the UL MU (multiuser) transmission was successful.

[0014] If a QoS data frame is successfully transmitted to the AP within the shared TXOP, the timer value for the residual duration to which the second EDCA parameter set is applied can be set to a value greater than 0.

[0015] The processor does not need to set the timer value to 0 even if the station successfully transmits a signal to the AP that deactivates the UL MU transmission operation within the shared TXOP.

[0016] The processor may set the timer value to 0 if the station successfully transmits a signal to the AP that deactivates the shared TXOP operation.

[0017] The operation method of a station in a wireless communication system according to an embodiment of the present invention may include the steps of: receiving a trigger frame from an Access Point (AP) that triggers an uplink transmission, wherein the trigger frame allocates a portion of the transmission opportunity (TXOP) acquired by the AP to the station as a shared TXOP; transmitting a CTS frame as a response to the trigger frame; and switching a first EDCA (enhanced distributed channel access) parameter set used for channel access to a second EDCA parameter set based on the transmission to the AP within the shared TXOP.

[0018] The step of switching the first EDCA parameter set used for channel access to the second EDCA parameter set may include a step of switching the first EDCA parameter set to the second EDCA parameter set when the station successfully transmits a QoS (quality of service) data frame to the AP within the shared TXOP.

[0019] The step of switching the first EDCA parameter set to the second EDCA parameter set when the station successfully transmits a QoS data frame to the AP within the shared TXOP may include the step of switching the first EDCA parameter set to the second EDCA parameter set when the station transmits a QoS data frame requesting an immediate response to the AP within the shared TXOP and receives a response to the QoS data frame requesting an immediate response.

[0020] The step of switching the first EDCA parameter set to the second EDCA parameter set when the station successfully transmits a QoS data frame to the AP within the shared TXOP may include the step of switching the first EDCA parameter set to the second EDCA parameter set when the station transmits a QoS data frame to the AP within the shared TXOP that does not require an immediate response.

[0021] The second EDCA parameter set may be used in place of the first EDCA parameter set, depending on whether or not the UL MU (multiuser) transmission was successful.

[0022] The step of switching the first EDCA parameter set used for channel access to the second EDCA parameter set may include setting the timer value for the residual duration to which the second EDCA parameter set is applied when a QoS data frame is successfully transmitted to the AP within the shared TXOP to a value greater than 0.

[0023] The step of setting the timer value for the residual duration to which the second EDCA parameter set applies to a value greater than 0 may include a step in which the station successfully transmits a signal to the AP that deactivates the UL MU transmission operation within the shared TXOP, but does not set the timer value to 0.

[0024] The step of setting the timer value for the residual duration to which the second EDCA parameter set applies to a value greater than 0 may include the step of setting the timer value to 0 if the station successfully transmits a signaling to the AP that deactivates the shared TXOP operation. [Effects of the Invention]

[0025] One embodiment of the present invention provides a wireless communication method that efficiently uses a shared TXOP and a wireless communication terminal that uses the same.

Brief Description of the Drawings

[0026] [Figure 1] It is a diagram showing a wireless LAN system according to an embodiment of the present invention. [Figure 2] It is a diagram showing a wireless LAN system according to another embodiment of the present invention. [Figure 3] It is a diagram showing the configuration of a station according to an embodiment of the present invention. [Figure 4] It is a diagram showing the configuration of an access point according to an embodiment of the present invention. [Figure 5] It is a diagram schematically showing the process in which a STA sets a link with an AP. [[ID=​​​​​​​​​​​​​​​​​​​​​​​​​This figure shows a wireless LAN function according to one embodiment of the present invention. [Figure 15] This figure shows the uplink (UL) multi-user (MU) operation according to one embodiment of the present invention. [Figure 16] This figure shows a trigger frame format according to one embodiment of the present invention. [Figure 17] This figure shows a method for instructing a trigger-based PPDU format according to one embodiment of the present invention. [Figure 18] This figure shows an example of UL MU operation according to one embodiment of the present invention. [Figure 19] This figure shows a method for sharing a TXOP according to one embodiment of the present invention. [Figure 20] This figure shows a method related to TXOP sharing and NAV configuration according to one embodiment of the present invention. [Figure 21] This figure shows TXOP sharing and CTS frame transmission according to one embodiment of the present invention. [Figure 22] This figure shows an example of a trigger frame for sharing a TXOP according to one embodiment of the present invention. [Figure 23] This figure shows a NAV timeout according to one embodiment of the present invention. [Figure 24] This figure shows TXOP sharing and NAV timeout according to one embodiment of the present invention. [Figure 25] This figure shows TXOP sharing and NAV timeout according to yet another embodiment of the present invention. [Figure 26] This figure shows TXOP sharing and NAV timeout according to yet another embodiment of the present invention. [Figure 27] This figure shows that STA and AP apply NAV when TXOP sharing is applied according to one embodiment of the present invention. [Figure 28] This figure shows that STA terminates sharing of TXOP according to one embodiment of the present invention. [Figure 29]This figure shows a method, according to an embodiment of the present invention, for signaling the format of the TB PPDU in response to a trigger frame using the Common Info field and Special User Info field contained in the trigger frame. [Figure 30] This figure shows how a station according to an embodiment of the present invention sets the TXVECTOR parameter when transmitting a frame as a response to a modified MU-RTS frame. [Figure 31] This figure shows the configuration of the management frame and the MU EDCA Parameter Set element according to an embodiment of the present invention. [Figure 32] This invention demonstrates how a station assigned to a shared TXOP according to an embodiment of the present invention can configure the MU EDCA parameter set. [Figure 33] This figure shows the operation of a station according to an embodiment of the present invention to recover a shared TXOP after allocating one. [Figure 34] This figure shows that, according to an embodiment of the present invention, the shared TXOP assigner performs TXOP recovery after the shared TXOP has terminated. [Figure 35] This figure shows that, according to yet another embodiment of the present invention, the shared TXOP assigner performs TXOP recovery after the shared TXOP has ended. [Figure 36] This figure shows that, according to yet another embodiment of the present invention, the shared TXOP assigner performs TXOP recovery after the shared TXOP has ended. [Figure 37] This figure shows the frame format according to an embodiment of the present invention. [Figure 38] This figure shows how an AP according to an embodiment of the present invention decodes the UL MU Disable subfield and the UL MU Data Disable subfield of the OM Control field. [Figure 39]This figure shows how a station according to an embodiment of the present invention sets the MU EDCA parameter set based on the UL MU Disable subfield and the UL MU Data subfield. [Figure 40] This figure shows how an AP according to yet another embodiment of the present invention decodes the UL MU Disable subfield and the UL MU Data Disable subfield of the OM Control field. [Figure 41] This figure shows the operation in which a station according to an embodiment of the present invention sets the MU EDCA parameter set based on a shared TXOP operation. [Figure 42] This figure shows the operation in which a station according to an embodiment of the present invention sets the MU EDCA parameter set based on a shared TXOP operation. [Modes for carrying out the invention]

[0027] The terms used herein have been selected to the greatest extent possible from among commonly used terms, taking into account the function of the present invention, although this may differ depending on the intent, conventions, or emergence of new technologies of the articulators. In addition, in certain cases, terms have been arbitrarily selected by the applicant, and in such cases, their meanings will be described in the relevant section of the invention description. Therefore, it should be made clear that the terms used herein are not merely names of terms, but should be interpreted based on the substantive meaning of the terms and the overall content of this specification.

[0028] Throughout the specification, when one component is described as being "connected" to another, this includes not only cases where they are "directly connected," but also cases where they are "electrically connected" with other components in between. Furthermore, when a component is described as "containing" a particular component, this means, unless otherwise stated, that it may contain other components rather than excluding them. In addition, limitations such as "greater than or equal to" or "less than or equal to" a specific threshold may be appropriately replaced by "greater than" or "less than" depending on the embodiment.

[0029] In the present invention, the terms "field" and "subfield" may be used interchangeably.

[0030] Figure 1 shows a wireless LAN system according to one embodiment of the present invention.

[0031] A wireless LAN system includes one or more Basic Service Sets (BSS), where a BSS represents a set of devices that have successfully synchronized and can communicate with each other. Generally, BSSs are classified into infrastructure BSSs and independent BSSs (IBSSs), and Figure 1 shows an infrastructure BSS.

[0032] As shown in Figure 1, the infrastructure BSS BSS1, BSS2 includes one or more stations STA1, STA2, STA3, STA4, STA5, access points AP-1, AP-2 which are stations that provide distribution services, and a distribution system DS that connects multiple access points AP-1, AP-2.

[0033] A Station (STA) is any device that includes Medium Access Control (MAC) and a Physical Layer interface to a wireless medium in accordance with the IEEE 802.11 standard, and in a broad sense includes not only non-AP stations but also all access point (AP) stations. In this specification, "terminal" is used to refer to non-AP, AP, or both. A station for wireless communication includes a processor and a communication unit, and depending on the embodiment, further includes a user interface unit and a display unit, etc. The processor generates frames to be transmitted over the wireless network or processes frames received over the wireless network, and performs various other processing for controlling the station. The communication unit is functionally connected to the processor and sends and receives frames over the wireless network for the station. In this invention, "terminal" is used as a term that includes user equipment (UE).

[0034] An Access Point (AP) is an individual device that provides connectivity to a distribution system (DS) via a wireless medium for stations associated with it. In infrastructure BSS, communication between non-AP stations is generally conducted via APs, however, direct communication is possible between non-AP stations if a direct link is configured. In this invention, AP is used as a concept that includes PCP (Personal BSS Coordination Point), but in a broader sense, it includes all concepts such as central controllers, base stations (BS), node B, BTS (Base Transceiver System), or site controllers. In this invention, AP is also referred to as a base wireless communication terminal, but in a broader sense, base wireless communication terminal is used as a term that includes APs, base stations, eNBs (eNodeBs), and transmission points (TPs). Furthermore, base wireless communication terminals include various forms of wireless communication terminals that allocate and schedule communication medium resources in communication with multiple wireless communication terminals.

[0035] Multiple infrastructure BSSs are connected to each other via a distribution system DS. In this case, multiple BSSs connected via the distribution system are called an Extended Service Set (ESS).

[0036] Figure 2 shows an independent BSS, which is a wireless LAN system according to another embodiment of the present invention. In the embodiment of Figure 2, redundant explanations are omitted for parts that are the same as or corresponding to the embodiment of Figure 1.

[0037] As shown in Figure 2, BSS3 is an independent BSS and does not include APs, so all stations (STA6, STA7) are not connected to APs. An independent BSS is not allowed to connect to a distribution system and forms a self-contained network. In an independent BSS, each station (STA6, STA7) is directly connected to one another.

[0038] Figure 3 is a block diagram showing the configuration of a station 100 according to one embodiment of the present invention. As shown, the station 100 according to the embodiment of the present invention includes a processor 110, a communication unit 120, a user interface unit 140, a display unit 150, and a memory 160.

[0039] First, the communication unit 120 transmits and receives wireless signals such as wireless LAN packets and may be incorporated into or externally mounted to the station 100. According to one embodiment, the communication unit 120 may include at least one communication module that uses different frequency bands. For example, the communication unit 120 may include communication modules for different frequency bands such as 2.4GHz, 5GHz, 6GHz, and 60GHz. According to one embodiment, the station 100 may include a communication module that uses a frequency band of 7.125GHz or higher and a communication module that uses a frequency band of 7.125GHz or lower. Each communication module can wirelessly communicate with an AP or external station based on the wireless LAN standard of the frequency band supported by the communication module. Depending on the performance and requirements of the station 100, the communication unit 120 may operate only one communication module at a time or operate multiple communication modules together simultaneously. When the station 100 includes multiple communication modules, each communication module may be provided in an independent form, or the multiple modules may be integrated as a single chip. In embodiments of the present invention, the communication unit 120 can represent an RF (Radio Frequency) communication module that processes RF signals.

[0040] Next, the user interface 140 includes various forms of input / output means provided in the station 100. In other words, the user interface unit 140 receives user input using various input means, and the processor 110 controls the station 100 based on the received user input. The user interface unit 140 also outputs based on instructions from the processor 110 using various output means.

[0041] Next, the display unit 150 outputs an image to the display screen. The display unit 150 outputs various display objects, such as content generated by the processor 110 or user interfaces based on control instructions from the processor 110. The memory 160 stores control programs used by the station 100 and various data associated with them. Such control programs include connection programs necessary for the station 100 to connect with APs or external stations.

[0042] The processor 110 of the present invention executes various instructions or programs and processes data within the station 100. The processor 110 also controls each unit of the station 100 and controls the transmission and reception of data between units. In an embodiment of the present invention, the processor 110 executes a program for connection with the AP stored in the memory 160 and receives a communication setup message transmitted by the AP. The processor 110 also reads information regarding the priority conditions of the station 100 contained in the communication setup message and requests a connection to the AP based on the priority conditions of the station 100. The processor 110 of the present invention may refer to the main control unit of the station 100, or, depending on the embodiment, may refer to a control unit for individually controlling a part of the station 100's configuration, such as the communication unit 120. In other words, the processor 110 may be a modem or a modulator and / or demodulator that modulates and demodulates the wireless signals transmitted and received from the communication unit 120. The processor 110 controls various operations of wireless signal transmission and reception of the station 100 according to an embodiment of the present invention. A detailed embodiment of this will be described later.

[0043] The station 100 shown in Figure 3 is a block diagram according to one embodiment of the present invention, and the separately shown blocks represent logically distinguished elements of the device. Therefore, the above-mentioned elements of the device are mounted on one chip or multiple chips depending on the design of the device. For example, the processor 110 and the communication unit 120 may be integrated and implemented on a single chip, or they may be implemented on separate chips. Furthermore, in the embodiment of the present invention, some components of the station 100, such as the user interface unit 140 and the display unit 150, may be selectively provided in the station 100.

[0044] Figure 4 is a block diagram showing the configuration of AP200 according to one embodiment of the present invention. As shown, AP200 according to an embodiment of the present invention includes a processor 210, a communication unit 220, and a memory 260. In Figure 4, redundant explanations are omitted for parts of the AP200 configuration that are the same as or correspond to the configuration of station 100 in Figure 3.

[0045] Referring to Figure 4, the AP200 according to the present invention includes a communication unit 220 for operating a BSS in at least one frequency band. As described above in the embodiment of Figure 3, the communication unit 220 of the AP200 may also include a plurality of communication modules using different frequency bands. That is, the AP200 according to an embodiment of the present invention may include two or more communication modules using different frequency bands, for example, 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz. Preferably, the AP200 may include a communication module using a frequency band of 7.125 GHz or higher and a communication module using a frequency band of 7.125 GHz or lower. Each communication module can communicate wirelessly with the station based on the wireless LAN standard of the frequency band supported by the communication module. Depending on the performance and requirements of the AP200, the communication unit 220 may operate only one communication module at a time or operate multiple communication modules together simultaneously. In an embodiment of the present invention, the communication unit 220 may represent an RF (Radio Frequency) communication module that processes RF signals.

[0046] Next, the memory 260 stores the control program used by the AP200 and various data associated with it. Such a control program includes a connection program that manages the connection of stations. The processor 210 controls each unit of the AP200 and controls the transmission and reception of data between units. In one embodiment of the present invention, the processor 210 executes the program for connecting with stations stored in the memory 260 and sends a communication setting message to one or more stations. In this case, the communication setting message includes information regarding the connection priority conditions of each station. The processor 210 also sets up the connection in response to the connection request from the station. In one embodiment, the processor 210 is a modem or modulation / demodulation unit that modulates and demodulates the wireless signals transmitted and received from the communication unit 220. The processor 210 controls various operations of wireless signal transmission and reception of the AP200 according to the embodiment of the present invention. A detailed embodiment relating thereto will be described later.

[0047] Figure 5 is a schematic diagram illustrating the process by which STA establishes a link with AP.

[0048] Referring to Figure 5, the link between STA100 and AP200 is established through three main steps: scanning, authentication, and association. First, the scanning step is the step in which STA100 obtains connection information for the BSS operated by AP200. There are two methods for performing scanning: passive scanning, which obtains information using only the beacon message S101 that AP200 periodically transmits, and active scanning, in which STA100 sends a probe request to AP S103, receives a probe response from AP S105, and obtains connection information.

[0049] In the scanning step, if STA100 successfully receives wireless connection information, it sends an authentication request (S107a), receives an authentication response from AP200 (S107b), and performs the authentication step. After the authentication step is performed, STA100 sends an association request (S109a), receives an association response from AP200 (S109b), and performs the association step. In this specification, "association" basically means wireless coupling, but the present invention is not limited to this, and in a broad sense, coupling includes all wireless and wired couplings.

[0050] Meanwhile, an additional 802.1X-based authentication step S111 and an IP address acquisition step S113 via DHCP are performed. In Figure 5, Server 300 is a server that processes authentication between STA100 and the 802.1X-based system, and may be physically connected to AP200 or exist as a separate server.

[0051] Figure 6 shows the CSMA (Carrier Sense Multiple Access) / CA (Collision Avoidance) method used in wireless LAN communication.

[0052] A terminal performing wireless LAN communication checks whether a channel is busy or not by performing carrier sensing before transmitting data. If a wireless signal above a certain strength is detected, the channel is determined to be busy, and the terminal delays access to that channel. This process is called Clear Channel Assessment (CCA), and the level at which the detection of the signal is determined is called the CCA threshold. If a wireless signal above the CCA threshold is received by the terminal and the terminal is the recipient, the terminal processes the received wireless signal. On the other hand, if no wireless signal is detected from the channel, or if a wireless signal with an intensity lower than the CCA threshold is detected, the channel is determined to be idle.

[0053] If a channel is determined to be idle, each terminal with data to transmit performs a backoff procedure after a time period determined by the status of each terminal, such as an IFS (Inter Frame Space), AIFS (Arbitration IFS), PIFS (PCF IFS), etc. In this embodiment, the AIFS is used as a replacement for the conventional DIFS (DCF IFS). Each terminal waits, decreasing a slot time equal to a random number determined for that terminal during the interval of idle state of the channel, and the terminal that has exhausted all of its slot time attempts to access the channel. The period in which each terminal performs this backoff procedure is called the competition window period. At this time, the random number can be called the backoff counter. That is, the initial value of the backoff counter is set by an integer, which is a random number acquired by the terminal. If a terminal senses that the channel is idle during the slot time, the terminal can decrease the backoff counter by 1. Also, when the backoff counter reaches 0, the terminal may be allowed to access the channel. Therefore, terminal transmission may be permitted when the channel is idle during the AIFS time and the backoff counter slot time.

[0054] If a specific terminal successfully accesses the channel, it transmits data through the channel. However, if the terminal attempting access collides with another terminal, the colliding terminals are each assigned a new random number and perform a further backoff procedure. In one embodiment, the random number newly assigned to each terminal is determined within a range twice the range (competition window, CW) of the random number previously assigned to that terminal (2*CW). Meanwhile, each terminal attempts access again in the next competition window interval by performing a further backoff procedure, but this time, each terminal performs the backoff procedure from the slot time remaining in the previous competition window interval. In this way, each terminal performing wireless LAN communication can avoid collisions with each other for a specific channel.

[0055] <Examples of various PPDU formats> Figure 7 shows examples of various standard generational PPDU (PLCP Protocol Data Unit) formats. More specifically, Figure 7(a) shows an example of a legacy PPDU format based on 802.11a / g, Figure 7(b) shows an example of an HE PPDU format based on 802.11ax, and Figure 7(c) shows an example of a non-legacy PPDU (i.e., EHT PPDU) format based on 802.11be. Figure 7(d) shows the detailed field configuration of L-SIG and RL-SIG commonly used in the aforementioned PPDU formats.

[0056] Referring to Figure 7(a), the legacy PPDU preamble includes L-STF (Legacy Short Training field), L-LTF (Legacy Long Training field), and L-SIG (Legacy Signal field). In embodiments of the present invention, the L-STF, L-LTF, and L-SIG can be referred to as the legacy preamble.

[0057] Referring to Figure 7(b), the HE PPDU preamble further includes RL-SIG (Repeated Legacy Short Training field), HE-SIG-A (High Efficiency Signal A field), HE-SIG-B (High Efficiency Signal B field), HE-STF (High Efficiency Short Training field), and HE-LTF (High Efficiency Long Training field) in addition to the legacy preamble. In embodiments of the present invention, RL-SIG, HE-SIG-A, HE-SIG-B, HE-STF, and HE-LTF can be referred to as the HE preamble. The specific configuration of the HE preamble may be modified according to the HE PPDU format. For example, HE-SIG-B may be used only in the HE MU PPDU format.

[0058] Referring to Figure 7(c), the EHT PPDU preamble further includes RL-SIG (Repeated Legacy Short Training field), U-SIG (Universal Signal field), EHT-SIG-A (Extremely High Throughput Signal A field), EHT-SIG-A (Extremely High Throughput Signal B field), EHT-STF (Extremely High Throughput Short Training field), and EHT-LTF (Extremely High Throughput Long Training field) in addition to the legacy preamble. In embodiments of the present invention, RL-SIG, EHT-SIG-A, EHT-SIG-B, EHT-STF, and EHT-LTF can be referred to as the EHT preamble. The specific configuration of the non-legacy preamble may be modified according to the EHT PPDU format. For example, EHT-SIG-A and EHT-SIG-B may be used in only some of the EHT PPDU formats.

[0059] The L-SIG field included in the PPDU preamble is configured with 64 FFT OFDM and consists of a total of 64 subcarriers. Of these, 48 subcarriers, excluding the guard subcarrier, DC subcarrier, and pilot subcarrier, are used for L-SIG data transmission. Since BPSK and Rate=1 / 2 MCS (Modulation and Coding Scheme) are applied to L-SIG, it may contain a total of 24 bits of information. Figure 7(d) shows the 24-bit information structure of L-SIG.

[0060] Referring to Figure 7(d), the L-SIG includes the L_RATE field and the L_LENGTH field. The L_RATE field consists of 4 bits and indicates the MCS used for data transmission. Specifically, the L_RATE field indicates one of the transmission speeds of 6 / 9 / 12 / 18 / 24 / 36 / 48 / 54 Mbps, which is a combination of a modulation scheme such as BPSK / QPSK / 16-QAM / 64-QAM and a code rate such as 1 / 2, 2 / 3, or 3 / 4. Combining the information from the L_RATE and L_LENGTH fields allows us to determine the total length of the PPDU. In the non-legacy PPDU format, the L_RATE field is set to the minimum speed of 6 Mbps.

[0061] The L_LENGTH field is measured in bytes, with a total of 12 bits allocated, allowing for signaling up to 4095. In combination with the L_RATE field, it can indicate the length of the PPDU. In this case, legacy and non-legacy terminals can parse the L_LENGTH field in different ways.

[0062] First, the method by which a legacy or non-legacy terminal analyzes the length of a PPDU using the L_LENGTH field is as follows: When the L_RATE field is set to 6Mbps, 3 bytes (i.e., 24 bits) may be transmitted in 4us, which is the symbol duration of one 64FFT. Therefore, by adding the 3 bytes corresponding to the SVC field and the Tail field to the L_LENGTH field value and dividing this by the transmission amount of one symbol, which is 3 bytes, the number of 64FFT reference symbols after L-SIG is obtained. After multiplying the obtained number of symbols by the symbol duration of one, which is 4us, and then adding the 20us required for transmission of L-STF, L-LTF, and L-SIG, the length of the PPDU, i.e., the reception time (RXTIME), is obtained. This can be expressed mathematically as shown in Equation 1 below.

[0063]

number

[0064] At this time,

number

[0065]

number

[0066] Here, TXTIME is the total transmission time that constitutes the PPDU, as shown in Equation 3 below. In this case, TX represents the transmission time of X.

[0067]

number

[0068] Referring to the above formula, the length of the PPDU is calculated based on the rounded-up value of L_LENGTH / 3. Therefore, for any value of k, three different values ​​L_LENGTH = {3k+1, 3k+2, 3(k+1)} indicate the same PPDU length.

[0069] Referring to Figure 7(e), the U-SIG (Universal SIG) field persists in EHT PPDUs and subsequent generations of wireless LAN PPDUs, playing a role in distinguishing which generation of PPDU it is, including 11be. The U-SIG is a 64FFT-based OFDM with two symbols, capable of transmitting a total of 52 bits of information. Of these, 43 bits, excluding the 9 bits of CRC / tail, are broadly divided into the VI (Version Independent) field and the VD (Version Dependent) field.

[0070] The VI bit maintains its current bit configuration, allowing current 11be terminals to obtain information about a PPDU from its VI field even when subsequent generations of PPDUs are defined. To this end, the VI field consists of the PHY version, UL / DL, BSS color, TXOP, and Reserved fields. The PHY version field is 3 bits and is responsible for sequentially distinguishing 11be and subsequent generations of wireless LAN standards by version. 11be has a value of 000b. The UL / DL field distinguishes whether the PPDU is an uplink or downlink PPDU. The BSS color represents the BSS identifier defined in 11ax and has a value of 6 bits or more. The TXOP represents the Transmit Opportunity Duration, which was transmitted in the MAC header, but by adding it to the PHY header, the length of the TXOP containing the PPDU can be inferred without decoding the PPDU, and it has a value of 7 bits or more.

[0071] The VD field may consist of the PPDU format as signaling information useful only for the 11be version of PPDU, fields that are common to any PPDU format such as BW, and fields that are defined differently depending on the PPDU format. The PPDU format is a divisor that distinguishes between EHT SU (Single User), EHT MU (Multiple User), EHT TB (Trigger-based), EHT ER (Extended Range) PPDU, etc. The BW field broadly signals five basic PPDU BW options of 20, 40, 80, 160 (80+80), and 320 (160+160) MHz (BW that can be expressed in the form of a power of 20*2 can be called a basic BW), and various remaining PPDU BWs composed of preamble puncturing. In addition, after being signaled at 320 MHz, some 80 MHz may be punctured and then signaled. Furthermore, the punctured and deformed channel shape may be signaled directly in the BW field, or it may be signaled using both the BW field and fields appearing after the BW field (for example, fields within the EHT-SIG field). If the BW field is 3 bits, a total of 8 BW signalings are possible, so a maximum of 3 puncturing modes can be signaled. If the BW field is 4 bits, a total of 16 BW signalings are possible, so a maximum of 11 puncturing modes can be signaled.

[0072] Fields located after the BW field vary depending on the form and format of the PPDU. MU PPDUs and SU PPDUs may be signaled in the same PPDU format. A field to distinguish between MU PPDUs and SU PPDUs may be located before the EHT-SIG field, and additional signaling may be performed for this purpose. Both SU PPDUs and MU PPDUs include the EHT-SIG field, but some fields unnecessary for the SU PPDU may be compressed. In this case, the information of the compressed fields may be omitted or have a reduced size compared to the original fields included in the MU PPDU. For example, in the case of a SU PPDU, the common fields of the EHT-SIG may be omitted or replaced, or user-specific fields may be replaced or reduced to one, resulting in a different configuration.

[0073] Alternatively, the SU PPDU may further include a compression field indicating whether or not it is compressed, and depending on the value of the compression field, some fields (e.g., the RA field) may be omitted.

[0074] If a portion of the EHT-SIG field of an SU PPDU is compressed, the information contained in the compressed field may be signaled together with the uncompressed field (e.g., a common field). In the case of an MU PPDU, since it is a PPDU format for simultaneous reception by multiple users, the EHT-SIG field must be transmitted after the U-SIG field, and the amount of information signaled may be variable. That is, since multiple MU PPDUs are transmitted to multiple STAs, each STA must know the location of the RU to which the MU PPDU is transmitted, the STA to which each RU is assigned, and whether or not the transmitted MU PPDU was sent to them. Therefore, the AP must transmit the EHT-SIG field with the above information included. To this end, the U-SIG field signals information for efficiently transmitting the EHT-SIG field, which may be the number of symbols and / or the modulation method (MCS) of the EHT-SIG field. The EHT-SIG field may include size and location information of the RU assigned to each user.

[0075] In the case of an SU PPDU, multiple RUs may be assigned to the STA, and these RUs may be consecutive or discontinuous. When the RUs assigned to the STA are not consecutive, the STA can efficiently receive the SU PPDU only if it recognizes the punctured RU in the middle. Therefore, the AP can transmit the SU PPDU including information about the punctured RUs among the RUs assigned to the STA (e.g., the puncturing pattern of the RUs). That is, in the case of an SU PPDU, the EHT-SIG field may contain a puncturing mode field that includes information on whether a puncturing mode was applied and the puncturing pattern shown in bitmap format or similar, and the puncturing mode field can signal the form of discontinuous channels appearing within the bandwidth.

[0076] The form of the signaled discontinuous channels is limited and, in combination with the value of the BW field, indicates the BW and discontinuous channel information of the SU PPDU. For example, in the case of an SU PPDU, since it is a PPDU transmitted to only one terminal, the STA can recognize the bandwidth allocated to it from the BW field included in the PPDU, and can recognize the punctured resources within the allocated bandwidth from the puncturing mode field of the U-SIG field or EHT-SIG field included in the PPDU. In this case, the terminal can receive the PPDU on the remaining resource units other than the specific channel of the punctured resource unit. At this time, the multiple RUs allocated to the STA may consist of different frequency bands or tones.

[0077] The reason only limited forms of discontinuous channel configurations are signaled is to reduce the signaling overhead of the SU PPDU. Since puncturing can be performed on each 20MHz subchannel, when puncturing is performed on a bandwidth with multiple 20MHz subchannels, such as 80, 160, and 320MHz, in the case of 320MHz, the usage status of the remaining 15 20MHz subchannels other than the primary channel must be represented, and the discontinuous channel configuration (if a configuration where only the end 20MHz is punctured is also considered discontinuous) must be signaled. Using 15 bits to signal the discontinuous channel configuration for single-user transmission in this way can result in excessive signaling overhead when considering the low transmission speed of the signaling portion.

[0078] This invention proposes a method for signaling the discontinuous channel configuration of an SU PPDU and illustrates the discontinuous channel configuration determined by the proposed method. Furthermore, it proposes a method for signaling the primary 160MHz and secondary 160MHz puncturing configurations, respectively, in a 320MHz BW configuration of an SU PPDU.

[0079] Furthermore, in one embodiment of the present invention, a method is proposed in which the configuration of the PPDU indicated by the preamble puncturing BW value differs depending on the signaled PPDU format in the PPDU format field. Assuming that the BW field is 4 bits, in the case of an EHT SU PPDU or TB PPDU, one symbol of EHT-SIG-A is further signaled after U-SIG, or it is not necessary to signal EHT-SIG-A from the beginning. Taking this into consideration, it is necessary to fully signal up to 11 puncturing modes using only the BW field of U-SIG. However, in the case of an EHT MU PPDU, EHT-SIG-B is further signaled after U-SIG, so up to 11 puncturing modes can be signaled in a different way than in an SU PPDU. In the case of an EHT ER PPDU, the BW field can be set to 1 bit to signal whether the PPDU uses a 20MHz or 10MHz bandwidth. Detailed puncturing patterns for each PPDU type will be described in detail in Figures 11 and 12.

[0080] Figure 7(f) shows the format-specific fields of the VD field when EHT MU PPDU is indicated in the U-SIG PPDU format field. In the case of MU PPDU, SIG-B, which is a signaling field for simultaneous reception by multiple users, is required, and SIG-B may be transmitted after U-SIG without a separate SIG-A. For this purpose, U-SIG must signal information for decoding SIG-B. Such fields include SIG-B MCS, SIG-B DCM, Number of SIG-B Symbols, SIG-B Compression, and Number of EHT-LTF Symbols fields.

[0081] Figure 8 shows examples of various EHT (Extremely High Throughput) PPDU (Physical Protocol Data Unit) formats and methods for specifying them according to embodiments of the present invention.

[0082] Referring to Figure 8, a PPDU may consist of a preamble and a data portion, and one type of format, EHT PPDU, may be distinguished by a U-SIG field included in the preamble. Specifically, whether or not the PPDU format is EHT PPDU may be indicated based on the PPDU format field included in the U-SIG field.

[0083] Figure 8(a) shows an example of the EHT SU PPDU format for a single STA. The EHT SU PPDU is a PPDU used for single-user (SU) transmission between an AP and a single STA, and may have an EHT-SIG-A field for additional signaling after the U-SIG field.

[0084] Figure 8(b) shows an example of an EHT trigger-based PPDU format, which is an EHT PPDU transmitted based on a trigger frame. An EHT trigger-based PPDU is an EHT PPDU transmitted based on a trigger frame and is an uplink PPDU used as a response to a trigger frame. Unlike an EHT SU PPDU, an EHT PPDU does not have an EHT-SIG-A field after the U-SIG field.

[0085] Figure 8(c) shows an example of the EHT MU PPDU format, which is an EHT PPDU for multiple users. An EHT MU PPDU is a PPDU used to send a PPDU to one or more STAs. In the EHT MU PPDU format, the HE-SIG-B field may be located after the U-SIG field.

[0086] Figure 8(d) shows an example of the EHT ER SU PPDU format used for single-user transmissions with STAs in an extended range. EHT ER SU PPDU may be used for single-user transmissions with STAs in a wider range than EHT SU PPDU described in Figure 8(a), and the U-SIG field may be repeatedly positioned on the time axis.

[0087] The EHT MU PPDU described in Figure 8(c) can be used by an AP to transmit downlink data to multiple STAs. In this case, the EHT MU PPDU may include scheduling information so that multiple STAs can simultaneously receive PPDUs transmitted from the AP. The EHT MU PPDU can transmit the AID information of the recipient and / or sender of the PPDU transmitted through the user-specific field of EHT-SIG-B to the STAs. Therefore, multiple terminals that receive the EHT MU PPDU can perform spatial reuse operations based on the AID information in the user-specific field included in the preamble of the received PPDU.

[0088] Specifically, the resource unit allocation (RA) field in the HE-SIG-B field included in the HE MU PPDU may contain information about the configuration of the resource units (e.g., the division of the resource units) within a specific bandwidth on the frequency axis (e.g., 20 MHz). That is, the RA field can instruct the STA on the configuration of the resource units divided by the bandwidth for transmitting the HE MU PPDU in order to receive the PPDU. Information about the STA allocated (or specified) to each divided resource unit may be included in the user-specific field of EHT-SIG-B and transmitted to the STA. That is, the user-specific field may contain one or more user fields corresponding to each divided resource unit.

[0089] For example, among the multiple divided resource units, the user field corresponding to at least one resource unit used for data transmission may contain the recipient's or sender's AID, while the user fields corresponding to the remaining resource units not used for data transmission may contain a previously set Null STA ID.

[0090] For the sake of clarity, the terms frame or MAC frame may be used interchangeably with MPDU in this specification.

[0091] When a single wireless communication device communicates using multiple links, the communication efficiency of the wireless communication device can be increased. In this case, a link is a physical path and may be configured as a single wireless medium that can be used to transmit an MSDU (MAC service data unit). For example, if the frequency band of one link is being used by another wireless communication device, the wireless communication device can continue to communicate using another link. In this way, the wireless communication device can make effective use of multiple channels. Furthermore, when the wireless communication device communicates simultaneously using multiple links, the overall throughput can be increased. However, existing wireless LANs are defined on the premise that one wireless communication device uses one link. Therefore, a wireless LAN operation method for using multiple links is necessary. Referring to Figures 9 to 26, the wireless communication method for a wireless communication device using multiple links will be explained. First, Figure 9 will be used to explain a specific form of a wireless communication device using multiple links.

[0092] Figure 9 shows a multi-link device according to an embodiment of the present invention.

[0093] A multi-link device (MLD) may be defined for the wireless communication method using the multiple links described above. A multi-link device can represent a device having one or more affiliated stations. In specific embodiments, a multi-link device can represent a device having two or more affiliated stations. A multi-link device can also have interchangeable multi-link elements. A multi-link element contains information about one or more stations or one or more links. A multi-link element may include the multi-link setup element described later. In this case, the multi-link device may be a logical entity. Specifically, a multi-link device may have multiple affiliated stations. A multi-link device can be called an MLLE (multi-link logical entity) or an MLE (multi-link entity). A multi-link device may have one medium access control service access point (SAP) up to logical link control (LLC). An MLD may also have one MAC data service.

[0094] Multiple stations included in a multilink system can operate on multiple links. Furthermore, multiple stations included in a multilink system can operate on multiple channels. Specifically, multiple stations included in a multilink system can operate on different links or different channels. For example, multiple stations included in a multilink system can operate on different channels of 2.4GHz, 5GHz, and 6GHz.

[0095] The operation of a multilink device can be called multilink operation, MLD operation, or multi-band operation. Furthermore, if the station paired with the multilink device is an AP (Application Platform), the multilink device can be called an AP MLD (Application Platform Multilink). Conversely, if the station paired with the multilink device is a non-AP station, the multilink device can be called a non-AP MLD (Application Platform Multilink).

[0096] Figure 9 illustrates the communication operation between a non-AP MLD and an AP-MLD. Specifically, the non-AP MLD and AP-MLD communicate using three links each. The AP MLD includes the first AP (AP1), the second AP (AP2), and the third AP (AP3). The non-AP MLD includes the first non-AP STA (non-AP STA1), the second non-AP STA (non-AP STA2), and the third non-AP STA (non-AP STA3). The first AP (AP1) and the first non-AP STA (non-AP STA1) communicate via the first link (Link1). The second AP (AP2) and the second non-AP STA (non-AP STA2) communicate via the second link (Link2). The third AP (AP3) and the third non-AP STA (non-AP STA3) communicate via the third link (Link3).

[0097] Multilink operation may include a multilink setup operation. Multilink setup corresponds to the association operation of the single-link operation described above and must be performed before frame exchange in multilink. A multilink device can obtain the information necessary for multilink setup from a multilink setup element. Specifically, the multilink setup element may include capability information related to multilink. In this case, the capability information may include information indicating whether one of the multiple devices included in the multilink device can transmit and the other devices can receive simultaneously. The capability information may also include information about the links available to each station included in the MLD. Furthermore, the capability information may include information about the channels available to each station included in the MLD.

[0098] Multilink configuration may be established through negotiations between peer stations. Specifically, multilink configuration may be performed through communication between stations without communication with the AP. Furthermore, multilink configuration may be established through any one of the links. For example, even if links 1 through 3 are configured via a multilink, the multilink configuration may be performed through link 1.

[0099] Furthermore, a mapping between TIDs (traffic identifiers) and links may be configured. Specifically, frames corresponding to a specific TID value may be exchanged only through pre-specified links. The mapping between TIDs and links may be configured in a directional-based manner. For example, if multiple links are configured between a first multilink device and a second multilink device, the first multilink device may be configured to send frames with a first TID to multiple first links, and the second multilink device may be configured to send frames with a second TID to the first links. Additionally, a default setting may exist for the mapping between TIDs and links. Specifically, if there are no additional settings in the multilink configuration, the multilink device can exchange frames corresponding to TIDs on each link according to the default setting. In this case, the default setting may be such that all TIDs are exchanged on any one link.

[0100] Let's explain TID in detail. TID is an ID used to classify traffic and data to support QoS (Quality of Service). TID may be used or assigned at layers higher than the MAC layer. TID can also indicate traffic category (TC) and traffic stream (TS). There may be 16 distinct TID values. For example, a TID may be specified as one of the values ​​from 0 to 15. Different TID values ​​may be specified depending on the access policy, channel access, or medium access method. For example, when EDCA (enhanced distributed channel access) or HCAF (hybrid coordination function contention based channel access) is used, the TID value may be assigned in the range of 0 to 7. When EDCA is used, TID can indicate user priority (UP). In this case, UP may be specified by TC or TS. UP may be assigned at layers higher than MAC. Furthermore, when HCCA (HCF controlled channel access) or SPCA is used, the TID value may be assigned in the range of 8 to 15. When HCCA or SPCA is used, TID can represent TSID. Furthermore, when HEMM or SEMM is used, the TID value may be assigned in the range of 8 to 15. When HEMM or SEMM is used, TID can represent TSID.

[0101] UP and AC (access category) may be mapped. AC may be a label for providing QoS in EDCA. AC may be a label for indicating an EDCA parameter set. EDCA parameters or EDCA parameter sets are parameters used in EDCA channel contention. QoS stations can guarantee QoS using AC. AC may also include AC_BK, AC_BE, AC_VI, and AC_VO. AC_BK, AC_BE, AC_VI, and AC_VO can indicate background, best effort, video, and voice, respectively. AC_BK, AC_BE, AC_VI, and AC_VO may also be classified into sub-ACs. For example, AC_VI can be subdivided into AC_VI primary and AC_VI alternate. Similarly, AC_VO can be subdivided into AC_VO primary and AC_VO alternate. UP or TID may also be mapped to AC. For example, each of 1, 2, 0, 3, 4, 5, 6, and 7 in UP or TID may be mapped to AC_BK, AC_BK, AC_BE, AC_BE, AC_VI, AC_VI, AC_VO, and AC_VO, respectively. Also, each of 1, 2, 0, 3, 4, 5, 6, and 7 in UP or TID may be mapped to AC_BK, AC_BK, AC_BE, AC_BE, AC_VI alternate, AC_VI primary, AC_VO primary, and AC_VO alternate, respectively. Furthermore, the priority of 1, 2, 0, 3, 4, 5, 6, and 7 in UP or TID may be in that order from highest to lowest. That is, 1 may have a lower priority and 7 may have a higher priority. Therefore, the priority may be in the order of AC_BK, AC_BE, AC_VI, and AC_VO, from highest to lowest. Furthermore, AC_BK, AC_BE, AC_VI, and AC_VO can each correspond to ACI (AC index) 0, 1, 2, and 3, respectively. Due to these characteristics of TIDs, the mapping between TIDs and links can represent the mapping between ACs and links.Furthermore, the mapping between links and ACs can represent the mapping between TIDs and links.

[0102] As mentioned above, a TID may be mapped to each of multiple links. The mapping may specify which links can exchange traffic corresponding to a particular TID or AC. Additionally, TIDs or ACs that can be transmitted in different transmission directions within a link may be specified. As mentioned above, a default setting may exist for the mapping between TIDs and links. Specifically, in a multilink configuration where no additional settings are made, the multilink device can exchange frames corresponding to TIDs on each link according to the default setting. In this case, the default setting may be that all TIDs are exchanged on any one link. At any given time, any TID or AC may always be mapped to at least one link. Management frames and control frames may be transmitted on all links.

[0103] When a link is mapped to a TID or AC, only data frames corresponding to the TID or AC mapped to that link may be transmitted on that link. Therefore, when a link is mapped to a TID or AC, frames that do not correspond to a TID or AC not mapped to that link do not need to be transmitted on that link. When a link is mapped to a TID or AC, the ACK may also be transmitted based on the link to which the TID or AC is mapped. For example, a block ACK agreement may be determined based on the mapping between TIDs and links. Furthermore, in other specific embodiments, the mapping between TIDs and links may be determined based on a block ACK agreement. Specifically, a block ACK agreement may be set for a TID mapped to a particular link.

[0104] The aforementioned mapping of TIDs to links may ensure QoS. Specifically, a relatively small number of stations may be operational, or higher-priority ACs or TIDs may be mapped to links with good channel conditions. Furthermore, the aforementioned mapping of TIDs to links may enable stations to maintain a power-saving state for longer periods.

[0105] Figure 10 shows a multilink mapped by a TID-to-link mapping method according to an embodiment of the present invention.

[0106] Referring to Figure 10, a mapping relationship between TID and link may exist, as explained in Figure 9. In this invention, the mapping relationship between TID and link can be called TID-to-link mapping, TID to link mapping, TID mapping, link mapping, etc. TID may be a traffic identifier. TID may also be an identifier used to classify traffic, data, etc., in order to support QoS (quality of service).

[0107] Furthermore, TID may be an ID used or assigned at a layer higher than the MAC layer. TID can represent TC (traffic categories) or TS (traffic streams). Also, TID may have 16 values, for example, represented as values ​​from 0 to 15. Furthermore, the TID value used may differ depending on the access policy or channel connection or medium access method. For example, when using EDCA (HCF (hybrid coordination function) contention-based channel connection, enhanced distributed channel connection), possible TID values ​​may be from 0 to 7. Also, when using EDCA, the TID value may represent UP (user priority), and said UP may relate to TC or TS. Also, UP may be a value assigned at a layer higher than MAC. Also, when using HCCA (HCF controlled channel access) or SPCA, possible TID values ​​may be from 8 to 15. Also, when using HCCA or SPCA, TID may represent TSID. Furthermore, when using HEMM or SEMM, the possible TID values ​​may be between 8 and 15. Also, when using HEMM or SEMM, the TID may represent the TSID.

[0108] Furthermore, a mapping relationship between UP and access category (AC) may exist. AC may be a label that indicates a label or set of EDCA parameters for providing QoS in EDCA. The EDCA parameters or set of EDCA parameters may be those used for channel connection. AC may be used by QoS STA.

[0109] The value of AC may be set as one of AC_BK, AC_BE, AC_VI, or AC_VO. AC_BK, AC_BE, AC_VI, and AC_VO may represent background, best effort, video, and voice, respectively. Furthermore, AC_BK, AC_BE, AC_VI, and AC_VO can be subdivided. For example, AC_VI may be subdivided into AC_VI primary and AC_VI alternate. Similarly, AC_VO may be subdivided into AC_VO primary and AC_VO alternate. Additionally, UP values ​​or TID values ​​may be mapped to AC values. For example, UP values ​​or TID values ​​1, 2, 0, 3, 4, 5, 6, and 7 may be mapped to AC_BK, AC_BK, AC_BE, AC_BE, AC_VI, AC_VI, AC_VO, and AC_VO, respectively. Alternatively, UP values ​​or TID values ​​1, 2, 0, 3, 4, 5, 6, and 7 may be mapped to AC_BK, AC_BK, AC_BE, AC_BE, AC_VI alternate, AC_VI primary, AC_VO primary, and AC_VO alternate, respectively. Furthermore, UP values ​​or TID values ​​1, 2, 0, 3, 4, 5, 6, and 7 may have increasing priorities in that order. That is, 1 may have a lower priority and 7 may have a higher priority. Therefore, the priorities may increase in the order of AC_BK, AC_BE, AC_VI, and AC_VO. Also, AC_BK, AC_BE, AC_VI, and AC_VO may correspond to AC indices (ACI) 0, 1, 2, and 3, respectively.

[0110] Therefore, a relationship between TID and AC can exist. Thus, the TID-to-link mapping of the present invention may also be a mapping relationship between AC and the link. Furthermore, in the present invention, the mapping of TID may also mean that AC is mapped, and vice versa.

[0111] According to one embodiment of the present invention, there may be TIDs mapped to each link in a multilink. For example, there may be a mapping for which links among multiple links are permitted to transmit and receive a particular TID or particular AC. Furthermore, such mappings may be defined separately for each of the two directions of the link. Also, as mentioned above, there may be a default setting for the mapping between TIDs and links. For example, the mapping between TIDs and links may basically be such that all TIDs are mapped to a certain link. Also, according to one embodiment, at a particular time, a certain TID or a certain AC may be mapped to at least one link. Furthermore, a management frame or control frame may be transmitted on all links.

[0112] In this invention, data frames corresponding to TIDs or ACs mapped to a given direction of a link may be transmitted. Conversely, data frames corresponding to TIDs or ACs that are not mapped to a given direction of a link do not need to be transmitted.

[0113] According to one embodiment, TID-to-link mapping may also be applied to acknowledgments. For example, a block ack agreement may be based on TID-to-link mapping. Alternatively, TID-to-link mapping may be based on a block ack agreement. For example, a block ack agreement can exist for a TID that has been TID-to-link mapped.

[0114] TID-to-link mapping makes it possible to provide QoS services. For example, by mapping high-priority ACs and TIDs to links with good channel status or few STAs, it may be possible to transmit data for those ACs and TIDs faster. Alternatively, TID-to-link mapping can help enable STAs on a specific link to power save (or enter a doze state).

[0115] Referring to Figure 10, an AP MLD containing AP1 and AP2 may exist. A Non-AP MLD containing STA1 and STA2 may also exist. Furthermore, the AP MLD may have multiple links, namely Link1 and Link2. AP1 and STA1 may be associated via Link1, and AP2 and STA2 may be associated via Link2.

[0116] Therefore, Link1 may include a link from AP1 to STA1 and / or a link from STA1 to AP1, and Link2 may include a link from AP2 to STA2 and / or a link from STA2 to AP2. In this case, each link may be mapped to a TID and / or AC.

[0117] For example, all TIDs and all ACs may be mapped to the link from AP1 to STA1 on Link1, and to the link from STA1 to AP1 on Link1. On the other hand, only AC_VO or TIDs corresponding to AC_VO may be mapped to the link from STA2 to AP2 on Link2. Furthermore, only data for mapped TIDs and / or ACs can be transmitted on that link. Data for TIDs or ACs that are not mapped to a link cannot be transmitted on that link.

[0118] Figure 11 shows an example of the multi-link NAV setting operation according to one embodiment of the present invention.

[0119] The simultaneous transmit and receive (STR) operation of the MLD may be limited, and this may be related to the frequency spacing between multiple links operating in a multi-link configuration.

[0120] Therefore, according to the embodiment of the present invention, simultaneous transmission or reception may be restricted when the link spacing is m MHz, but simultaneous transmission or reception may not be restricted when the link spacing is n MHz for n greater than m. This embodiment may be intended to solve the problem of restrictions on simultaneous transmission or reception, and redundant explanations can be omitted. Furthermore, this embodiment can be applied to STR-non-MLDs.

[0121] According to one embodiment of the present invention, duration information may be shared between links operating in a multilink configuration. In one embodiment, the duration information may be TXOP duration information transmitted in the signaling field of the preamble. The signaling field may be the U-SIG field described above. Alternatively, the signaling field may be the HE-SIG-A field described above. In yet another embodiment, the duration information may be the duration information indicated by the Duration / ID field included in the MAC header. In yet another embodiment, the duration information may be the duration information indicated by the Length field (L Length field) included in the L-SIG field. According to one embodiment, the duration information indicated by the U-SIG field, HE-SIG-A, or Duration / ID field may be a value indicating the TXOP duration. According to one embodiment, the duration information indicated by the L-SIG field may be a value indicating the length of the PPDU (physical layer protocol data unit) containing the L-SIG field or the end of the PPDU containing the L-SIG field.

[0122] Furthermore, according to embodiments of the present invention, transmission or channel connection can be restricted to a period based on period information shared between links. The method for restricting transmission or channel connection may include setting a NAV. Alternatively, the NAV can be reset to resume transmission or channel connection. In this case, the NAV may be an intra-BSS NAV. An intra-BSS NAV may be a NAV set by an intra-BSS frame (or PPDU). That is, an STA belonging to an MLD can set a NAV based on a frame (or PPDU) directed to another STA belonging to the MLD.

[0123] According to one embodiment of the present invention, an inter-link NAV may exist. The inter-link NAV may be a NAV used by the STAs of multiple links belonging to a certain MLD when operating with multiple links. For example, transmission on link 2 is not required based on the inter-link NAV set based on the period information received on link 1. Furthermore, the inter-link NAV can exist or be used for MLDs that do not support STR. For example, if an inter-link NAV is set, the MLD that set the inter-link NAV does not need to transmit or establish a channel connection on multiple links (or all links used by the MLD).

[0124] Furthermore, in addition to intra-BSS NAV, there may also be a basic NAV. Basic NAV may be a NAV configured by an inter-BSS frame (or PPDU), and basic NAV may also be configured by a frame (or PPDU) where it is not possible to determine whether it is intra-BSS or inter-BSS.

[0125] When using Inter-link NAV separately, there may be advantages in situations where NAV settings are updated compared to not using Inter-link NAV. For example, there may be situations where it is acceptable to reset the NAV set by another link. For instance, if an Inter-link NAV is set based on a certain frame (or PPDU), but it is determined that the frame (or PPDU) is not directed to the same MLD, it may be acceptable to reset the set Inter-link NAV. For example, if there are MLDs operating on Link 1 and Link 2, the NAV for Link 1 may be set based on frames received on Link 1. Subsequently, the NAV for Link 1 can be updated based on frames from Link 2. Then, if the NAV for Link 1 is reset when it is no longer necessary to maintain the NAV by Link 2, the NAV information set based on frames received on Link 1 may be lost. However, if Inter-link NAV is used together with the NAV for each link, this problem can be solved because the NAV for each link can be maintained even if the Inter-link NAV is reset.

[0126] While the embodiments of the present invention focus on setting the NAV, the embodiments of the present invention are not limited to this and can also be applied to instructing the physical layer to interrupt the channel connection or to instruct the channel state to be busy. Furthermore, the embodiments are not limited to resetting the NAV and may also be applied to instructing the physical layer to continue the channel connection or to instruct the channel state to be idle. In this case, primitives exchanged between the physical layer and the MAC layer may be used. Alternatively, primitives exchanged between one STA and another STA of the MLD may be used. Alternatively, primitives exchanged between one MAC layer and another MAC layer of the MLD may be used.

[0127] According to an embodiment of the present invention, when an STA belonging to an MLD begins receiving a PPDU, other STAs belonging to the MLD may need to terminate their channel connection. As mentioned above, the channel connection can be terminated based on the received period information, but there may be a time lag between the start of PPDU reception and obtaining the period information, depending on the position of the field containing the period information or the time required for decoding, etc. Therefore, if the channel is accessed and transmission is started during this time, the aforementioned problem may occur. Accordingly, according to one embodiment of the present invention, an STA of an MLD can suspend its channel connection from the time other STAs of the MLD begin receiving. Furthermore, the channel connection can be resumed after it is confirmed that the frame received after other STAs of the MLD begin receiving is not intended for those other STAs.

[0128] Figure 12 shows yet another example of the multi-link NAV configuration operation according to one embodiment of the present invention.

[0129] Figure 12 provides a detailed explanation of the specific method of the embodiment described in Figure 11, and redundant explanations may be omitted.

[0130] As described above, based on a frame or PPDU received by an STA belonging to the same MLD, other STAs belonging to the same MLD can cancel or resume channel connection or transmission. In this invention, canceling channel connection or transmission may include actions such as setting (updating) the NAV, determining the channel is busy, or canceling CCA. Resumeing channel connection or transmission may include actions such as resetting the NAV, canceling the NAV setting, determining the channel is idle, or performing CCA. Hereafter, these actions can be instructed as canceling and resuming channel connection. Furthermore, hereafter, it can be explained that STA1 and STA2 belong to the MLD, and STA1 and STA2 operate on link 1 and link 2, respectively. Also, frames and PPDUs can be used interchangeably in instructions. In this case, the NAV may be an intra-BSS NAV or an inter-link NAV, as explained in Figure 11.

[0131] According to an embodiment of the present invention, when STA1 begins receiving frames, STA2 can interrupt the channel connection. Furthermore, when STA1 obtains duration information from the L-SIG, STA2 can maintain the interrupted channel connection state. In this case, STA2 can determine that the interrupted channel connection state will last until the end of the frame received by STA1. Also, if STA1 fails to correctly decode the L-SIG (i.e., if it is an invalid L-SIG), STA2 can resume the channel connection.

[0132] Furthermore, STA1 may receive the TXOP duration and BSS color from the U-SIG of the frame it receives. If the received BSS color indicates intra-BSS, or if the BSS color is the BSS color corresponding to STA1, the channel connection can be interrupted. In one embodiment, the period for which the channel connection is interrupted may be until the end of the received frame. In this case, there is an advantage in that the channel connection can be started sooner after the received frame has finished. In another embodiment, the period for which the channel connection is interrupted may be the TXOP duration. In this case, the duration of the interrupted channel connection based on the L-SIG can be updated. In this case, there is an advantage in that the sequence following the received frame can be better protected.

[0133] Alternatively, STA2 may have received the TXOP duration and BSS color from the U-SIG of the frame received by STA1, and the received BSS color may indicate that it is not an intra-BSS, or the BSS color may not be the BSS color corresponding to STA1. Or, STA1 may have failed to successfully decode the U-SIG. In such cases, STA2 can resume the channel connection.

[0134] Alternatively, STA2 can resume the channel connection if the information obtained from the U-SIG of a frame received by STA1 indicates that the frame is one that STA1 did not receive. For example, STA2 can resume the channel connection if the PHY identifier obtained from the U-SIG is an ID that corresponds to a future standard or an ID that is not recognized.

[0135] Furthermore, although the case of receiving a U-SIG has been described, the same embodiment can also be applied when receiving an HE PPDU or when receiving an HE-SIG-A. For example, HE-SIG-A may include TXOP duration and BSS color, thereby enabling the same operation as described above.

[0136] Additionally, STA1 may receive an STA-ID from the EHT-SIG of the frame it receives. If the received STA-ID is the indicator that STA1 should receive, for example, if the STA-ID indicates STA1, the group to which STA1 belongs, or broadcast, STA2 can maintain the state of interrupted channel connection.

[0137] Alternatively, STA1 may receive the STA-ID from the EHT-SIG of the frame it receives. If the received STA-ID is an indicator that does not correspond to STA1, for example, if the STA-ID does not indicate an indicator that corresponds to STA1, if the STA-ID does not indicate a group to which STA1 belonged, or if the STA-ID does not indicate broadcast, STA2 can resume the channel connection. Alternatively, STA2 can also resume the channel connection if STA1 is unable to successfully decode the EHT-SIG.

[0138] Furthermore, although the case of receiving EHT-SIG has been described, the same embodiment can also be applied when receiving HE-SIG-B when receiving HE PPDU. For example, HE-SIG-B may include STA-ID, thereby enabling the same operation as described above.

[0139] Furthermore, STA2 may receive the MAC header of the frame that STA1 receives. If the RA (receiver address) or DA (destination address) contained in the received MAC header indicates a value that STA1 should receive—for example, if the RA or DA indicates STA1, or the group to which STA1 belongs, or if the STA-ID indicates broadcast—STA2 can maintain the state of interrupted channel connection. In this case, the duration of the interrupted channel access can be determined based on the duration information contained in the received MAC header. More specifically, the duration of the interrupted channel access can be determined based on the duration information indicated by the Duration / ID field contained in the received MAC header.

[0140] Additionally, STA2 may have received the MAC header of the frame that STA1 receives. If the RA or DA contained in the received MAC header is an indicator that does not correspond to STA1, for example, if the RA or DA does not indicate an indicator that corresponds to STA1, does not indicate a group belonging to STA1, and does not indicate a broadcast, STA2 can resume the channel connection. Alternatively, STA1 may not have received all MAC headers. For example, STA1 may have failed to receive all MPDUs included in the A-MPDU. In this case, STA2 can resume the channel connection.

[0141] The channel connection interruption and resumption described in Figure 12 can be performed sequentially by receiving frames (or PPDUs) at STA1 and decoding them in the order they are decoded. The decoding order can be determined based on the PPDU format, frame format, etc. For example, it can be decoded in the order of L-SIG, U-SIG, EHT-SIG, MAC header (for EHT PPDU). Or, it can be decoded in the order of L-SIG, HE-SIG-A, MAC header (for HE SU PPDU and HE TB PPDU). Or, it can be decoded in the order of L-SIG, HE-SIG-A, HE-SIG-B, MAC header (for HE MU PPDU). Or, it can be decoded in the order of L-SIG, MAC header (for 11a / g PPDU).

[0142] According to embodiments of the present invention, the aforementioned STA-ID may be a value indicating the intended recipient of the PPDU or RU (resource unit). The STA-ID may also be included in the EHT-SIG field or HE-SIG-B field, etc. Furthermore, the STA-ID can represent a value corresponding to a single STA. For example, when multiple STAs are included in the MLD, the STA-ID can represent a value corresponding to one of the multiple STAs. The STA-ID may also be a value based on the AID or MAC address of the STA.

[0143] Figure 13 shows an example of a BSS classification and operation based thereon according to one embodiment of the present invention.

[0144] According to one embodiment of the present invention, an STA can classify (determine) a BSS based on a received frame or received PPDU. Classifying a BSS may include the operation of determining whether the received frame or received PPDU belongs to the BSS to which the classifying STA belongs. Alternatively, classifying a BSS may mean determining whether the received frame or received PPDU was transmitted from the BSS to which the classifying STA belongs. Furthermore, classifying a BSS may include the operation of determining whether the received frame or received PPDU belongs to a BSS to which the classifying STA does not belong. Alternatively, classifying a BSS may mean determining whether the received frame or received PPDU was transmitted from the BSS to which the classifying STA does not belong. Furthermore, classifying a BSS may include the operation of determining which BSS the received frame or received PPDU belongs. Alternatively, classifying a BSS may mean determining which BSS the received frame or received PPDU was transmitted from. According to one embodiment of the present invention, a BSS to which a classified STA belongs can be called an intra-BSS. Alternatively, a BSS that includes a BSS to which a classified STA belongs can be called an intra-BSS. Furthermore, a BSS that is not an intra-BSS can be called an inter-BSS. Alternatively, a BSS that is not an intra-BSS may be an inter-BSS or an unclassified BSS. Alternatively, an inter-BSS may include an unclassified BSS. Furthermore, a BSS to which no classified STA belongs can be called an inter-BSS.

[0145] According to one embodiment, if a received frame or PPDU is determined to be an intra-BSS or to have been transmitted from an intra-BSS, the received frame or PPDU can be referred to as an intra-BSS frame and an intra-BSS PPDU, respectively. Furthermore, if a received frame or PPDU is determined to be an inter-BSS or to have been transmitted from an inter-BSS, the received frame or PPDU can be referred to as an inter-BSS frame and an inter-BSS PPDU, respectively. Additionally, a PPDU containing an intra-BSS frame may be an intra-BSS PPDU. Similarly, a PPDU containing an inter-BSS frame may be an inter-BSS PPDU.

[0146] According to one embodiment of the present invention, BSS can be classified based on one or more BSS classification conditions. For example, BSS can be classified based on whether or not at least one of the one or more BSS classification conditions is met.

[0147] The BSS classification conditions may include conditions based on the BSS color. The BSS color may be an identifier for the BSS. The BSS color can also be included in the PPDU preamble, more specifically, in the signaling field (e.g., the HE-SIG-A field, U-SIG field, or VHT-SIG-A field). The BSS color may also be included in the TXVECTOR transmitted from the sender's MAC layer to the PHY layer. The BSS color may also be included in the RXVECTOR transmitted from the receiver's PHY layer to the MAC layer. The parameters included in the TXVECTOR and RXVECTOR can be called the TXVECTOR parameter and RXVECTOR parameter, respectively. The BSS color can also be included in the TXVECTOR parameter or RXVECTOR parameter. Furthermore, the AP can inform the STA of the BSS color it has set. According to one embodiment, the BSS can be classified based on the BSS color included in the received PPDU. If the BSS color included in the PPDU received by the STA is different from the BSS color of the BSS corresponding to the STA, the received PPDU can be classified as an inter-BSS PPDU. Alternatively, if the BSS color included in the PPDU received by the STA is different from the BSS color of the BSS corresponding to the STA, and its value is not 0, the received PPDU can be classified as an inter-BSS PPDU. Furthermore, if the BSS color included in the PPDU received by the STA is the same as the BSS color of the BSS corresponding to the STA, the received PPDU can be classified as an intra-BSS PPDU.

[0148] The BSS classification conditions may include conditions based on the MAC address. The MAC address may be included in the MAC header of the frame. The MAC address may also include RA (receiver address), TA (transmitter address), BSSID, SA (source address), DA (destination address), etc. According to one embodiment, BSS can be classified based on the MAC address included in the received frame. If the MAC address included in the received frame is different from the BSSID of a BSS corresponding to STA, the received frame can be classified as an inter-BSS frame. More specifically, if all of the MAC addresses included in the received frame are different from the BSSIDs of BSS corresponding to STA, the received frame can be classified as an inter-BSS frame. Also, if the MAC address included in the received frame is the same as the BSSID of a BSS corresponding to STA, the received frame can be classified as an intra-BSS frame. More specifically, if at least one of the MAC addresses included in the received frame is the same as the BSSID of a BSS corresponding to STA, the received frame can be classified as an intra-BSS frame.

[0149] The aforementioned BSS may include a BSS to which an STA is associated. Furthermore, the aforementioned BSS may include a BSS included in the same multiplexed BSSID set as the BSS to which an STA is associated. Furthermore, the aforementioned BSS may include a BSS included in the same co-hosted BSSID set as the BSS to which an STA is associated. Additionally, information regarding one or more BSSs included in the same multiplexed BSSID set or the same co-hosted BSSID set may be transmitted within a single frame.

[0150] The aforementioned BSS classification conditions may include conditions based on the Partial AID field value included in the VHT PPDU. The Partial AID field may be included in the preamble of the VHT PPDU. Alternatively, the Partial AID field may be included in the VHT-SIG-A field included in the VHT PPDU. According to one embodiment, the Partial AID field can represent a part of the BSS color. For example, when using the partial BSS color function, the Partial AID field can represent a part of the BSS color. Or, when using an AID assignment rule, the Partial AID field can represent a part of the BSS color. The AID assignment rule may be a method of assigning AIDs based on the BSS color. Furthermore, if the Group ID field included in the VHT-SIG-A field of the VHT PPDU is already set to a value (for example, if the Group ID field is set to 63), the Partial AID field can represent a part of the BSS color. According to one embodiment, if the Partial AID field of a received PPDU represents a part of the BSS color, and the received Partial AID field value differs from the part of the BSS color corresponding to the received STA, the received PPDU can be classified as an inter-BSS PPDU.

[0151] Furthermore, if the Partial AID field of a received PPDU indicates a part of the BSS color, and the received Partial AID field value is the same as the part of the BSS color corresponding to the received STA, the received PPDU can be classified as an intra-BSS PPDU. In this case, the part of the BSS color can be the 4LSB of the BSS color. In another embodiment, the Partial AID field can indicate a part of the BSSID. For example, if the Group ID field included in the VHT-SIG-A field of a VHT PPDU is already set to a value (for example, if the Group ID field is set to 0), the Partial AID field can indicate a part of the BSSID. In one embodiment, if the Partial AID field of a received PPDU indicates a part of the BSSID, and the received Partial AID field value is different from the part of the BSSID corresponding to the received STA, the received PPDU can be classified as an inter-BSS PPDU. Furthermore, if the Partial AID field of the received PPDU indicates a part of the BSSID, and the received Partial AID field value is identical to the part of the BSSID corresponding to the received STA, the received PPDU can be classified as an intra-BSS PPDU. In this case, the part of the BSSID can be the 9MSB of the BSSID. The Partial AID field value can be included in TXVECTOR parameter PARTIAL_AID or RXVECTOR parameter PARTIAL_AID. The Group ID field value can be included in TXVECTOR parameter GROUP_ID or RXVECTOR parameter GROUP_ID.

[0152] The BSS classification conditions may include conditions under which the AP receives a PPDU that meets already set conditions. For example, the PPDU that meets the already set conditions may include a downlink PPDU. According to one embodiment, the downlink PPDU may include a VHT MU PPDU. The downlink PPDU may also include a PPDU with signaling indicating whether it is an uplink or downlink set to a value that has already been set. The signaling indicating whether it is an uplink or downlink can be included in the signaling field of the HE PPDU. Alternatively, the signaling indicating whether it is an uplink or downlink can be included in the U-SIG. The U-SIG can be included in the preamble of an EHT PPDU or a PPDU that follows the EHT standard.

[0153] Furthermore, there may be cases where a PPDU cannot be classified as either intra-BSS PPDU or inter-BSS PPDU. For example, if a PPDU does not meet either of the aforementioned criteria for classification as intra-BSS PPDU or inter-BSS PPDU, it may not be possible to classify it as either an intra-BSS PPDU or an inter-BSS PPDU.

[0154] Furthermore, when classifying BSS, if the classification results based on multiple conditions do not match, it is possible to determine the final result based on the previously set conditions. For example, if the result based on the BSS color condition does not match the result based on the MAC address condition, the result based on the MAC address condition can take precedence, or the result based on the MAC address condition can be determined as the final result. Alternatively, if both the conditions for classifying as intra-BSS PPDU and the conditions for classifying as inter-BSS PPDU are met, it can be classified as intra-BSS PPDU.

[0155] According to one embodiment of the present invention, the STA can perform operations based on the classified BSS. Operations based on the classified BSS may include intra-PPDU power saving operations. The intra-PPDU power saving operation may be a power saving operation based on the received PPDU. The intra-PPDU power saving operation can be performed if the already set conditions are met. The already set conditions may include conditions for classifying the received PPDU as an intra-BSS PPDU. The already set conditions may also include conditions for the intended receiver of the received PPDU not to be the STA that received the PPDU. For example, if the ID or address included in the PPDU does not correspond to the STA that received the PPDU, the intended receiver of the PPDU does not have to be the STA that received the PPDU. The ID may be included in the PPDU's preamble. For example, the ID may be the STA_ID included in the PPDU's preamble. The STA_ID may also be included in the HE MU PPDU or EHT PPDU. The address may be the MAC address mentioned above. Furthermore, if the signaling in the received PPDU indicating whether it is an uplink or downlink indicates an uplink, the intended recipient of the PPDU does not have to be the STA that received the PPDU. Also, if the settings of the received PPDU are set so that the STA that received the PPDU does not support it, the intended recipient of the PPDU does not have to be the STA that received the PPDU. The settings of the received PPDU may include the PPDU's MCS, number of spatial streams, channel width, etc. Also, if the settings of the received PPDU are set so that the STA that received the PPDU does not support it, the PHY-RXEND.indication(UnsupportedRate) primitive may be received. Also, if the received PPDU is in an already set format, the intended recipient of the PPDU does not have to be the STA that received the PPDU. The already set format may include TB PPDU.A TB PPDU may include an HE TB PPDU and an EHT TB PPDU. A TB PPDU may also be a PPDU transmitted as a response to a triggering frame. The triggering frame may include a trigger frame. The triggering frame may include a frame containing triggering information. The triggering information can be contained in the MAC header, for example, the A-control field. The triggering information or information contained in the trigger frame may include the length of the responding PPDU, the RU used when responding, the PHY configuration used when responding, the MAC configuration, etc. The intra-PPDU power-saving operation may be an operation that allows the system to enter a doze state until the end of the received PPDU. In another embodiment, if the STA determines that the intended recipient of the received PPDU or frame is not the STA, the reception or decoding of the PPDU or frame may be interrupted.

[0156] The operation based on the classified BSS may include the operation of setting (or updating) the NAV. According to one embodiment, the STA can operate one or more NAVs. Furthermore, when the STA receives a PPDU or frame, it is possible to set up a NAV that corresponds to the BSS classified based on the received PPDU or frame. For example, an intra-BSS NAV may be a NAV that corresponds to an intra-BSS PPDU. Also, a basic NAV may be a NAV that corresponds to a PPDU that is not an intra-BSS PPDU. Or, a basic NAV may be a NAV that corresponds to an inter-BSS PPDU. Furthermore, when setting up a NAV based on a received PPDU or frame, it is possible to use the duration information contained in the received PPDU or frame. The duration information may include a TXOP. A TXOP can mean the value contained in the TXOP field. The TXOP field can be included in the preamble of the PPDU. For example, the TXOP field can be included in the HE-SIG-A field of an HE PPDU. Alternatively, the TXOP field may be included in the U-SIG field of an EHT PPDU or a post-EHT standard PPDU. Furthermore, the duration information may be included in the MAC header. For example, the duration information may be included in the Duration / ID field in the MAC header.

[0157] The classified BSS-based operation may include a spatial reuse operation. The classified BSS-based operation may also include a channel connection operation. The spatial reuse operation may be a channel connection operation. When the STA receives a PPDU or frame, it is possible to perform a spatial reuse operation if the already set conditions are met. The already set conditions may include the condition that the received PPDU or received frame is an inter-BSS. The already set conditions may also include the condition that the signal strength of the received PPDU or received frame is less than a threshold. For example, the threshold may be variable. The threshold may also be a threshold for OBSS PD-based spatial reuse operation. The threshold may also be a value greater than or equal to the CCA threshold. The threshold may also be a value based on the power to be transmitted. The spatial reuse operation may include the operation of transmitting the PPDU. The spatial reuse operation may also include the operation of resetting the PHY. For example, the operation of resetting the PHY may be the operation of issuing the PHY-CCARESET.request primitive. Furthermore, the space reuse operation may include an operation that does not set the NAV based on the received PPDU or received frame. If the STA performs the space reuse operation, the STA may transmit a PPDU while the received PPDU or received frame is being transmitted or received.

[0158] Referring to Figure 13, BSS A and BSS B may exist, and BSS A and BSS B may be different BSSs from each other. Also, BSS A and BSS B may correspond to each other as inter-BSS. That is, a PPDU or frame transmitted by an STA coupled to BSS A on BSS B may be classified as an inter-BSS PPDU or an inter-BSS frame. Also, there may be STA1 and STA2 belonging to BSS A (or coupled to an AP operating BSS A). There may be STA3 and STA4 belonging to BSS B (or coupled to an AP operating BSS B). Referring to Figure 13, STA1 can transmit a PPDU. Also, the PPDU transmitted by STA1 may contain information about the BSS. For example, the information about the BSS may be the information used to classify the BSS as described above. Also, the PPDU transmitted by STA1 may contain duration information.

[0159] STA2 can receive the PPDU transmitted by STA1 and classify the BSS for this PPDU. Since both STA2 and STA1 belong to BSS A, the PPDU received by STA2 may be classified as an intra-BSS PPDU. Furthermore, the PPDU received by STA2 may be a UL PPDU or a PPDU that is not intended for STA. Therefore, according to the embodiment described above, STA2 can perform intra-PPDU power saving. Referring to Figure 13, STA2 may remain in the doze state until the end time of the received PPDU. Also, STA2 can set the NAV based on the Duration information contained in the received PPDU. Since STA2 classified the received PPDU as an intra-BSS PPDU, it is possible to set the intra-BSS NAV.

[0160] STA3 can receive the PPDU transmitted by STA1 and classify the BSS for this PPDU. Since STA3 and STA1 belong to BSS B and BSS A respectively, the PPDU received by STA3 can be classified as an inter-BSS PPDU. Furthermore, STA3 can set the NAV based on the Duration information contained in the received PPDU. Since STA3 has classified the received PPDU as an inter-BSS PPDU, it is possible to set the basic NAV.

[0161] STA4 can receive the PPDU transmitted by STA1 and classify the BSS for this PPDU. Since STA4 and STA1 belong to BSS B and BSS A, respectively, the PPDU received by STA4 may be classified as an inter-BSS PPDU. Furthermore, the signal strength of the PPDU received by STA4 may be less than the threshold. Therefore, since the PPDU received by STA4 is classified as an inter-BSS PPDU and the signal strength of the PPDU received by STA4 is less than the threshold, STA4 can perform space reuse operation. Consequently, STA4 can connect the channel, perform the backoff procedure, and start transmitting. For example, STA4 may start transmitting before the PPDU transmitted by STA1 has finished.

[0162] Figure 14 shows the function of STA according to an embodiment of the present invention.

[0163] According to embodiments of the present invention, an STA conforming to a certain wireless LAN standard may include functions of a previous wireless LAN standard. This is for backward compatibility. For example, an STA supporting a particular wireless LAN standard can support functions of previous generations of wireless LAN standards and can also support new functions. For example, an HT STA can support the basic functions of an OFDM PHY STA. Therefore, an HT STA may be classified as an OFDM PHY STA. Furthermore, an HT STA can support not only the functions of an OFDM PHY STA but also additional functions that an OFDM PHY STA does not support. A VHT STA can support the basic functions of an HT STA while also supporting functions that an HT STA does not support. A VHT STA may be classified as an HT STA. Furthermore, an HE STA can support the basic functions of a VHT STA while also supporting functions that a VHT STA does not support. A HE STA may be classified as a VHT STA. Also, an EHT STA can be an HE STA. Furthermore, an EHT STA can support the basic functions of a HE STA while also supporting functions that a HE STA does not support. Furthermore, EHT STA may be classified as HE STA. Also, a new wireless LAN standard may be defined after the EHT standard. In this invention, a standard after the EHT standard is called a NEXT standard, and an STA that conforms to the NEXT standard is called a NEXT STA. A NEXT STA can support the basic functions of an EHT STA, as well as functions that an EHT STA does not support. A NEXT STA may be classified as an EHT STA.

[0164] Figure 14 is a diagram showing the relationships between STAs that support each wireless LAN standard. Referring to Figure 11, if it is an EHT STA, it may also be an HE STA, a VHT STA, an HT STA, or an OFDM PHY STA. Similarly, if it is a NEXT STA, it may also be an EHT STA, a HE STA, a VHT STA, an HT STA, or an OFDM PHY STA.

[0165] Figure 16 shows the UL MU operation according to an embodiment of the present invention.

[0166] In one embodiment of the present invention, an access point can transmit a frame that solicits multi-user (MU) transmission. Such a frame is called a triggering frame. At this time, one or more STAs that receive the triggering frame can perform an uplink transmission based on the triggering frame. Specifically, one or more STAs that receive the triggering frame can transmit a response frame to the frame. At this time, the inter-space between the PPDU containing the triggering frame and the PPDU used for uplink transmission may be SIFS. Specifically, multiple STAs can receive a triggering frame and simultaneously transmit an immediate response. In this specification, an immediate response indicates that the inter-space between the previously received PPDU and the PPDU containing the response is SIFS. Specifically, this may mean transmitting the response SIFS after the end of the received PPDU.

[0167] A triggering frame is a type of control frame and may be a trigger frame containing trigger information. Alternatively, a triggering frame may be a frame that includes trigger information in its MAC header. In this case, the trigger information may be a TRS (triggered response scheduling) contained in the HT Control field, Control subfield, or A-Control subfield of the MAC header. Furthermore, the trigger information may be information that triggers the transmission of a TB PPDU.

[0168] TB PPDU is a PPDU format that includes a response frame to a triggering frame. TB PPDU may include HE TB PPDU and EHT TB PPDU. Furthermore, TB PPDU may include NEXT TB PPDU as defined in the NEXT wireless LAN standard. HE TB PPDU includes a preamble containing L-STF, L-LTF, L-SIG, RL-SIG, HE-SIG-A, HE-STF, and HE-LTF in that order, followed by data and a packet extension (PE). EHT TB PPDU and NEXT TB PPDU also include a preamble containing L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, (EHT- / NEXT-)STF, and (EHT- / NEXT-)LTF in that order, followed by data and a packet extension (PE).

[0169] The triggering frame may contain information necessary for TB PPDU transmission. A MAC frame can be indicated as a triggering frame if the value of the MAC frame's Type subfield (B3 B2) is 01b and the value of the Subtype subfield (B7 B6 B5 B4) is 0010b.

[0170] When multiple STAs responding to a trigger frame send TB PPDUs in different formats, the access point may have difficulty receiving the TB PPDU. Similarly, if the preambles of the PPDUs sent by multiple STAs are different, the access point may have difficulty receiving the TB PPDU. In particular, if RUs sending TB PPDUs in different formats overlap, the access point may have difficulty receiving the TB PPDU. Therefore, multiple STAs sending responses to a single triggering frame can use TB PPDUs in the same format. Furthermore, the preamble information of the TB PPDUs sent by multiple STAs responding to a single triggering frame may be identical.

[0171] As explained in Figure 14, HE STA can transmit HE TB PPDU. EHT STA can transmit EHT TB PPDU or HE TB PPDU. NEXT STA can transmit NEXT TB PPDU, EHT TB PPDU, or HE TB PPDU.

[0172] In the embodiment shown in Figure 15, the AP sends a trigger frame that schedules the transmission of an HE STA (HE STA) and an EHT STA (EHT STA). If the trigger frame does not specify the format of the TB PPDU to be sent in response to the trigger frame, the HE STA (HE STA) and EHT STA (EHT STA), or different EHT STAs (EHT STA), may send TB PPDUs in different formats. This can result in a failure to send the TB PPDU and a wasted transmission opportunity. For convenience of explanation, the trigger frames defined in the HE, EHT, and NEXT standards are referred to as HE trigger frames, EHT trigger frames, and NEXT trigger frames, respectively. Similarly, the TRS defined in the HE, EHT, and NEXT standards are referred to as HE TRS, EHTTRS, and NEXT TRS. The format of the trigger frames is explained in Figure 13.

[0173] Figure 16 shows the format of a trigger frame and the subfields included in the trigger frame according to an embodiment of the present invention.

[0174] Specifically, Figure 16(a) shows the format of a trigger frame, Figure 16(b) shows the Common Info field of a trigger frame, and Figure 16(c) shows the User Info field of a trigger frame. The MAC header of a trigger frame includes a Frame Control field, a Duration field, and an Address field. In this case, the Address field includes an RA field and a TA field. The trigger frame also includes a Common Info field and a User Info List field. The Common Info field contains information for all STAs that the trigger frame triggers. The User Info List field may also include a User Info field. In specific embodiments, certain types of trigger frames do not need to include a User Info List field. The trigger frame may also include a Padding field and an FCS field. The Padding field can serve to extend the frame length to allow time for the receiving STA to prepare a response and may be optionally present.

[0175] The Common Info field may include a Trigger Type subfield. The Trigger Type subfield identifies the trigger frame variant. The type of trigger frame can be indicated by the value of the Trigger Type subfield. The Trigger Type subfield may also determine the information contained in the Trigger Dependent Common Info subfield and the length of the Trigger Dependent Common Info subfield and the Trigger Dependent User Info subfield. For example, the Trigger Type subfield may be indicated by bits B0 to B3 of the Common Info field.

[0176] Furthermore, the Common Info field may include a UL Length subfield. The UL Length subfield may contain information about the length of the TB PPDU responding to the Trigger frame. Alternatively, the UL Length subfield may contain information about the length of the frame responding to the Trigger frame. The UL Length subfield can also indicate a value contained in the Length subfield of the L-SIG of the TB PPDU responding to the Trigger frame. Therefore, an STA responding with a TB PPDU can set the Length subfield of the L-SIG of the TB PPDU based on the value of the UL Length subfield contained in the received Trigger frame. More specifically, an STA responding with a TB PPDU can set the Length subfield of the L-SIG of the TB PPDU with the value of the UL Length subfield contained in the received Trigger frame. For example, the UL Length subfield may be indicated by bits B4 through B15 of the Common Info field.

[0177] The Common Info field may also include a UL BW subfield. The UL BW subfield can indicate the bandwidth (BW) value included in the signaling field of the TB PPDU in response to the trigger frame, for example, the HE-SIG-A field or the U-SIG field. The UL BW subfield can also indicate the maximum bandwidth of the TB PPDU in response to the trigger frame.

[0178] The Common Info field may also include information contained in the signaling fields of the TB PPDU in response to the trigger frame, such as the HE-SIG-A field or the U-SIG field.

[0179] The User Info field may contain an AID12 subfield. The AID12 subfield can indicate the intended recipient or function of the User Info field containing the AID12 subfield. Therefore, the AID12 subfield can indicate the intended recipient or function of the trigger frame containing the AID12 subfield. For example, if the value of the AID12 subfield is already set, the User Info field can indicate that it indicates a random access resource unit (RA-RU). More specifically, if the value of the AID12 subfield is 0, the User Info field can indicate an RA-RU for an associated STA. Also, if the value of the AID12 subfield is 2045, the User Info field can indicate an RA-RU for an unassociated STA. Furthermore, the value of the AID12 subfield can indicate that a User Info field containing the AID12 subfield, or a trigger frame containing the AID12 subfield, will trigger a response. For example, the AID12 subfield can indicate the AID or the 12th LSB of the AID. The STA corresponding to the value of the AID12 subfield can respond to the trigger frame with a TB PPDU. The value of the AID12 subfield may be in the range of 1 to 2007 (including 1 and 2007). Also, if the AID12 subfield is already set to a value, for example 2046, it can indicate that the corresponding RU is not assigned to any STA. Also, if the AID12 subfield is already set to a value, for example 4095, it can indicate that padding of the trigger frame will begin.

[0180] Furthermore, the information in the User Info field, including the AID12 subfield, may be information corresponding to the STA indicated by the AID12 subfield. For example, the RU Allocation subfield can indicate the size and location of the RU. In this case, the value of the RU Allocation subfield in the User Info field, including the AID12 subfield, may be information corresponding to the STA indicated by the AID12 subfield. Additionally, the User Info field can indicate the coding method (UL FEC Coding Type), modulation method (UL HE-MCS, UL DCM), and transmit power (UL Target RSSI) used in the response of the trigger frame containing the User Info field.

[0181] As mentioned earlier, problems can arise depending on the format of the TB PPDU that is sent simultaneously as a response to the trigger frame. Figure 14 illustrates the triggering frame transmission method related to this.

[0182] Figure 17 shows the information indicated by the value of the AID12 subfield of the trigger frame according to an embodiment of the present invention.

[0183] An EHT STA according to an embodiment of the present invention can selectively transmit HE TB PPDU and EHT TB PPDU. Similarly, a NEXT STA can selectively transmit HE TB PPDU, EHT TB PPDU, and NEXT TB PPDU. This allows multiple wireless LAN standard STAs to be scheduled in a single frame or PPDU. This improves the efficiency of the transmission medium. For example, an HE STA and an EHT STA that do not support the EHT standard can be configured to respond with an HE TB PPDU in a single frame.

[0184] Furthermore, information for selecting the TB PPDU format may be included in the trigger frame or TRS or a PPDU containing a trigger frame or a PPDU containing a TRS.

[0185] According to embodiments of the present invention, information regarding the TB PPDU format to be responded to may be present at the MAC level. According to embodiments of the present invention, trigger frames can be divided into HE trigger frames, EHT trigger frames, and NEXT trigger frames. Furthermore, responses triggered by HE trigger frames, EHT trigger frames, and NEXT trigger frames can be responded to in HE TB PPDU, EHT TB PPDU, and NEXT TB PPDU formats, respectively.

[0186] Furthermore, distinguishing between HE trigger frames, EHT trigger frames, and NEXT trigger frames is equivalent to distinguishing between HE TB PPDU, EHT TB PPDU, and NEXT TB PPDU formats, respectively, that respond to trigger frames. In other words, the format of the TB PPDU may change depending on the format of the trigger frame, and a next-generation trigger frame can also instruct the transmission of a previous-generation TB PPDU. That is, an EHT trigger frame can simultaneously instruct the transmission of both HE TB PPDU and EHT TB PPDU. However, an HE trigger frame cannot instruct the transmission of an EHT TB PPDU.

[0187] In a specific embodiment, the Frame Control field of the MAC header containing the trigger frame may determine whether the trigger frame is an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame. For example, at least one of the Type subfield, Subtype subfield, or Control Frame Extension subfield of the Frame Control field of the MAC header containing the trigger frame may determine whether the trigger frame is an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame. For example, if the Type subfield, Subtype subfield, or Control Frame Extension subfield of the Frame Control field of the MAC header containing the trigger frame has a first value, the trigger frame may be classified as an HE trigger frame. If the Type subfield, Subtype subfield, or Control Frame Extension subfield of the Frame Control field of the MAC header containing the trigger frame has a second value, the trigger frame may be classified as an EHT trigger frame. If the Type subfield, Subtype subfield, or Control Frame Extension subfield of the Frame Control field of the MAC header containing the trigger frame has a third value, the trigger frame may be classified as a NEXT trigger frame. A trigger frame may be classified as an HE trigger frame if the value of the Type subfield in the Frame Control field of the MAC header is 01b and the value of the Subtype subfield is 0010b. The Type subfield, Subtype subfield, and Control Frame Extension subfield are limited to 2 bits, 4 bits, and 4 bits, respectively. Therefore, such an embodiment has the disadvantage of limiting the types that can be used in the future by using limited bit field values.

[0188] In other specific embodiments, the Common Info field contained in the trigger frame may determine whether the trigger frame is an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame. For example, if the value of the Trigger Type subfield in the Common Info field of the trigger frame is the first value, the trigger frame may be classified as an HE trigger frame. If the value of the Trigger Type subfield in the Common Info field of the trigger frame is the second value, the trigger frame may be classified as an EHT trigger frame. If the value of the Trigger Type subfield in the Common Info field of the trigger frame is the third value, the trigger frame may be classified as a NEXT trigger frame. Specifically, if the value of the Trigger Type subfield in the Common Info field of the trigger frame is between 0 and 7, the trigger frame may be classified as an HE trigger frame. Also, if the value of the Trigger Type subfield in the Common Info field of the trigger frame is not between 0 and 7, the trigger frame may be classified as an EHT trigger frame or a NEXT trigger frame. Because the number of bits in the Trigger Type subfield is limited, such implementations have the disadvantage of restricting the trigger types that can be used in the future using a limited number of bit field values.

[0189] In other specific embodiments, the UL Length field included in the trigger frame may determine whether the trigger frame is an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame. For example, if the remainder when the value of the UL Length field of the trigger frame is divided by 3 is the first value, the trigger frame may be classified as an HE trigger frame. If the remainder when the value of the UL Length field of the trigger frame is divided by 3 is the second value, the trigger frame may be classified as an EHT trigger frame. If the remainder when the value of the UL Length field of the trigger frame is divided by 3 is the third value, the trigger frame may be classified as a NEXT trigger frame. If the remainder when the value of the UL Length field of the trigger frame is divided by 3 is not 0, the trigger frame may be classified as an HE trigger frame. If the remainder when the value of the UL Length field of the trigger frame is divided by 3 is 1, the trigger frame may be classified as an HE trigger frame. If the remainder when the value of the UL Length field of the trigger frame is divided by 3 is 0, the trigger frame may be classified as an EHT trigger frame or a NEXT trigger frame. In addition to the value of the UL Length field of the trigger frame, at least one of the following trigger frames—HE trigger frame, EHT trigger frame, or NEXT trigger frame—may also be used to determine whether a trigger frame is an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame.

[0190] In further specific embodiments, the User Info field contained in the trigger frame may determine whether the trigger frame is an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame. Specifically, the value of the AID12 subfield in the User Info field of the trigger frame may determine whether the trigger frame is an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame. For example, whether the trigger frame is an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame may be determined by whether the value of the AID12 subfield in the User Info field of the trigger frame is a pre-specified value. In this case, the User Info field containing the AID12 subfield indicating the type of trigger frame may be the first User Info field in the User Info field list. The User Info field containing the AID12 subfield indicating the type of trigger frame may be located before the User Info field containing the AID12 subfield indicating the STA's AID. This allows the STA receiving the trigger frame to determine the type of trigger frame early. In further specific embodiments, a User Info field containing an AID12 subfield indicating the trigger frame type may be located after the User Info field for the HE STA in the User Info field list. This prevents problems arising from legacy STAs, i.e., HE STAs, being unable to determine the meaning of the AID12 subfield value. Additionally, a User Info field containing an AID12 subfield indicating the trigger frame type does not need to contain any other subfields. This is because, since the User Info field is intended to indicate the trigger frame type, information other than the trigger frame type may be unnecessary.In such embodiments, the length of the User Info field varies depending on the value of the AID12 subfield. Figure 17 illustrates the meaning of the AID12 subfield value when such embodiments are applied. When the value of the AID12 subfield is the first value, the AID12 subfield can indicate that the trigger frame containing the AID12 field triggers the transmission of an EHT TB PPDU. The first value may be 2047. When the value of the AID12 subfield is the second value, the AID12 subfield can indicate that the trigger frame containing the AID12 field triggers the transmission of a NEXT TB PPDU. The second value may be 2048.

[0191] In further specific embodiments, the STA can determine the format of the TB PPDU to send as a response to the trigger frame based on the location of the User Info field that triggers the STA. Specifically, the STA can determine the format of the TB PPDU to send as a response to the trigger frame based on whether the User Info field that triggers the STA is located after a User Info field containing an AID12 field having a predetermined value. In this case, the STA can determine the format of the TB PPDU to send as a response to the trigger frame based on whether the User Info field that triggers the STA is located after a User Info field containing an AID12 field having a first value, or after a User Info field containing an AID12 field having a second value. In the embodiment of Figure 17, when the User Info field that triggers the STA is located after a User Info field containing an AID12 field having 2047, the STA can send an EHT TB PPDU as a response to the trigger frame. Furthermore, when the User Info field that triggers STA is located after a User Info field containing an AID12 field with 2048, STA can send a NEXT TB PPDU in response to the trigger frame. Also, when the User Info field that triggers STA is located after a User Info field containing an AID12 field with 2047 and a User Info field containing an AID12 field with 2048, STA can send a NEXT TB PPDU in response to the trigger frame. Also, when the User Info field that triggers STA is located before a User Info field containing an AID12 field with 2047 and a User Info field containing an AID12 field with 2048, STA can send a HE TB PPDU in response to the trigger frame.

[0192] The subfields of the User Info field other than the AID12 subfield may determine whether the trigger frame is an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame.

[0193] The Padding field of a trigger frame may determine whether it is an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame. For example, the Padding field of a trigger frame may contain a pre-specified value to determine whether it is an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame.

[0194] Furthermore, the embodiments described above may be applied in combination. For example, the elements that influence whether the trigger frame described above is an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame can be combined to make the determination.

[0195] Furthermore, the aforementioned embodiment may be used to determine the format of the TB PPDU sent as a response to the TRS field.

[0196] Figure 18 shows the UL MU operation according to an embodiment of the present invention.

[0197] As mentioned above, the trigger frame may include a TRS in the MAC frame header. The TRS may be included in the HT Control field, as mentioned above. Specifically, the HT Control field may include a TRS when it includes an A-Control field. Also, the TRS may be included in the TRS Control field. The Control List field may be located consecutively with the A-Control field. In this case, the Control List field may include a TRS.

[0198] An STA that is the intended recipient of a MAC frame containing a TRS may transmit a PPDU based on the field containing the TRS. In this case, the TRS may include information (UL Data Symbols) about the length of the PPDU or frame that the STA transmits as a response to the MAC frame containing the TRS. It may also include information about the power of the response transmission to the MAC frame containing the TRS (AP Tx Power, UL Target RSSI), the location and size of the RUs used when transmitting a response to the MAC frame containing the TRS (RU Allocation), and information about the modulation method of the response transmission to the MAC frame containing the TRS (UL HE-MCS).

[0199] A TRS may be defined according to the wireless LAN standard. In this case, an STA that receives a MAC frame containing a TRS can determine the format of the TB PPDU to be sent as a response to the TRS based on the format of the TRS, i.e., which wireless LAN standard defines the TRS. Specifically, if the STA receives an HE TRS, the STA can send an HE TB PPDU as a response to the TRS. Similarly, if the STA receives an EHT TRS, the STA can send an EHT TB PPDU as a response to the TRS. Furthermore, if the STA receives a NEXT TRS, the STA can send a NEXT TB PPDU as a response to the TRS. In this case, the STA can determine which wireless LAN standard defines the TRS based on the Control ID subfield of the A-Control subfield. TRS can be classified into HE TRS and non-TRS TRS.

[0200] The format of a TRS may be determined by whether the HT Control field containing the TRS is an HE variant, an EHT variant, or a NEXT variant. If the HT Control field containing the TRS is an EHT variant, the TRS may be an EHT TRS. Also, if the HT Control field containing the TRS is a NEXT variant, the TRS may be a NEXT TRS. Furthermore, the format of a TRS may be determined by the value of a pre-specified bit in the HT Control field containing the TRS, indicating whether the HT Control field is an HE variant, an EHT variant, or a NEXT variant. For example, if the first and second bits (B0, B1) of the HT Control field are 11b, the HT Control field may be an HE variant. Also, the HT Control field may be determined by the first and second bits (B0, B1) of the HT Control field and an additional bit, for example, the 32nd bit (B31), indicating whether the HT Control field is an HE variant, an EHT variant, or a NEXT variant.

[0201] In the embodiment shown in Figure 18, if the TRS is included in the HE PPDU, the STA that receives the HE PPDU sends the HE TB PPDU as a response to the TRS. If the TRS is included in the EHT PPDU, the STA that receives the EHT PPDU sends the EHT TB PPDU as a response to the TRS. If the TRS is included in the NEXT PPDU, the STA that receives the EHT PPDU sends the NEXT TB PPDU as a response to the TRS.

[0202] Furthermore, the information indicated by the subfields contained in the TRS may change depending on the PPDU format in which the TRS is included. When the TRS is included in an HE PPDU, the subfields related to the MCS contained in the TRS, for example, the UL HE-MCS subfield, can indicate a value corresponding to the HE MCS table. Similarly, when the TRS is included in an EHT PPDU, the subfields related to the MCS contained in the TRS, for example, the UL HE-MCS subfield, can indicate a value corresponding to the EHT MCS table. Furthermore, when the TRS is included in a NEXT PPDU, the subfields related to the MCS contained in the TRS, for example, the UL HE-MCS subfield, can indicate a value corresponding to the NEXT MCS table. Additionally, the information indicated by the RU Allocation subfield may change depending on the PPDU format in which the TRS is included.

[0203] Figure 19 shows a method for sharing a TXOP according to one embodiment of the present invention.

[0204] Referring to Figure 19, some or all of the TXOPs set by the AP are shared with a non-AP STA, and the non-AP STA can use the shared TXOPs to send PPDUs (PLCP Protocol Data Units) to other non-AP STAs (third STAs) and / or APs. Hereinafter, in this invention, sharing a TXOP with another STA can be referred to as TXOP sharing. Furthermore, an STA may be an AP or AP-STA that sends a trigger frame, or a non-AP STA that receives a trigger frame. Also, an STA can either share a TXOP or receive TXOP sharing.

[0205] Specifically, an STA can set (or acquire) a TXOP by sending a frame for setting the TXOP and then receiving a response to it. After setting the TXOP, the STA can share the set TXOP by sharing it. The response to the frame for setting the TXOP may include information about the length of the TXOP, and the length of the TXOP may be greater than 0. In this case, the response to the frame for setting the TXOP may be an immediate response and may be sent after a specific time (e.g., SIFS) from the end of the frame for setting the TXOP (e.g., PPDU).

[0206] The length of the TXOP may be indicated based on the duration information included in the frame transmitted by the STA. For example, the duration information may be included in the duration / ID field of the MAC header of the PPDU, and the length of the TXOP can be determined based on the duration information. The length of the TXOP may be included in the preamble of the PPDU of the frame transmitted by the STA. That is, the duration information may be included in the TXOP field contained in the signaling field of the PPDU, and the signaling field may be the HE-SIG-A field or the U-SIG field.

[0207] TXOP sharing may occur within a configured TXOP, and one or more TXOPs may be shared within a configured TXOP. In other words, one or more TXOPs may be shared with other STAs within a TXOP configured by an STA.

[0208] An STA that receives a TXOP share can transmit a PPDU over the shared TXOP to the STA that shared the TXOP or to another STA, and the transmitted PPDU may be a non-TB PPDU (e.g., a non-TB PPDU). In other words, an STA that receives a TXOP share can transmit a PPDU over the shared TXOP without receiving a trigger frame from the AP. To put it another way, an STA that receives a TXOP share can transmit a PPDU using the RU assigned by the trigger frame transmitted when receiving the TXOP share, even if no separate RU is individually assigned by a trigger frame over the shared TXOP, without receiving any additional trigger frames until the shared TXOP ends. Therefore, examples of PPDUs transmitted by an STA over a shared TXOP may include non-HT PPDU, HE PPDU, VHT PPDU, HE SU PPDU, or EHT MU PPDU.

[0209] In TXOP sharing, an STA that receives a shared TXOP can send a frame to the STA that shared the TXOP or to a third STA (and other STAs). In other words, when an AP sets up a TXOP and shares some or all of the set TXOP with an STA, the STA that receives the shared TXOP can send a frame to the AP that shared the TXOP or to a third STA. In this case, the frame that the STA sends to the third STA is a frame sent between non-AP STAs, and therefore may be a P2P (peer-to-peer) frame.

[0210] Such TXOP sharing may be established by a specific frame. That is, a specific frame may indicate that some or all of the TXOP set up will be shared, and the STA can receive the frame and use the shared TXOP. In this case, the specific frame may be transmitted by the STA sharing the TXOP. For example, TXOP sharing may be performed by a trigger frame transmitted by the AP. In this case, the trigger frame for TXOP sharing may be a specific type of trigger frame (e.g., a MU-RTS frame or a MU-RTS trigger frame), and may be identified by the value of the trigger type subfield of the trigger frame as described in Figure 16. That is, if the value of the trigger type subfield is set to an already set value (e.g., "3"), the STA that receives the trigger frame can recognize that the TXOP will be shared and can transmit a PPDU using the shared TXOP.

[0211] The MU-RTS frame, which is a frame for sharing a TXOP, may be a frame that instructs one or more STAs to send a CTS frame. For example, a CTS frame may be sent as an immediate response to a MU-RTS frame, and the CTS frame may be a non-HT PPDU. Hereinafter in this invention, the MU-RTS frame for sharing a TXOP may be called a modified MU-RTS frame or a MU-RTS TXS trigger frame. However, it is not limited to this, and frames for sharing a TXOP may be used under various names.

[0212] Sharing of part or all of a TXOP may be configured in only one STA, or in one or more STAs. That is, in TXOP sharing using frames, one or more STAs for TXOP sharing may be indicated by the frame. In this case, TXOP sharing may be configured within the TXOP configured by the sharing STA, as described above. That is, the shared TXOP cannot exceed the TXOP configured by the sharing STA.

[0213] The duration of the shared TXOP may be indicated by a specific frame for sharing the TXOP (e.g., a modified MU-RTS frame). For example, the modified MU-RTS frame may include a UL length subfield, which may contain the duration of the shared TXOP. In this case, the UL length subfield may be the UL length subfield described in Figure 16. The UL length subfield may contain information about the length of the indicated TB PPDU (or segment information for transmitting the TB PPDU) when the trigger frame indicates the transmission of the TB PPDU.

[0214] Whether a transmitted MU-RTS frame is a MU-RTS frame for TXOP sharing (modified MU-RTS frame) or a MU-RTS frame not used for TXOP sharing may be indicated by a specific field contained in the frame. For example, if the value of a specific field contained in the frame is a value that has already been set, the MU-RTS frame may be a modified MU-RTS frame for TXOP sharing. In this case, the specific field may be the GI And HE-LTF type subfield. For example, if the type field contained in a trigger frame indicates a MU-RTS frame, the value of the GI And HE-LTF type subfield may identify whether the MU-RTS frame is a trigger frame for TXOP sharing. That is, if the GI And HE-LTF type subfield is set to a value that has already been set, the trigger frame may be a trigger frame for TXOP sharing.

[0215] Alternatively, whether a received frame is a MU-RTS frame for TXOP sharing may be determined based on whether a specific field is included in the MU-RTS frame and / or the number of specific fields. In this case, the specific field may be the User Info field or User Info List field as described in Figure 16. Specifically, whether a received MU-RTS frame is a frame for TXOP sharing may be determined based on the number of User Info fields included in the MU-RTS frame. For example, if a MU-RTS frame does not include a User Info field (i.e., the number of User Info fields is "0"), then the MU-RTS frame may be a frame for TXOP sharing. In this case, if the MU-RTS frame is not a frame for TXOP sharing, then the MU-RTS frame may be an MU-RTS frame instructing one or more STAs to transmit an existing CTS frame, or the existing MU-RTS frame may be an MU-RTS frame as defined in the 802.11ax standard.

[0216] Immediately after a CTS frame is sent in response to an existing MU-RTS frame, the STA (e.g., AP) that sent the existing MU-RTS frame can send a frame or PPDU. Similarly, immediately after a CTS frame is sent in response to a modified MU-RTS frame, the STA that sent the CTS frame can send a frame or PPDU. Alternatively, an STA that received a TXOP share in response to a modified MU-RTS frame can send a frame or PPDU that is not a CTS frame. In this case, the frame and PPDU may be a frame sent by the STA that received the TXOP share via the shared TXOP, or a PPDU containing a frame sent by the STA that received the TXOP share via the shared TXOP, respectively. That is, the frame or PPDU may be directed to the AP or may be a P2P frame.

[0217] In this invention, what is referred to as a MU-RTS frame may be an existing MU-RTS frame. In other words, in this invention, what is referred to as a MU-RTS frame may be an MU-RTS frame that is not a modified MU-RTS frame.

[0218] According to one embodiment of the present invention, a CTS frame may be transmitted as a response to a modified MU-RTS frame. The CTS frame may be transmitted by an STA receiving a TXOP share. In such a case, the STA receiving the TXOP share can transmit a frame immediately after transmitting the CTS frame. The STA receiving the TXOP share can transmit a frame immediately after transmitting a PPDU containing the CTS frame. The frame transmitted immediately after transmitting the CTS frame may be included in the PPDU transmitted by the STA that received the TXOP share via the shared TXOP as described above. Alternatively, the frame transmitted immediately after transmitting the CTS frame may be included in the non-TB PPDU as described above. Furthermore, in the present invention, transmitting immediately after means transmitting at a time after SIFS or PIFS from the end of the PPDU containing the CTS frame. The CTS frame can serve to inform the STA receiving the TXOP share that it has received the TXOP share.

[0219] In further embodiments, a CTS frame does not need to be sent as a response to a modified MU-RTS frame. Also, an STA that receives a TXOP share immediately after a modified MU-RTS frame can send a frame. Alternatively, an STA that receives a TXOP share immediately after a PPDU containing a modified MU-RTS frame can send a PPDU. In this case, the frame to be sent may be included in the PPDU sent by the STA that received the TXOP share via the shared TXOP mentioned above. Alternatively, the frame to be sent may be included in the non-TB PPDU mentioned above. Furthermore, in the present invention, sending immediately after means sending at a time later by SIFS or PIFS from the end of the PPDU containing the modified MU-RTS frame.

[0220] In one embodiment, the modified MU-RTS frame may include signaling on whether the STA receiving the TXOP share should send a CTS frame. In one embodiment, when the STA receiving the TXOP share sends a frame to the AP, it is possible to use the shared TXOP without a CTS frame. Also, when the STA receiving the TXOP share sends a P2P frame, it is possible to use the shared TXOP by sending a CTS frame. Furthermore, even when the STA receiving the TXOP share sends a P2P frame, the RA field of the CTS frame sent immediately after the modified MU-RTS frame can be set to the MAC address of the STA that sent the modified MU-RTS frame. This is because, if the STA receiving the TXOP share does not send a frame containing the address of the STA that sent the modified MU-RTS frame after receiving the modified MU-RTS frame, it is difficult for the STA sharing the TXOP to know whether the STA receiving the TXOP share successfully received the modified MU-RTS frame.

[0221] Referring to Figure 19, STA1 and STA2 may exist and may be associated with each other. Also, STA1 may be an AP. STA2 may be a non-AP STA. STA1 is capable of transmitting MU-RTS frames. The MU-RTS frame may be an existing MU-RTS frame. The MU-RTS frame may include duration information related to TXOP duration. The MU-RTS frame can induce a CTS frame from one or more STAs. In this case, the one or more STAs may include STA2. STA2 can transmit a CTS frame as a response to the MU-RTS frame. In this case, STA1 may be a TXOP holder. The TXOP holder may be an STA that has obtained a TXOP. The TXOP holder can transmit the frame it wants to send via TXOP. Also, in this case, STA2 may be a TXOP responder. The TXOP responder may be an STA that has transmitted a response to the frame sent by the TXOP holder. A TXOP responder can send a response via TXOP to a frame transmitted by a TXOP holder. Alternatively, a TXOP responder can send a frame via TXOP that the TXOP holder has accepted. In the embodiment shown in Figure 19, an example of a TXOP being acquired based on the exchange of MU-RTS and CTS frames was described, but the present invention is not limited to this and can also be applied to cases where a TXOP is acquired based on other frame exchanges.

[0222] In Figure 19, STA1 can share a TXOP after acquiring it. For example, STA1 can send a modified MU-RTS frame, which is a frame that indicates TXOP sharing. For example, STA1 can send a modified MU-RTS frame to STA2. The TA (transmitter address) of the modified MU-RTS frame may be set to STA1's MAC address or a value based on STA1's MAC address. The RA (receiver address) of the modified MU-RTS frame may be set to STA2's MAC address or a value based on STA2's MAC address. In addition, the User Info field included in the modified MU-RTS frame may have an AID12 subfield value that indicates STA2. That is, the User Info field included in the modified MU-RTS frame may have an AID12 subfield value that indicates the 12th LSB of STA2's AID. The modified MU-RTS frame may include information about the duration of the shared TXOP.

[0223] In one embodiment, STA2 can send a CTS frame as a response to a modified MU-RTS frame. Furthermore, STA2 can send a frame after sending a CTS frame. The frame that STA2 sends after sending a CTS frame does not have to be a CTS frame. In yet another embodiment, STA2 does not have to send a CTS frame as a response to a modified MU-RTS frame. In this case, STA2 can send a frame that is not a CTS frame after a modified MU-RTS frame has been sent. Also, in one embodiment, the frame that is not a CTS frame that STA2 sends after receiving a modified MU-RTS frame may be a frame that is sent to STA1. In yet another embodiment, the frame that is not a CTS frame that STA2 sends after receiving a modified MU-RTS frame may be a frame that is sent to STA3.

[0224] For example, an AP can set its TXOP by sending a trigger frame to a non-AP STA (or STA). In this case, if the AP wants to share some or all of the TXOP set by the AP with the non-AP STA that sent the trigger frame, it can set a specific field in the trigger frame (e.g., the GI And HE-LTF type subfield) to an already set value and send it. In this case, the specific field can be called the GI And HE-LTF type / triggered TXOP sharing mode subfield. Specifically, if the AP does not share the TXOP set by the AP, the GI And HE-LTF type / triggered TXOP sharing mode subfield may be set to "0" and parsed as the GI And HE-LTF type subfield. However, if the AP does not share the TXOP set by the AP, the GI And HE-LTF type / triggered TXOP sharing mode subfield may be set to a value of "1" or "2" and interpreted as the triggered TXOP sharing mode subfield. If the value of the GI And HE-LTF type / triggered TXOP sharing mode subfield is "1" or "2", the trigger frame can be referred to as a modified MU-RTS frame or MU-RTS TXS trigger frame. When an AP shares some or all of a TXOP set up by the AP, the GI And HE-LTF type / triggered TXOP sharing mode subfield of the trigger frame for TXOP sharing indicates the TXOP sharing mode. For example, the GI And HE-LTF type / triggered TXOP sharing mode subfield indicates whether the TXOP sharing is limited to transmission and reception with the AP that set up the TXOP, or whether it is also shared with a third STA (and other STAs) in addition to the AP. That is, if the value of the GI And HE-LTF type / triggered TXOP sharing mode subfield is "1", the STA can only send PPDUs to the AP with the shared TXOP.However, when the value of the GI And HE-LTF type / triggered TXOP shared mode subfield is "2", the STA can send PPDUs to other STAs as well as APs on the shared TXOP. In other words, when the value of the GI And HE-LTF type / triggered TXOP shared mode subfield is "2", the STA can also perform P2P communication on the shared TXOP.

[0225] Table 1 below shows an example of the presence and mode of TXOP sharing based on the GI and HE-LTF type / triggered TXOP sharing mode subfield value.

[0226] [Table 1]

[0227] Figure 20 shows a method related to TXOP sharing and NAV configuration according to one embodiment of the present invention.

[0228] The embodiment in Figure 20 may be an embodiment that illustrates the problem of difficulty in performing the operation described in Figure 19 and a solution to that problem. The details described in Figure 19 can be omitted.

[0229] According to one embodiment of the present invention, an STA can set a network allocation vector (NAV) based on the duration information contained in the received frame or PPDU. Whether the virtual carrier sense (CS) result is idle or busy may be determined based on whether the NAV has been set. If the NAV value is 0, the virtual CS result may be idle. If the NAV value is greater than 0, the virtual CS result may be busy. The physical CS may be a clear channel assessment (CCA). If at least one of the virtual CS or physical CS is busy, the CS result may be busy. If both the virtual CS and physical CS are idle, the CS result may be idle. Furthermore, there may be cases where an STA includes multiple NAVs. For example, an STA may include an intra-BSS NAV and a basic NAV. The intra-BSS NAV may be a NAV set by an intra-BSS frame or an intra-BSS PPDU. Regular NAV may be set by an inter-BSS frame or inter-BSS PPDU, or a frame or PPDU that is either intra-BSS or cannot be determined to be inter-BSS. Also, virtual CS may be busy if at least one of intra-BSS NAV or basic NAV is greater than 0. Alternatively, if at least one of intra-BSS NAV or basic NAV is greater than 0, it can be said that the NAV is greater than 0. If both intra-BSS NAV and basic NAV are 0, virtual CS may be idle. Alternatively, if both intra-BSS NAV and basic NAV are 0, it can be said that the NAV is 0.

[0230] For a given STA, an intra-BSS frame or intra-BSS PPDU may be determined to have been transmitted from the same BSS as the STA. For a given STA, an inter-BSS frame or inter-BSS PPDU may be determined to have been transmitted from a different BSS than the STA. The determination of whether a frame was transmitted from the same BSS or a different BSS may be based on the BSS color field included in the PPDU's preamble, the address field included in the MAC header, etc. For example, if the BSS color field or address field contains a value corresponding to the same BSS, it can be determined to be an intra-BSS frame or intra-BSS PPDU. Conversely, if the BSS color field or address field does not contain a value corresponding to the same BSS, it can be determined to be an inter-BSS frame or inter-BSS PPDU. The address field may include the RA field, TA field, BSSID field, etc.

[0231] According to one embodiment, the STA can set up a NAV based on a received frame if the Resource Allocation (RA) field of the received frame is not its own MAC address. Alternatively, the STA can set up a NAV based on a received trigger frame. More specifically, the STA can set up a NAV based on a trigger frame which is a received intra-BSS frame. In this case, the NAV may be an intra-BSS NAV. In this case, the NAV can be set up regardless of whether the trigger frame triggers the STA. Alternatively, the STA can set up a NAV if a received frame or received PPDU does not instruct the STA to respond immediately.

[0232] According to one embodiment of the present invention, if the CS is busy, the STA may be unable to transmit a frame or PPDU.

[0233] According to one embodiment of the present invention, an STA whose NAV is set to a value greater than 0 may be unable to transmit a frame or PPDU. More specifically, an STA whose NAV is set to a value greater than 0 may be unable to transmit a frame or PPDU if it does not satisfy the previously set conditions.

[0234] According to one embodiment, an STA may transmit a received frame regardless of (or without considering) the NAV if the received frame is addressed to the STA and an immediate response is requested. More specifically, the received frame does not have to be an RTS frame or a trigger frame. That is, even if the NAV is set to a value greater than 0, the STA may transmit a received frame regardless of the NAV if the received frame is addressed to the STA and an immediate response is requested. Furthermore, if the frame is addressed to the STA, this may include cases where the RA field of the frame is set to the address of the STA. Alternatively, if the frame is addressed to the STA, this may include cases where the frame contains an identifier corresponding to the STA. The identifier may include a MAC address, an AID (association ID), an ID based on a MAC address, an ID based on an AID, etc.

[0235] In another embodiment, the STA may send a response to a received frame regardless of the NAV if the received frame was transmitted from the TXOP holder. In this case, the NAV may be the NAV set by the frame or PPDU sent by the TXOP holder. Alternatively, the NAV may be an intra-BSS NAV. The received frame may also be an RTS frame. It can be determined that the frame was transmitted from the TXOP holder based on the TA field contained in the frame. The STA can store the TXOP holder address. If the STA receives an RTS frame transmitted by the TXOP holder and the RTS frame is addressed to the STA, the STA can respond to the RTS frame without considering the NAV. In this case, a CTS frame can be sent as a response to the RTS frame.

[0236] In another embodiment, the STA may transmit a response to a trigger frame regardless of the NAV upon receiving it. In this case, the NAV may be limited to the intra-BSS NAV. Therefore, when the NAV is set by an STA or AP of the same BSS, the STA can transmit a response to a trigger frame regardless of the NAV when a response is instructed by the trigger frame. When the STA receives a trigger frame, it can decide whether or not to transmit a response, taking into account the intra-BSS NAV but not the basic NAV. Also, when the STA receives a trigger frame, it can decide whether or not to transmit a response to the trigger frame based on the CS result. For example, the trigger frame may include signaling that indicates whether or not to decide whether or not to transmit a response based on the CS result upon receiving the trigger frame. For example, the signaling may be the CS Required subfield shown in Figure 16. If the CS Required subfield indicates that the STA should decide whether to respond based on the CS result, the STA will respond to the trigger frame if both the virtual CS and physical CS indicate idle, but will not respond if either the virtual CS or physical CS indicates busy. In this case, it is possible to consider the basic NAV as the virtual CS and not the intra-BSS NAV. Also, if the CS Required subfield indicates that the STA should respond without relying on the CS result, the STA can respond to the trigger frame without checking the CS result.

[0237] In the embodiment shown in Figure 19, the STA that received the modified MU-RTS frame may be unable to transmit non-CTS frames via the shared TXOP because NAV has been set. This is further illustrated in Figure 20.

[0238] The explanation in Figure 19 in relation to Figure 20 may be omitted. Referring to Figure 20, STA1 and STA2 may exist and may be associated with each other. Also, STA1 may be an AP. STA2 may be a non-AP STA. STA1 can transmit MU-RTS frames. Also, STA2 can transmit CTS frames in response to the MU-RTS frames. In this case, STA2 transmitting a CTS frame may be because the physical CS result of STA2 is idle and basic NAV is not set. Alternatively, STA2 transmitting a CTS frame may be because STA2 has received a frame addressed to it and requesting an immediate response. In this case, even if other frame exchanges occur in addition to the exchange of MU-RTS frames and CTS frames, STA2 can transmit a response frame based on the frame received from STA1, because the frame is addressed to STA2 and requests an immediate response. Furthermore, STA2 may configure the NAV based on MU-RTS frames or other frames besides MU-RTS frames transmitted by STA1. In this case, the NAV may be an intra-BSS NAV.

[0239] Furthermore, STA1 can perform TXOP sharing with STA2. That is, STA1 can send a modified MU-RTS frame to STA2. In this case, as mentioned above, STA2 can use the shared TXOP to either 1) send a CTS frame followed by other frames, or 2) send other frames without sending a CTS frame. However, in this case, STA2 may have difficulty sending frames because NAV is set. For example, STA2's NAV may be set by frames sent by STA1 to obtain a TXOP before STA1 allocated a shared TXOP. That is, STA2's NAV may be set by receiving frames sent by STA1 before STA1 sent a modified MU-RTS frame. Or, STA2's NAV may be set by receiving frames sent by other STAs on the same TXOP before receiving a modified MU-RTS frame addressed to it. Or, STA2's NAV may be set based on a modified MU-RTS frame addressed to it. In other words, STA2 should receive at least modified MU-RTS frames when using shared TXOP, so NAV may be configured. For this reason, STA2 may have difficulty transmitting frames using shared TXOP.

[0240] Therefore, according to one embodiment of the present invention, an STA that has received a TXOP share can transmit a frame regardless of the NAV. For example, an STA that has received a TXOP share can transmit a frame using the shared TXOP regardless of the NAV. For example, an STA that has received a TXOP share can transmit a frame even if a NAV is set (or even if the NAV is greater than 0). According to a more specific embodiment, in this case, the NAV may be limited to the intra-BSS NAV. For example, an STA that has received a TXOP share can transmit a frame regardless of the intra-BSS NAV. Also, an STA that has received a TXOP share may be unable to transmit a frame if a basic NAV is set. Alternatively, an STA that has received a TXOP share can transmit a frame regardless of the NAV set by the frame sent by the coupled AP or by the PPDU. For example, if the NAV of an STA that has received a TXOP share is set by a frame sent by an STA that is not a coupled AP, it may be impossible to transmit a frame using the shared TXOP.

[0241] In other words, when an STA receives a TXOP share, it can send a PPDU regardless of the NAV set within the shared TXOP. Specifically, when an AP sends a trigger frame for TXOP sharing, the AP may set a NAV within the shared TXOP. In this case, the STA that receives the TXOP share may be unable to send a PPDU due to the NAV set within the shared TXOP. Therefore, the STA receiving the TXOP share can send a PPDU within the shared TXOP, ignoring the NAV set by the AP that shared the TXOP.

[0242] In this invention, the term "frame" can be replaced with a PPDU containing a frame, and the invention can be applied accordingly.

[0243] Furthermore, in this case, the frame that the STA transmits after receiving the TXOP share, regardless of NAV, may be transmitted after SIFS from the previous PPDU.

[0244] Furthermore, according to other embodiments, when an STA that has received a TXOP share transmits a frame, it is possible to consider NAV if the frame is transmitted after PIFS from the previous PPDU.

[0245] Referring to Figure 20, STA2 may have its NAV configured based on a MU-RTS frame or a modified MU-RTS frame. For example, an intra-BSS NAV may be configured. Alternatively, STA2 may have its NAV configured based on an intra-BSS frame. Alternatively, STA2 may have its NAV configured based on a frame transmitted by a coupled AP. In this embodiment, NAV may refer to a general term for such NAVs. STA1 can share a TXOP with STA2. STA2 can receive a TXOP share via a modified MU-RTS frame. When STA2 transmits a frame via shared TXOP, it is possible to transmit the frame regardless of the NAV. In this case, according to one embodiment, the frame to be transmitted may be the frame transmitted immediately after the CTS frame transmitted immediately after the received modified MU-RTS frame. In yet another embodiment, the frame to be transmitted may be the frame transmitted immediately after the received modified MU-RTS frame. Furthermore, according to one embodiment, the frame transmitted by STA2 may be a frame sent to the STA that transmitted the modified MU-RTS frame. That is, the RA field of the transmitted frame may be set to the value of the TA field of the received modified MU-RTS frame. Alternatively, the RA field of the transmitted frame may be set to the MAC address of the AP. According to another embodiment, the frame transmitted by STA2 may be a frame sent to STA3. Also, transmitting a frame immediately after the previous one means that the start time of transmission of the PPDU containing the frame is after SIFS from the end of the previous PPDU.

[0246] Figure 21 shows a TXOP sharing and CTS frame transmission according to one embodiment of the present invention.

[0247] The embodiment in Figure 21 may be a method for solving the problems described in Figures 19 and 20. Therefore, the above explanation can be omitted.

[0248] According to one embodiment of the present invention, in order to solve the problem of difficulty in transmitting frames in a shared TXOP considering NAV, the frame sequence can be continued in such a way that the conditions for transmitting a response regardless of NAV are met.

[0249] According to an embodiment of the present invention, an STA that has received a TXOP share can send a CTS-to-self frame as a response to a modified MU-RTS frame. The CTS-to-self frame may be a CTS frame in which the RA field is set to the MAC address of the STA that is sending the CTS-to-self frame. In such a case, the STA that is sharing the TXOP can determine that the shared TXOP allocation has been successful when it receives a frame containing the MAC address of the STA that is receiving the TXOP share after sending the modified MU-RTS frame.

[0250] Referring to Figure 21, STA2 can receive a modified MU-RTS frame from STA1. Furthermore, STA2 can send a CTS-to-self frame immediately after the modified MU-RTS frame. That is, STA2 can set its MAC address in the RA field of the CTS frame and send the CTS frame. In such a case, the CTS-to-self frame sent by STA2 can be considered as a frame addressed to it and requesting an immediate response. Alternatively, STA2 can consider that it received a frame addressed to it and requesting an immediate response in response to sending the CTS-to-self frame. Therefore, STA2 can send a frame immediately after the CTS-to-self frame even if NAV is configured.

[0251] According to an embodiment of the present invention, the RA field of a CTS frame transmitted as a response to an RTS frame or MU-RTS frame can be set to the TA field value of the RTS frame or the MU-RTS frame, or to a value in the TA field value where the Individual / Group bit is set to 0. However, as explained in Figure 21, a further method for setting the RA field of a CTS frame may be defined for transmitting a CTS-to-self frame. For example, the RA field of a CTS frame transmitted as a response to a modified MU-RTS frame can be set to the MAC address of the STA transmitting the CTS frame.

[0252] According to one embodiment of the present invention, an STA that receives a TXOP share may be able to perform recovery within the shared TXOP. That is, an STA that receives a TXOP share can perform recovery if a frame it transmits within the shared TXOP fails. For example, if a frame it transmits within the shared TXOP fails, an STA that receives a TXOP share can transmit the frame at a time PIFS later. According to an embodiment of the present invention, a TXOP holder can perform recovery. In addition, if a TXOP holder performs a TXOP share, an STA that receives the TXOP can perform recovery. That is, recovery is possible if 1) the STA is a TXOP responder, or 2) the STA is neither a TXOP holder nor a TXOP responder but receives a TXOP share. Furthermore, an STA that receives a TXOP share can also perform recovery if the first non-CTS frame it transmits after receiving a modified MU-RTS frame fails. For example, a TXOP holder may be unable to perform a recovery operation if the first frame transmitted in the sequence fails, and in this case, a TXOP may not have been obtained. However, an STA that receives a TXOP can perform a recovery operation even if a frame other than the first CTS frame transmitted with the shared TXOP fails.

[0253] Referring to Figure 21, STA2 can transmit the UL frame shown in the drawing and perform a recovery operation if it fails. That is, STA2 can transmit the UL frame and, if it fails to receive the DL frame shown in the drawing, transmit the frame again. In this case, the frame to be transmitted again can start transmission after PIFS from the end of the PPDU containing the failed UL frame shown in the drawing. It can also check whether the channel is idle during recovery. Furthermore, in the recovery operation performed by STA that has received a TXOP share, only the physical CS can be considered, and the virtual CS can not be considered.

[0254] Figure 22 shows an example of a trigger frame for sharing a TXOP according to one embodiment of the present invention.

[0255] As explained in Figure 19, whether or not a frame is a modified MU-RTS frame may be determined based on the number of user information fields. However, trigger frames defined in the 802.11ax standard may have been designed without considering that functionality may be extended in subsequent standards. Therefore, for example, the Common Info field shown in Figure 16(b) may lack sufficient signaling space to include extended functionality. Accordingly, according to one embodiment of the present invention, a user information field containing an already set AID12 subfield value may have a different format than that shown in Figure 16(c). Furthermore, a user information field containing an already set AID12 subfield value may include information applicable to all recipients or one or more recipients of the trigger frame containing the user information field. For example, a user information field containing an already set AID12 subfield value may include at least one of the following pieces of information: PHY version ID, bandwidth extension, bandwidth, spatial reuse, and U-SIG reserved bits. Furthermore, the previously set AID12 subfield value may be based on a value that is not actually assigned as an AID. The previously set AID12 subfield value may be 12LSB of a value that is not actually assigned as an AID. For example, the previously set AID12 subfield value may be 2007.

[0256] Furthermore, the aforementioned extended functionality may include, for example, an extended bandwidth. For instance, the bandwidth may be extended from a maximum of 160 MHz to a maximum of 320 MHz. The extended functionality may also include information for generating the U-SIG field.

[0257] Therefore, according to embodiments of the present invention, in order to use the extended functionality within a modified MU-RTS frame or a shared TXOP, the modified MU-RTS frame may include a user information field containing the aforementioned already set AID12 subfield value.

[0258] According to an embodiment of the present invention, a modified MU-RTS frame may contain no user information fields, or may contain only a user information field that includes the previously set AID12 subfield value described above. That is, if a received trigger frame contains no user information fields, or contains only a user information field that includes the previously set AID12 subfield value described above, the trigger frame can be determined to be a modified MU-RTS frame. Alternatively, if a received MU-RTS frame contains no user information fields, or contains only a user information field that includes the previously set AID12 subfield value described above, the MU-RTS frame can be determined to be a modified MU-RTS frame. In this case, the STA receiving the TXOP share may be indicated by the RA field of the trigger frame.

[0259] Referring to FIG. 22, in the modified MU-RTS frame, the type subfield may be set to MU-RTS. Also, the modified MU-RTS frame may have one user information field. At this time, the AID12 subfield included in the user information field may be set to a value that has already been set. At this time, the already set value may be a value that cannot be assigned as an AID. Also, the already set value may be a value different from the 12 LSBs of the AID of the STA having the RA field value of the modified MU-RTS frame as the MAC address. For example, the already set value may be 2007. Or, the modified MU-RTS frame may not include any user information fields. That is, when the Type of the trigger frame received by the STA is set as the MU-RTS frame, if the trigger frame does not include any user information fields or only includes the user information field including the AID12 subfield of the already set value, the trigger frame can be determined as a modified MU-RTS frame. <??0009?0> FIG. 23 is a diagram showing the NAV time out according to an embodiment of the present invention.

[0261] Note: There is a problem with the tag in the original text. It seems to be an incomplete or incorrect tag. I have translated it as best as possible while keeping it as is. If this is a known issue with the original text format, it might need to be corrected for a more accurate translation in a proper context.According to an embodiment of the present invention, the STA may be able to reset the set NAV. For example, when the NAV is set based on an RTS frame or a MU-RTS frame, it may be possible to reset the NAV. More specifically, when the NAV is set based on an RTS frame or a MU-RTS frame, it may be possible to reset the NAV when the PPDU reception cannot be successfully started at the already set time. Such an operation can be called NAV timeout or NAVTimeout. The already set time can be called the NAVTimeout period or the NAV timeout period. The NAVTimeout period may be started when a PHY-RXEND.indication primitive corresponding to the RTS frame or the MU-RTS frame is received.

[0262] In an embodiment of the present invention, when the NAV is set based on an RTS frame or a MU-RTS frame, it can mean that the most recent NAV update was made based on an RTS frame or a MU-RTS frame. If the duration information received by the STA from the RTS frame or the MU-RTS frame is greater than the current NAV value of the STA, the NAV can be set or updated based on the RTS frame or the MU-RTS frame. The duration information can be obtained based on the Duration / ID field included in the MAC header, or based on the TXOP duration or the TXOP field included in the preamble of the PPDU.

[0263] Furthermore, in embodiments of the present invention, the PHY-RXSTART.indication primitive can be received when PPDU reception is successfully initiated. Alternatively, the PHY-RXSTART.indication primitive can be issued when PPDU reception is successfully initiated. The PHY-RXSTART.indication primitive may be transmitted from the PHY to the MAC. For example, the PHY-RXSTART.indication primitive may be generated when the PHY receives a valid start of a PPDU. Receiving a valid start of a PPDU can mean receiving a valid PHY header. The PHY-RXSTART.indication primitive can also be generated after determining the PPDU format. When the PHY-RXSTART.indication primitive is generated, the PHY can maintain the physical medium in a busy state for the length of the PPDU or the length indicated by the PPDU preamble. If the PHY-RXSTART.indication primitive is generated, even if reception fails in the middle of the PPDU, the PHY can maintain the physical medium in a busy state for the length of the PPDU or the length indicated by the PPDU's preamble. Additionally, the PHY-RXEND.indication may be generated when PPDU reception is complete.

[0264] According to embodiments of the present invention, the aforementioned NAV timeout period may be based on the response time to an RTS frame or MU-RTS frame. That is, if the response to an RTS frame or MU-RTS frame is a CTS frame, the NAV timeout period may be based on the CTS frame time. The CTS frame time can be denoted as CTS_Time. Alternatively, the response time to an RTS frame or MU-RTS frame can be denoted as CTS_Time. In this case, the response time to an RTS frame or MU-RTS frame may mean the length of the PPDU including the response.

[0265] According to one embodiment, the NAV timeout period may be based on at least one of the following: 1) CTS_Time 2) aSIFSTime 3) aRxPHYStartDelay 4) aSlotTime

[0266] According to one embodiment, CTS_Time can be calculated based on a previously set rate. That is, CTS_Time may be the length of the CTS frame calculated based on a previously set rate. Or, that is, CTS_Time may be the length of the PPDU containing the CTS frame calculated based on a previously set rate. For example, the previously set rate may be 6 Mbps. For example, CTS_Time can be calculated based on a data rate of 6 Mbps. Or, the previously set rate may be the rate of the RTS frame or MU-RTS frame that is set to configure NAV. Or, the previously set rate may be the rate indicated by the RTS frame or MU-RTS frame that is set to configure NAV.

[0267] In one embodiment, aSIFSTime may be the SIFS length. For example, aSIFSTime may be 10us when operating in the 2.4GHz band. For example, aSIFSTime may be 16us when operating in the 5GHz or 6GHz band.

[0268] In one embodiment, aRxPHYStartDelay may be the delay from the start of the PPDU until the receiver generates the PHY-RXSTART.indication primitive. For example, aRxPHYStartDelay may be the time from the start of the PPDU until the PPDU format is determined. For example, aRxPHYStartDelay may vary depending on the PPDU format. aRxPHYStartDelay may be 20us for non-HT PPDUs. aRxPHYStartDelay may be 28us for HT PPDUs in HT-mixed format. aRxPHYStartDelay may be 24us for HT PPDUs in HT-greenfield format. aRxPHYStartDelay may be (36 + 4 * (the maximum possible value for N_VHT-LTF supported) + 4)us for VHT PPDUs, where N_VHT-LTF is the number of VHT-LTFs. Furthermore, aRxPHYStartDelay may be 32us for HE SU PPDU or HE TB PPDU. Also, aRxPHYStartDelay may be 40us for HE ER SU PPDU. Also, aRxPHYStartDelay may be (32 + 4 * N_HE-SIG-B)us for HE MU PPDU, where N_HE-SIG-B is the number of OFDM symbols in the HE-SIG-B field. Also, aRxPHYStartDelay may be 32us for EHT MU PPDU or EHT TB PPDU.

[0269] According to one embodiment, the NAV timeout period may be ((2*aSIFSTime)+(CTS_Time)+aRxPHYStartDelay+(2*aSlotTime)).

[0270] According to embodiments of the present invention, an RTS frame may be a frame that indicates a CTS frame. Alternatively, an RTS frame may be a frame that indicates a CTS frame from a single STA. An RTS frame may include a Frame Control field, a Duration field, an RA field, a TA field, and an FCS field. The Duration field may contain time information for the STA receiving the Duration field to set up the NAV. The RA field may contain the address of the intended immediate recipient. For example, if the RA field of an RTS frame received by an STA is the address of the STA, it is possible to respond to the RTS frame with a CTS frame. Furthermore, whether a frame is an RTS frame may be determined based on the Frame Control field contained in the frame. For example, whether a frame is an RTS frame may be determined based on the Type subfield and Subtype subfield contained in the Frame Control field contained in the frame. For example, if the Type subfield is 01 (B3 B2) and the Subtype subfield is 1011 (B7 B6 B5 B4), it can be indicated that the frame containing the Type subfield and the Subtype subfield is an RTS frame. For example, the RTS frame may be a Control frame.

[0271] A CTS frame may include a Frame Control field, a Duration field, an RA field, and an FCS field. The Duration field may contain time information for the STA receiving the Duration field to set the NAV. For example, if the Type subfield is 01 (B3 B2) and the Subtype subfield is 1100 (B7 B6 B5 B4), it can be indicated that a frame containing the Type subfield and the Subtype subfield is a CTS frame. For example, a CTS frame may be a Control frame.

[0272] Referring to the first sequence in Figure 23, STA1, STA2, and STA3 may exist. STA1 can also send an RTS frame or MU-RTS frame to STA2. For example, if the RA field of the RTS frame or MU-RTS frame is set to STA2's address, the RTS frame or MU-RTS frame may be sent to STA2. Alternatively, if the User Info field included in the MU-RTS frame points to STA2, the MU-RTS frame may be sent to STA2. If STA2 successfully receives the RTS frame or MU-RTS frame, it can respond with a CTS frame. In this case, STA2 can respond based on the CS (carrier sense) result. Furthermore, if STA3 receives the RTS frame or MU-RTS frame, STA3 can set the NAV based on the duration information included in the RTS frame or MU-RTS frame, or the duration information included in the PPDU containing the RTS frame or MU-RTS frame. Furthermore, if STA1 successfully receives a CTS frame transmitted by STA2, STA1 can transmit a frame to STA2. Also, after STA3 sets up NAV, it may receive a CTS frame transmitted by STA2 or a frame transmitted by STA1 to STA2. In such cases, STA3 can receive the PHY-RXSTART.indication primitive within the NAVTimeout period. Therefore, it is not necessary for STA3 to be unable to cancel the NAV it has set up.

[0273] Referring to the second sequence in Figure 23, STA1, STA2, and STA3 may exist. Also, STA1 can send an RTS frame or MU-RTS frame to STA2. If STA2 fails to successfully receive the RTS frame or MU-RTS frame, it may be impossible for STA2 to respond with a CTS frame. Alternatively, STA2 may successfully receive the RTS frame or MU-RTS frame, but be unable to respond with a CTS frame based on the CS result. In such cases, the frame sequence that STA1 sends to STA2 may not continue.

[0274] Furthermore, when STA3 receives the RTS frame or the MU-RTS frame, STA3 can set the NAV based on the duration information contained in the RTS frame or the MU-RTS frame, or the duration information contained in the PPDU containing the RTS frame or the MU-RTS frame. Also, after STA3 sets the NAV, it may be impossible for STA3 to receive the CTS frame transmitted by STA2 or the frame transmitted by STA1 to STA2. In such a case, STA3 does not need to receive the PHY-RXSTART.indication primitive within the NAVTimeout period. Therefore, the NAV set by STA3 can be released. This solves the problem where STA3 maintains the NAV and cannot access the channel even though the sequence is not continuing.

[0275] Figure 24 shows TXOP sharing and NAV timeout according to one embodiment of the present invention.

[0276] Referring to Figure 24, as mentioned above, STA1 can perform TXOP sharing with STA2. STA1 may be the STA that performs TXOP sharing, and STA2 may be the STA that receives TXOP sharing. STA1 can send the first frame of a sequence to STA2. Referring to Figure 24, the first frame of a sequence that STA1 sends to STA2 may be an MU-RTS frame. In addition, a CTS frame, which is a response to the MU-RTS frame, may be sent.

[0277] For example, a CTS frame may be transmitted from an STA including STA2. STA1 can obtain a TXOP. Also, STA3 may not have successfully received the MU-RTS frame and the CTS frame. STA1 can transmit a modified MU-RTS frame to STA2. That is, STA1 can share a TXOP with STA2. Also, STA3 can successfully receive the modified MU-RTS frame. Therefore, STA3 can set up a NAV based on the modified MU-RTS frame. In this case, STA3 may have set up a NAV based on the MU-RTS frame. Also, according to the TXOP sharing sequence described above, in response to a modified MU-RTS frame, STA2 can 1) transmit a CTS frame and then transmit a frame immediately after transmitting the CTS frame. Or, in response to a modified MU-RTS frame, STA2 can 2) not transmit a CTS frame and then transmit a frame. Also, STA3 may not receive a frame or PPDU from STA2. For example, STA3 may be located in a hidden position from STA2. For example, the power transmitted by STA2 may not be sufficient for STA3 to receive. In such cases, STA3 may not receive the PPDU during the NAV timeout period. This may be because the NAV timeout period is not determined based on CTS_Time. That is, if STA2 transmits a frame after transmitting a CTS frame, STA3 should have its NAVTimeout period completed while the frame is being transmitted. Or, if STA2 transmits a frame without transmitting a CTS frame, the frame is likely to be longer than the CTS frame, so STA3 should have its NAVTimeout period completed while the frame is being transmitted. Therefore, STA3 may be able to disengage NAV. If STA3 disengages NAV, STA3 may connect to the channel and disrupt the sequence in the shared TXOP.

[0278] FIG. 25 is a diagram showing sharing of a TXOP and NAV timeout according to still another embodiment of the present invention.

[0279] Referring to FIG. 25, when a TXOP is shared by an AP, other STAs (third STAs) that are not STAs for which the TXOP is shared by the AP do not have to release the shared TXOP even when a CTS frame or other frame is not transmitted from the STA for which the TXOP is shared for a certain period of time. The embodiment of FIG. 25 may be for solving the problems described in FIGS. 23 and 24. Also, the above-described content may be omitted.

[0280] Specifically, based on whether a trigger frame (e.g., MU-RTS frame) transmitted from the AP is a modified MU-RTS frame or a MU-RTS TXS trigger frame for sharing a TXOP, a NAV timeout for releasing the TXOP may be allowed or not allowed. That is, depending on whether it is a generally set TXOP or a TXOP for which all or part of a TXOP set by the AP is shared, it may be determined whether a NAV timeout for releasing the TXOP set by other STAs that are not the STAs for which the TXOP is set is allowed.

[0281] For example, when NAV is set based on a MU-RTS frame that is not a frame (modifited MU-RTS frame or MU-RTS TXS trigger frame) for sharing part or all of a set TXOP, a NAV timeout may be allowed. That is, when an STA sets NAV based on a MU-RTS frame, if the MU-RTS frame is not a modified MU-RTS frame, or if reception of a PPDU could not be successfully started within the NAVTimeout period, it may be possible to release the NAV.

[0282] However, if NAV is configured by a modified MU-RTS frame or MU-RTS TXS trigger frame that is a frame for sharing some or all of the configured TXOP, then a NAV timeout is not permitted. In other words, if STA configures NAV based on a MU-RTS frame, and that MU-RTS frame is a modified MU-RTS frame or MU-RTS TXS trigger frame for TXOP sharing, then STA may not be able to cancel NAV even if it fails to successfully start PPDU reception during the NAVTimeout period.

[0283] In other words, if the last frame received by the STA for NAV update is a modified MU-RTS frame or a MU-RTS TXS trigger frame, which are frames for TXOP sharing, the STA must not reset the NAV after the NAVTimeout has expired.

[0284] Whether a received MU-RTS frame is a modified MU-RTS frame can be determined according to the embodiments described above. For example, whether a frame is a modified MU-RTS frame can be determined based on the GI And HE-LTF Type subfield it contains. For example, if the GI And HE-LTF Type subfield value is 0, the MU-RTS frame containing the GI And HE-LTF Type subfield does not have to be a modified MU-RTS frame. Also, if the GI And HE-LTF Type subfield value is not 0, the MU-RTS frame containing the GI And HE-LTF Type subfield may be a modified MU-RTS frame. For example, if the GI And HE-LTF Type subfield value is 1 or 2, the MU-RTS frame containing the GI And HE-LTF Type subfield may be a modified MU-RTS frame.

[0285] By embodiment of the present invention, the problem described in Figure 24, in which the STA interferes with the sequence of shared TXOPs by performing a NAV timeout operation after setting up the NAV based on the modified MU-RTS frame, can be prevented.

[0286] Furthermore, such embodiments can be performed by terminals conforming to the 802.11be standard or later (terminals conforming to the EHT standard and subsequent standards), while it may not be possible for terminals conforming to the 802.11ax standard (HE STA). Even if HE STA cannot perform this, it can reduce the probability of the problems described in the above embodiments occurring.

[0287] Referring to Figure 25, STA1, STA2, and STA3 may exist. Also, STA1 can send an MU-RTS frame to STA2. For example, STA1 can send an MU-RTS frame that is not a modified MU-RTS frame. However, STA2, the intended recipient of the MU-RTS frame, may not be able to respond to the MU-RTS frame. Therefore, it may be impossible for STA2 to send a CTS frame. Also, STA3 can set up NAV based on the MU-RTS frame. However, because STA2 was unable to send a CTS frame, STA3 may not have successfully received the PPDU during the NAV timeout period. In this case, based on the NAV timeout operation, STA3 can cancel the set NAV. This may be because the frame that caused STA3 to set up NAV is an MU-RTS frame that is not a modified MU-RTS frame.

[0288] Furthermore, STA1 can transmit a modified MU-RTS frame. In Figure 25, the frame preceding the modified MU-RTS frame may be omitted. STA2, the intended recipient of the modified MU-RTS frame, can respond to it. STA3 can also set up the NAV based on the modified MU-RTS frame. However, STA3 may not receive the response that STA2 sent to the modified MU-RTS frame. For example, this may be because the response sent by STA2 to STA3 is not heard with sufficient power. For example, this may be because STA3 and STA2 are far apart. In such cases, STA3 may not be able to successfully start PPDU reception within the NAVTimeout period. This may be because STA2 transmitted a frame after the modified MU-RTS frame, after transmitting a CTS frame. Or, this may be because STA2 transmitted a frame longer than the CTS frame after the modified MU-RTS frame. Alternatively, this could be because STA2 sent a PPDU longer than the PPDU containing the CTS frame after the modified MU-RTS frame. In this case, STA3 may be unable to perform the action to disengage NAV based on the NAV timeout operation. This could be because the frame that caused STA3 to set up NAV is a modified MU-RTS frame.

[0289] Figure 26 shows TXOP sharing and NAV timeout according to yet another embodiment of the present invention.

[0290] The embodiment in Figure 26 may be intended to solve the problems described in Figures 23 and 24. Furthermore, the previously mentioned details may be omitted.

[0291] According to one embodiment of the present invention, the NAV timeout period may be determined differently depending on whether or not the MU-RTS frame is a modified MU-RTS frame. For example, the CTS_Time may be determined differently depending on whether or not the MU-RTS frame is a modified MU-RTS frame. According to one embodiment, when the MU-RTS frame is a modified MU-RTS frame, the NAV timeout period may be longer than the NAV timeout period when the MU-RTS frame is not a modified MU-RTS frame. In this embodiment, when the MU-RTS frame is a modified MU-RTS frame, the NAV timeout period can be called an extended NAVTimeout period. The NAVTimeout period and the extended NAVTimeout period described in Figure 23 can start at the same time. That is, they may start when the PHY-RXEND.indication primitive corresponding to the MU-RTS frame is received. The NAVTimeout period described in Figure 23 may be a time based on the CTS frame time. For example, the NAVTimeout period explained in Figure 23 may be a time based on the time it takes to transmit a CTS frame at 6 Mbps.

[0292] According to an embodiment of the present invention, when the STA sets up NAV based on a modified MU-RTS frame, it may be possible to deactivate the NAV if PPDU reception fails to be successfully completed within the extended NAVTimeout period. When the STA sets up NAV based on a modified MU-RTS frame, it may also be impossible to deactivate the NAV if PPDU reception fails to be successfully started within the NAVTimeout period as explained in Figure 23.

[0293] Furthermore, if STA sets up NAV based on a MU-RTS frame that is not a modified MU-RTS frame, it may be possible to deactivate NAV if PPDU reception fails to start successfully within the NAVTimeout period explained in Figure 23.

[0294] According to an embodiment of the present invention, the extended NAVTimeout period may be determined based on length information contained in the modified MU-RTS frame. For example, CTS_Time may be determined based on length information contained in the modified MU-RTS frame. Alternatively, the extended NAVTimeout period may be determined based on length information contained in the modified MU-RTS frame and the rate corresponding to the modified MU-RTS frame. For example, CTS_Time may be determined based on length information contained in the modified MU-RTS frame and the rate corresponding to the modified MU-RTS frame. For example, the length information contained in the modified MU-RTS frame may be included in the UL Length subfield shown in Figure 16. In yet another embodiment, the length information contained in the modified MU-RTS frame may be included in the User Info field shown in Figure 16. More specifically, the length information contained in the modified MU-RTS frame may be included in the User Info field that indicates the STA receiving the TXOP share, among the User Info fields shown in Figure 16.

[0295] Furthermore, an STA that receives a TXOP can transmit a PPDU based on the length information contained in the modified MU-RTS frame. For example, an STA that receives a TXOP can transmit the first PPDU of the shared TXOP based on the length information contained in the modified MU-RTS frame. Alternatively, an STA that receives a TXOP can transmit the first PPDU of the shared TXOP that does not include the CTS frame, based on the length information contained in the modified MU-RTS frame. The first PPDU of the shared TXOP that does not include the CTS frame may be the first PPDU after the PPDU that includes the CTS frame.

[0296] Referring to Figure 26, STA1, STA2, and STA3 may exist. Also, STA1 can send an MU-RTS frame to STA2. For example, STA1 can send an MU-RTS frame that is not a modified MU-RTS frame. However, it may be impossible for STA2, the intended recipient of the MU-RTS frame, to respond to the MU-RTS frame. Therefore, it may be impossible for STA2 to send a CTS frame. Also, STA3 can set NAV based on the MU-RTS frame. However, because STA2 was unable to send a CTS frame, STA3 may not have successfully started PPDU reception within the NAVTimeout period. In this case, based on the NAV timeout operation, STA3 can cancel the set NAV. This is because the frame that caused STA3 to set NAV is an MU-RTS frame that is not a modified MU-RTS frame, and therefore this operation may be based on the determined NAVTimeout period. In other words, since the frame that causes STA3 to set NAV is a MU-RTS frame that is not a modified MU-RTS frame, the NAVTimeout period can be determined based on the time it takes to transmit the CTS frame.

[0297] Furthermore, STA1 can transmit a modified MU-RTS frame. In Figure 26, the frame preceding the modified MU-RTS frame may be omitted. STA2, the intended recipient of the modified MU-RTS frame, can respond to it. STA3 can also set up the NAV based on the modified MU-RTS frame. However, STA3 may not receive the response that STA2 sent to the modified MU-RTS frame. For example, this may be because the response sent by STA2 to STA3 is not heard with sufficient power. For example, this may be because STA3 and STA2 are far apart. In such cases, STA3 may not be able to successfully start PPDU reception in the NAVTimeout period described in Figure 23. However, in such cases, STA3 can successfully start PPDU reception in the extended NAVTimeout period. Therefore, STA3 does not need to perform the NAV timeout operation. The fact that STA3 was able to wait for the extended NAVTimeout period without performing a NAV deactivation operation when the NAVTimeout period described in Figure 23 elapsed may be because the frame that caused STA3 to set NAV was a modified MU-RTS frame.

[0298] If STA2 is unable to respond to the modified MU-RTS frame, STA1 can perform a recovery operation. Therefore, PPDU reception can be successfully initiated before STA3 performs a NAV timeout operation.

[0299] Alternatively, if STA2, which receives the modified MU-RTS frame, is unable to respond, the shared TXOP sequence may be interrupted. In this case, STA3 can perform a NAV timeout operation, which solves the problem of being unable to connect to the channel because NAV is unnecessarily set when no frame exchange is actually occurring.

[0300] Figure 20 illustrates the problem and solution in TXOP sharing where a scheduled STA that has received a share of some or all of the TXOPs set by an AP has difficulty transmitting using the configured NAV. Further solutions for other embodiments are explained in Figure 27. Hereafter, the scheduled STA and the STA with shared TXOPs are the same STA and may be used interchangeably.

[0301] Figure 27 shows that STA and AP apply NAV when TXOP sharing is applied according to one embodiment of the present invention.

[0302] In TXOP sharing, a scheduled STA does not need to set a NAV. Specifically, in TXOP sharing, a scheduled STA does not need to set a NAV based on a modified MU-RTS frame or MU-RTS TXS trigger frame, which are MU-RTS frames for TXOP sharing setup. An STA that receives a MU-RTS frame for TXOP sharing setup does not need to set a NAV based on that MU-RTS frame. An STA scheduled by a MU-RTS frame for TXOP sharing setup does not need to set a NAV based on that MU-RTS frame. Therefore, when an STA receives a trigger frame and the trigger frame schedules TXOP sharing to the STA, the STA does not need to set a NAV based on the trigger frame. That is, depending on whether the trigger frame is a trigger frame for TXOP sharing, the STA can set a NAV based on the received trigger frame. For example, if the received MU-RTS frame is a modified MU-RTS frame or MU-RTS TXS trigger frame for TXOP sharing, the STA does not set a NAV based on the received MU-RTS frame. However, if the received MU-RTS frame is not a modified MU-RTS frame for TXOP sharing or a MU-RTS TXS trigger frame, the STA sets up a NAV based on the received MU-RTS frame.

[0303] Furthermore, in TXOP sharing, the scheduled STA does not need to configure NAV based on frames received within the shared TXOP.

[0304] In this case, "within the shared TXOP" can refer to the period until the shared TXOP terminates, even if the entire duration of the shared TXOP is not utilized. The TXOP terminates when the scheduled STA of the shared TXOP sends a PPDU, and the PPDU contains only frames that do not require an immediate response. Therefore, "within the shared TXOP" may refer to the period from when the TXOP share is established until the scheduled STA of the shared TXOP sends a PPDU containing only frames that do not require an immediate response. The shared TXOP may terminate when the scheduled STA of the shared TXOP signals the termination of the shared TXOP. Therefore, "within the shared TXOP" may refer to the period from when the TXOP share is established until the scheduled STA of the shared TXOP signals the termination of the shared TXOP. Alternatively, "within the TXOP" may refer to the period from when the TXOP share is established until the shared TXOP duration has elapsed. Or, the shared TXOP may terminate when the STA that received the TXOP share (or the STA that initiated the TXOP share) sends or receives a signal that the shared TXOP is terminating. In this case, the duration of the shared TXOP and the TXOP used by the AP for sharing (the TXOP initially acquired by the AP's frame) are either the same, or the duration of the shared TXOP is shorter than the duration of the TXOP. Therefore, even if the shared TXOP terminates, the TXOP does not need to terminate. In other words, if the duration of the shared TXOP and the duration of the TXOP are the same, the TXOP will terminate when the shared TXOP terminates. However, if the duration of the shared TXOP is shorter than the duration of the TXOP, the TXOP may be maintained even if the shared TXOP terminates.

[0305] In other specific embodiments, even if the shared TXOP terminates before the shared TXOP period, the shared TXOP period may be defined as the period from when the TXOP sharing is established until the shared TXOP duration has elapsed.

[0306] As mentioned above, in TXOP sharing, a scheduled STA can transmit frames regardless of the NAV. That is, if a NAV is set within a TXOP set by an AP (for example, a NAV set by an intra-BSS PPDU), the scheduled STA can transmit PPDUs within the shared TXOP regardless of the set NAV. In other words, an STA that receives a TXOP can transmit frames within the shared TXOP ignoring the NAV set by the frames transmitted by the STA that shared the TXOP. In this case, the shared TXOP may end before the section set by the MU-RTS frame. That is, an STA that received the TXOP before the section set by MU-RTS within the shared TXOP can interrupt the TXOP sharing by sending a signaling to request the interruption of the TXOP sharing. For example, if a non-AP STA receives all or part of a TXOP from an AP and has no PPDUs to transmit (or pending), it can interrupt the TXOP sharing by sending a signaling to the AP to terminate the TXOP sharing in order to terminate the shared TXOP. The point at which TXOP sharing is interrupted may be either when the non-AP STA sends a signaling request for the interruption of TXOP sharing, or when it receives a response frame to that signaling. In this case, the signaling for TXOP sharing may or may not require an immediate response. Also, in this case, since TXOP sharing is interrupted earlier than the period in which TXOP is shared as set by the MU-RTS frame, the non-AP STA can ignore the NAV set only up to the point at which TXOP sharing ends.

[0307] In this case, the STA that has configured TXOP sharing can also transmit frames regardless of NAV. In the embodiment shown in Figure 27, the first STA (STA1) transmits a MU-RTS frame for TXOP sharing configuration to the second STA (STA2). In this case, the first STA (STA1) may be an AP. The second STA (STA2) receives the MU-RTS frame for TXOP sharing configuration and transmits a CTS frame as a response to the MU-RTS frame for TXOP sharing configuration. The second STA (STA2) performs frame exchange within the shared TXOP. The first STA (STA1) can configure NAV based on frames transmitted by or sent to the second STA (STA2). For example, within the shared TXOP, the second STA (STA2) can perform frame exchange with the third STA (STA3). In this case, the first STA (STA1) can configure NAV based on frames transmitted by the third STA (STA3) to the second STA (STA2). Furthermore, the first STA (STA1) can set the NAV based on the frame transmitted by the second STA (STA2) to the third STA (STA3). When the first STA (STA1) sets the NAV in this way, it may be difficult for the shared TXOP to transmit frames within the assigned TXOP. For example, when the first STA (STA1) tries to transmit a frame after the shared TXOP has finished, it may be impossible to transmit the frame due to the NAV set within the shared TXOP. Specifically, if the frame contained in the PPDU transmitted within the shared TXOP is not a frame that would prompt an immediate response from the first STA (STA1), it may be impossible for the first STA (STA1) to transmit the frame due to the set NAV.

[0308] An STA that has configured TXOP sharing can transmit frames regardless of NAV within the TXOP it has acquired. Furthermore, in other specific embodiments, an STA that has configured TXOP sharing can transmit frames regardless of NAV within the TXOP it has acquired since the shared TXOP ended. The STA that has configured TXOP sharing may be the STA or TXOP holder that sent the MU-RTS frame for configuring TXOP sharing.

[0309] In this case, as mentioned above, the shared TXOP may terminate before the interval set by the MU-RTS frame. That is, the STA that received the TXOP can terminate the TXOP sharing by sending a signaling signal to terminate the TXOP sharing before the interval set by MU-RTS within the shared TXOP. For example, if a non-AP STA receives all or part of a TXOP from an AP and has no PPDUs to send (or pending), it can terminate the TXOP sharing by sending a signaling signal to the AP to terminate the shared TXOP. The point at which the TXOP sharing is terminated may be either the point at which the non-AP STA sends the signaling signal requesting the termination of the TXOP sharing, or the point at which it receives a response frame to that signaling signal. In this case, the signaling for TXOP sharing may or may not require an immediate response. Furthermore, in this case, since TXOP sharing is interrupted earlier than the interval in which TXOP set by the MU-RTS frame is shared, the AP can ignore the NAV set by the AP based on the PPDU sent and received by the non-AP STA from the point when TXOP sharing ends.

[0310] In the embodiment described above, the fact that an STA that has configured TXOP sharing transmits frames regardless of NAV indicates that it transmits frames regardless of NAV, which is set based on frames exchanged by scheduled STAs within the TXOP sharing. If an STA that has configured TXOP sharing transmits frames regardless of NAV, which is set based on frames not exchanged by scheduled STAs within the TXOP sharing, it may interfere with frame exchanges by other STAs. Furthermore, an STA can determine whether or not a frame was exchanged by a scheduled STA within the TXOP sharing based on the MAC header of the frame. Specifically, an STA can determine whether or not a frame was exchanged by a scheduled STA within the TXOP sharing based on the address field of the frame. The address field may include at least one of the RA field, TA field, and BSSID field. For example, if one of the fields in the address field of the frame indicates the MAC address of the STA, the STA can determine that it is a frame exchanged by a scheduled STA within the TXOP sharing. Additionally, an STA can determine whether or not a frame was exchanged by a scheduled STA within the TXOP sharing based on the preamble of the PPDU containing the frame. Furthermore, an STA can determine whether a frame was exchanged by a scheduled STA within a TXOP share based on at least one of the BSS color and STA ID contained in the preamble of the PPDU containing the frame. If the PPDU preamble contains the BSS color of the BSS to which the scheduled STA in the TXOP share belonged, and the PPDU preamble contains the STA ID corresponding to the scheduled STA in the TXOP share, the STA can determine that the frame contained in the PPDU was exchanged by a scheduled STA. In this case, the STA ID may be a value set based on the STA's AID.

[0311] In other specific embodiments, if an STA with TXOP sharing configured transmits regardless of NAV, it can use only physical CS, such as CCA, as the carrier sensing (CS) when transmitting frames. Therefore, the STA does not need to perform virtual CS.

[0312] In this specification, setting a NAV may be used interchangeably with updating a NAV. Furthermore, in this specification, a NAV may include at least one of either an Intra-BSS NAV or a Basic NAV. Unless otherwise specified, a NAV may refer to an Intra-BSS NAV. Also, in this specification, setting a NAV based on a frame in which an STA exists may include setting a NAV based on a PPDU containing the frame. Therefore, in this specification, not setting a NAV based on a frame in which an STA exists may include not setting a NAV based on a PPDU containing the frame.

[0313] MU-RTS frames for configuring TXOP shares can indicate the scheduled STA of the TXOP using the MAC address, for example, the RA field or User Info field. Configuring the NAV based on the duration information of the frame or PPDU can indicate that the last configured NAV is configured based on the duration information of the frame or PPDU.

[0314] In other specific embodiments, the Duration / ID field of a frame transmitted within a shared TXOP, or the TXOP of a PPDU containing the frame, may be set based on the shared TXOP. Specifically, the Duration / ID field of a frame transmitted within a shared TXOP, or the TXOP of a PPDU containing the frame, does not need to be allowed to be set beyond the shared TXOP. This prevents the problem where an STA that set the shared TXOP is unable to transmit frames after the shared TXOP has ended.

[0315] In other words, when a TXOP set by an AP is shared with an STA by a trigger frame, the duration information (e.g., Duration / ID field) contained in a frame (e.g., PPDU) transmitted within the shared TXOP may be set based on the shared TXOP. Specifically, the TXOP of a frame transmitted within a shared TXOP is not permitted to be set beyond the shared TXOP. Therefore, the TXOP of a PPDU transmitted to an AP or a third STA for P2P communication that set the TXOP within the shared TXOP must be the same as or earlier than the shared TXOP. Thus, the end time of the duration indicated by the duration information contained in the PPDU may be the same as or earlier than the end time of the shared TXOP. To put it another way, when part or all of a TXOP set by an AP is shared with a specific STA, the TXOP of a PPDU transmitted by that specific STA must not exceed the shared TXOP and must expire earlier. Therefore, the end time of the PPDU length (or TXOP) transmitted by a specific STA to a third STA for AP or P2P communication must be before, and not after, the end time of the shared TXOP. In this case, since the end time of the PPDU length (or TXOP) must be the same as or before the end time of the shared TXOP, the value indicated by the duration information contained in the PPDU may be set based on the shared TXOP.

[0316] In other specific embodiments, the STA that configured the shared TXOP does not need to configure the NAV based on the frames exchanged by the scheduled STA with the shared TXOP.

[0317] An STA that has set up a shared TXOP within a shared TXOP does not need to send a trigger frame. This is because if an STA that has set up a shared TXOP within a shared TXOP sends a trigger frame, the frame triggered by the trigger frame and the frame exchange of the scheduled STA may overlap. Also, if an STA that has set up a shared TXOP within a shared TXOP sends a trigger frame to a scheduled STA, the scheduled STA may need to send a response to the trigger frame. Therefore, this does not need to be consistent with the purpose of setting up the shared TXOP. In such an embodiment, the trigger frame may include a MU-RTS frame for setting up the TXOP share. In such an embodiment, after the shared TXOP has finished, the STA that set up the shared TXOP can send a trigger frame.

[0318] In the embodiment described above, the trigger frames that an STA that has configured a shared TXOP cannot send may be the remaining trigger frames, excluding the trigger frame for scheduled STAs that share the TXOP. Therefore, an STA that has configured a shared TXOP can send trigger frames only to scheduled STAs that share the TXOP within the shared TXOP. For example, an STA that has configured a shared TXOP can send a MU-RTS frame to configure the TXOP share in order to extend the shared TXOP. In this case, an STA that receives a MU-RTS frame to configure the TXOP share can start frame exchange without sending a CTS frame. Specifically, if frame exchange is only permitted with STAs that have configured the TXOP share within the TXOP share, an STA that receives a MU-RTS frame to configure the TXOP share can start frame exchange without sending a CTS frame.

[0319] In this specification, an operation performed on a shared TXOP may be an operation in which the shared TXOP is utilized by a scheduled STA of the TXOP share. An operation performed on a shared TXOP may be a scheduled STA of the TXOP share sending a frame in response to a MU-RTS frame for setting up the TXOP share, or a scheduled STA of the TXOP share sending a frame within the shared TXOP. In this case, the response frame to the MU-RTS frame for setting up the TXOP share may be a CTS frame.

[0320] This section describes the signaling for TXOP sharing operation. An STA can signal whether or not it can operate as a scheduled STA for TXOP sharing. In this case, the STA can signal whether or not it can operate as a scheduled STA for TXOP sharing using the EHT Capabilities element. In addition, the STA can send a signaling indicating whether or not it can operate as a scheduled STA for TXOP sharing using a (re)connection request frame or a probe request frame. An STA attempting to set up TXOP sharing can send a MU-RTS frame for setting up TXOP sharing only to STAs that have signaled that they can operate as a scheduled STA for TXOP sharing. Furthermore, an STA attempting to set up TXOP sharing may not be able to send a MU-RTS frame for setting up TXOP sharing to an STA that has signaled that it cannot operate as a scheduled STA for TXOP sharing.

[0321] Furthermore, the MU-RTS frame may include information indicating whether or not it is a MU-RTS frame for setting up a TXOP share. If the MU-RTS frame is a MU-RTS frame for setting up a TXOP share, the MU-RTS frame may also indicate the mode of the TXOP share. The mode of the TXOP share can indicate to which STAs a scheduled STA for the TXOP share can send frames. For example, in the first mode, a scheduled STA for the TXOP share can send frames only to the STA that has set up the TXOP share. In the second mode, a scheduled STA for the TXOP share can send frames to the STA that has set up the TXOP share, or it can send P2P frames. The first mode can be indicated if the value of the information indicating whether or not the MU-RTS frame is a MU-RTS frame for setting up a TXOP share is 1. The second mode can be indicated if the value of the information indicating whether or not the MU-RTS frame is a MU-RTS frame for setting up a TXOP share is 2. Additionally, if the value of the information indicating whether or not a MU-RTS frame is a MU-RTS frame for setting up a TXOP share is 0, it can indicate that the MU-RTS frame is not a MU-RTS frame for setting up a TXOP share.

[0322] In the embodiment described above, the GI And HE-LTF Type subfield can indicate whether or not the MU-RTS frame is a MU-RTS frame for setting up TXOP sharing. If the MU-RTS frame is a MU-RTS frame for setting up TXOP sharing, the GI And HE-LTF Type subfield can indicate the mode of TXOP sharing, as described above. In this case, the GI And HE-LTF Type subfield can be called the TXOP Sharing Mode subfield. The TXOP Sharing Mode subfield may be the subfield of bits 21 (B20) to 22 (B21) of the Common Info field in Figure 16.

[0323] Figure 28 illustrates how to terminate a TXOP share.

[0324] Figure 28 shows that STA terminates sharing of TXOP according to one embodiment of the present invention.

[0325] A scheduled STA for TXOP sharing can signal the end of TXOP sharing. If an STA that set up TXOP sharing receives the TXOP sharing termination signaling, that STA may become the TXOP holder. Also, if an STA that set up TXOP sharing receives the TXOP sharing termination signaling, that STA can transmit a frame or PPDU. Specifically, if an STA that set up TXOP sharing receives the TXOP sharing termination signaling, that STA can transmit a frame or PPDU even within the shared TXOP. Furthermore, if a scheduled STA for TXOP sharing signals the end of TXOP sharing, that scheduled STA may be unable to transmit any frames or PPDUs within the remaining shared TXOP.

[0326] A scheduled STA in TXOP sharing can signal the end of TXOP sharing using the A-Control subfield. Specifically, the SRS (single response scheduling) Control subfield of the A-Control subfield can signal the end of TXOP sharing. An STA that receives the SRS Control subfield can respond to the frame containing the SRS Control subfield with a PPDU that is not a TB PPDU. Furthermore, the length of the response PPDU for a frame containing the SRS Control subfield may be determined based on the SRS Control subfield. Specifically, an STA that receives the SRS Control subfield can set the length of the response PPDU for a frame containing the SRS Control subfield to the length indicated by the SRS Control subfield.

[0327] Figure 28(a) shows the format of the SRS Control subfield. As mentioned above, the SRS Control subfield may include a field that indicates the length of the PPDU, which is the response to the MAC frame containing the SRS Control subfield. In this case, the field can be called the PPDU Response Duration field. The PPDU Response Duration field can indicate time in units of 4us. The length of the PPDU indicated by the PPDU Response Duration field may be the value of the PPDU Response Duration field multiplied by 4us. The PPDU Response Duration field may also be an 8-bit field.

[0328] Furthermore, an STA can signal its capability for the SRS Control subfield. Specifically, an STA can signal whether or not it can receive the SRS Control subfield. An STA can also signal whether or not it can respond to a frame containing the SRS Control subfield. An STA may be unable to send an SRS Control subfield to an STA that has signaled that it does not support operations on the SRS Control subfield. An STA may send an SRS Control subfield to an STA that has signaled that it supports operations on the SRS Control subfield.

[0329] The SRS Control field may also include a field that signals the termination of TXOP sharing. This field can be called the Shared TXOP Termination field. The Shared TXOP Termination field may be a 1-bit field. When the value of the Shared TXOP Termination field is 1, it indicates that TXOP sharing has ended. When the value of the Shared TXOP Termination field is 0, it indicates that TXOP sharing has not ended. The STA can determine that TXOP sharing has ended when it receives a QoS Data frame or QoS Null frame in which the Shared TXOP Termination field is 1.

[0330] In other specific embodiments, a frame with pre-specified settings can signal the termination of a TXOP share. In this case, the frame with pre-specified settings may be a QoS Null frame. Specifically, the frame with pre-specified settings may be a QoS Null frame that does not include the A-Control subfield. Also, the frame with pre-specified settings may be a QoS Null frame that does not include the SRS Control subfield. A scheduled STA for a TXOP share can signal the termination of the TXOP share by sending a frame with pre-specified settings. Furthermore, if an STA that configured a TXOP share receives a frame with pre-specified settings, the STA that configured the TXOP share can determine that the TXOP share has terminated.

[0331] A scheduled STA for TXOP sharing may send a TXOP sharing termination signal, but the STA that configured the TXOP sharing may not receive the signal. In this case, the scheduled STA for TXOP sharing does not need to send a frame, as it may determine that the TXOP sharing has ended. Similarly, the STA that configured the TXOP sharing does not need to send a frame, as it may determine that the TXOP sharing has not ended.

[0332] In a specific embodiment, when a scheduled STA of a TXOP share that signals the termination of the TXOP share receives a response to the signal, the scheduled STA of the TXOP share can determine that the TXOP share has terminated. At this time, the scheduled STA of the TXOP share does not need to send a frame, as it has determined that the TXOP share has terminated. The response to the TXOP share termination signal may be an immediate response. Alternatively, the response to the TXOP share termination signal may be an ACK. However, such an embodiment may only be applied if the Ack policy of the TXOP share termination signal is set to require an immediate response. Specifically, when the Ack policy of the TXOP share termination signal requires an immediate response, the scheduled STA of the TXOP share that signals the termination of the TXOP share can determine that the TXOP share has terminated when it receives a response to the signal. If the acknowledgment policy for the termination signaling of a TXOP share does not require an immediate response, for example, if the scheduled STA of the TXOP share that signaled the termination of the TXOP share does not receive a response to the signaling, the scheduled STA of the TXOP share can determine that the TXOP share has terminated. In this case, the scheduled STA of the TXOP share can determine that the TXOP share has terminated when it sends the termination signaling for the TXOP share. Furthermore, if sending the termination signaling for the TXOP share fails, an error recovery operation may be performed. Specifically, the scheduled STA of the TXOP share can perform an error recovery operation. Also, the STA that configured the TXOP share can perform an error recovery operation.

[0333] In Figure 28(b), the first STA (STA1) sends a MU-RTS frame for TXOP sharing setup to the second STA (STA2). At this time, the first STA (STA1) may be an AP. The second STA (STA2) receives the MU-RTS frame for TXOP sharing setup and sends a CTS frame as a response to the MU-RTS frame for TXOP sharing setup. Within the shared TXOP, the second STA (STA2) sends a TXOP sharing termination signal (Frame to STA1 indicating termination) to the first STA (STA1). The first STA (STA1) fails to receive the TXOP sharing termination signal (Frame to STA1 indicating termination). At this time, the first STA (STA1) determines that the TXOP sharing has not terminated. As mentioned above, either the first STA (STA1) or the second STA (STA2) can perform an error recovery operation. After the error recovery operation, the second STA (STA2) sends a TXOP sharing termination signal (Frame to STA1 indicating termination) to the first STA (STA1). The first STA (STA1) sends an ACK (Ack to STA2) to the second STA (STA2), which is a response to the TXOP sharing termination signal (Frame to STA1 indicating termination). Upon receiving the ACK (Ack to STA2), the second STA (STA2) determines that the TXOP sharing has ended.

[0334] Even after TXOP sharing has ended, the scheduled STA for TXOP sharing can send a frame if the STA that configured the TXOP sharing instructs it to respond.

[0335] As mentioned above, it may be impossible to send an SRS Control subfield to an STA that has signaled that it will not support actions on the SRS Control subfield. If the SRS Control subfield signals the termination of a TXOP share, the STA that has signaled that it will not support actions on the SRS Control subfield may not receive the TXOP share termination signaling. Therefore, a scheduled STA for a TXOP share can send an SRS Control subfield that signals the termination of a TXOP share to an STA that has signaled that it will not support actions on the SRS Control subfield. An SRS Control subfield that signals the termination of a TXOP share may be an SRS Control subfield with a value of 1 in the TXOP Termination subfield. A scheduled STA for a TXOP share cannot send an SRS Control subfield with a value of 0 in the TXOP Termination subfield to an STA that has signaled that it will not support actions on the SRS Control subfield. Furthermore, the restriction that an SRS Control subfield cannot be sent to an STA that has signaled that it will not support actions on the SRS Control subfield may only apply if the SRS Control subfield is sent outside of the shared TXOP.

[0336] If the SRS Control subfield signals the end of TXOP sharing, the PPDU Response Duration subfield may be set as a reserved field. All bits of the reserved field may be set to 0. If the SRS Control subfield does not signal the end of TXOP sharing, the PPDU Response Duration subfield may indicate the length of the PPDU containing the frame that is the response to the frame containing the SRS Control subfield.

[0337] When the SRS Control subfield signals the end of TXOP sharing, the STA receiving the SRS Control subfield does not need to send a response for the frame containing the SRS Control subfield. In yet another specific embodiment, when the SRS Control subfield signals the end of TXOP sharing, the STA receiving the SRS Control subfield can send a response for the frame containing the SRS Control subfield regardless of the information the SRS Control field signals. In this case, the STA receiving the SRS Control subfield can send a response PPDU regardless of the length of the response PPDU for the frame containing the SRS Control subfield that the SRS Control subfield signals.

[0338] An STA that receives an SRS Control subfield within a shared TXOP does not need to send a response for the frame containing the SRS Control subfield. In yet another specific embodiment, an STA that receives an SRS Control subfield within a shared TXOP can send a response for the frame containing the SRS Control subfield regardless of the information signaled by the SRS Control field. In this case, the STA that receives the SRS Control subfield can send a response PPDU regardless of the length of the response PPDU for the frame containing the SRS Control subfield that the SRS Control subfield signals.

[0339] Alternatively, an STA receiving an SRS Control subfield within a shared TXOP does not need to respond based on the duration information (PPDU Response Duration subfield value) contained in the SRS Control subfield. For example, an STA receiving an SRS Control subfield within a shared TXOP may respond regardless of the duration information (PPDU Response Duration subfield value) contained in the SRS Control subfield.

[0340] According to one embodiment of the present invention, the modified MU-RTS frame does not have to be the first frame in the TXOP. For example, the TXOP holder may not send the modified MU-RTS frame to obtain the TXOP, but may send other frames instead. This allows the STA to set the NAV before setting the NAV based on the modified MU-RTS frame. That is, the STA can set the NAV based on frames sent in the TXOP before the modified MU-RTS frame. The aforementioned NAV timeout operation can be performed when the NAV is set based on an RTS frame or a MU-RTS frame, but by ensuring that there is a frame transmission in the TXOP before the modified MU-RTS frame, the need to set the NAV based on an RTS frame or a MU-RTS frame can be reduced. Furthermore, the duration information contained in the modified MU-RTS frame does not need to increase the TXOP.

[0341] Figure 29 shows an embodiment of the present invention that signals the format of the TB PPDU in response to a trigger frame using the Common Info field and Special User Info field contained in the trigger frame.

[0342] In an embodiment of the present invention, a station receiving a trigger frame can determine the format of the TB PPDU based on the User Info field contained in the trigger frame. Specifically, a particular User Info field contained in the trigger frame can indicate the format of the TB PPDU to be sent as a response to the trigger frame. For convenience of explanation, this particular User Info field will be referred to as the Special User Info field.

[0343] The AID12 subfield of the Special User Info field may be set to a pre-specified value. In this case, the pre-specified value may be 2007. It may also be a value that AP does not assign as AID (association ID). Furthermore, the format of the Special User Info field may differ from the format of a User Info field that is not a Special User Info field. The format of the subfields contained in the Special User Info field may differ from the format of the subfields contained in a User Info field that is not a Special User Info field. In this case, the format of the AID12 subfield contained in the Special User Info field may be the same as the format of the AID12 subfield contained in a User Info field that is not a Special User Info field. Therefore, the value of the first 12 bits of the Special User Info field, i.e., AID12, may be set to a pre-specified value. This allows the HE station to parse trigger frames containing the Special User Info field without errors.

[0344] Furthermore, the trigger frame may include a subfield indicating whether the trigger frame contains the Special User Info field. For convenience of explanation, the subfield indicating whether the Special User Info field is included will be referred to as the Special User Info Field Present field. Specifically, the Common Info field of the trigger frame may include the Special User Info Field Present subfield. In this case, the 56th bit (B55) of the Common Info field may be the Special User Info Field Present subfield. In a specific embodiment, if the value of the Special User Info Field Present subfield is 1, the trigger frame does not need to contain the Special User Info field. Also, if the value of the Special User Info Field Present subfield is 0, the trigger frame may contain the Special User Info field. This is because the 56th bit of the Common Info field in a legacy trigger frame is basically (default) set to 1. A station receiving the trigger frame can determine whether the trigger frame contains the Special User Info field based on the Special User Info field. If the value of the Special User Info Field Present subfield in the trigger frame received by the station is 1, the station can determine that the trigger frame does not contain the Special User Info field. Conversely, if the value of the Special User Info Field Present subfield in the trigger frame received by the station is 0, the station can determine that the trigger frame contains the Special User Info field.As in the example described above, when the Special User Info Field Present subfield is included in the trigger frame, it is possible to determine whether the Special User Info field is included in the trigger frame even if an unassociated station receives the trigger frame.

[0345] A trigger frame may include the Special User Info field before any User Info fields that are not Special User Info fields. Specifically, a trigger frame may include the User Info field immediately after the Common Info field. A station can determine the format of the TB PPDU response to a trigger frame based on whether the trigger frame it receives includes the Special User Info field. If the trigger frame it receives includes the Special User Info field, the station can send an EHT TB PPDU as a response to the trigger frame. If the trigger frame it receives does not include the Special User Info field, the station can send an HE TB PPDU as a response to the trigger frame. As mentioned above, a trigger frame may include the Special User Info Field Present subfield. In this case, the station can determine the format of the TB PPDU response to the trigger frame based on the value of the Special User Info Field Present field in the trigger frame it receives. If the value of the Special User Info Field Present field in the trigger frame it receives is 0, the station can send an EHT TB PPDU as a response to the trigger frame. If the value of the Special User Info Field Present field in the trigger frame received by the station is 1, the station can send an HE TB PPDU as a response to the trigger frame.

[0346] If the trigger frame contains a User Info field that is an EHT variant, the trigger frame may always contain a Special User Info field. If the trigger frame does not contain a Special User Info field, the trigger frame may not be permitted to contain a User Info field that is an EHT variant.

[0347] The method by which a User Info field that is an EHT variant indicates a RU may differ from the method by which a User Info field that is an HE variant indicates a RU. Specifically, the method by which the RU Allocation subfield of a User Info field that is an EHT variant indicates a RU may differ from the method by which the RU Allocation subfield of a User Info field that is an HE variant indicates a RU. For example, the RU Allocation subfield of a User Info field that is an EHT variant can indicate a RU index for a User Info field that is an EHT variant. Similarly, the RU Allocation subfield of a User Info field that is an HE variant can indicate a RU index for a User Info field that is an HE variant. A User Info field that is an EHT variant can use the RU Allocation subfield and the PS160 subfield to indicate the RU to be assigned to the station corresponding to the User Info field.

[0348] The RU Allocation subfield may be located immediately after the AID12 subfield, as explained in Figure 16. The RU Allocation subfield may also be an 8-bit field. The PS160 subfield can indicate which subchannel the RU indicated by the RU Allocation subfield of the User Info field containing the PS160 subfield is located on. In this case, the subchannel bandwidth may be 160MHz. Specifically, the PS160 subfield can indicate whether the RU indicated by the RU Allocation subfield of the User Info field containing the PS160 subfield is located on a primary 160MHz channel or a secondary 160MHz channel. The PS160 subfield may also be located immediately before the Trigger Dependent User Info subfield. The PS160 subfield is a 1-bit field and may be the 40th bit (B39) of the RU Allocation subfield.

[0349] The User Info field, which is an HE variant, can use the RU Allocation subfield to specify the RU to be assigned to the station corresponding to the User Info field.

[0350] In the embodiment shown in Figure 29, the station receiving the trigger frame can determine the format of a subfield that indicates the format of the TB PPDU to be sent as a response to the trigger frame on a pre-specified channel, and the format of a subfield that indicates the format of the TB PPDU to be sent as a response to the trigger frame based on the Special User Info field. In this case, the pre-specified channel may be the primary 160MHz channel. For convenience of explanation, the subfield that indicates the format of the TB PPDU to be sent as a response to the trigger frame is referred to as the HE / EHT P160 subfield. When the HE / EHT P160 subfield indicates that the format of the TB PPDU to be sent as a response to the trigger frame on the primary 160MHz channel is EHT TB PPDU, the station receiving the trigger frame can send an EHT TB PPDU as a response to the trigger frame regardless of the location of the RU assigned to the station. In this case, the value of the HE / EHT P160 subfield may be 0. Furthermore, if the HE / EHT P160 subfield indicates that the format of the TB PPDU transmitted as a response to the trigger frame on the primary 160MHz channel is EHT TB PPDU, the trigger frame may always include the Special User Info field.

[0351] When the HE / EHT P160 subfield indicates that the format of the TB PPDU to be sent as a response to a trigger frame on the primary 160MHz channel is HE TB PPDU, the station receiving the trigger frame can determine the format of the TB PPDU to be sent as a response to the trigger frame based on the location of the RU assigned to the station. In this case, the value of the HE / EHT P160 subfield may be 1. Specifically, if the HE / EHT P160 subfield indicates that the format of the TB PPDU to be sent as a response to a trigger frame on the primary 160MHz channel is HE TB PPDU, and the RU assigned to the station receiving the trigger frame is not included in the primary 160MHz, the station can send an EHT TB PPDU as a response to the trigger frame. Furthermore, the HE / EHT P160 subfield indicates that the format of the TB PPDU sent as a response to the trigger frame on the primary 160MHz channel is HE TB PPDU, and if the RU assigned to the station that received the trigger frame is included in the primary 160MHz, the station can send HE TB PPDU as a response to the trigger frame. In this case, the station can determine whether the RU assigned to the station is included in the primary 160MHz based on the value of the PS160 subfield.

[0352] The HE / EHT P160 subfield may be included in the Common Info field. Specifically, the HE / EHT P160 subfield may be the 56th bit (B55) of the Common Info field. Also, the HE / EHT P160 subfield may be included in the Common Info field which is an EHT variant, and the PS160 field may be included in the User Info field which is an EHT variant. Therefore, if the trigger frame includes the Special User Info field, the trigger frame may include the HE / EHT P160 subfield and the PS160 field. Figure 29 shows the Common Info field and Special User Info field to which such an embodiment applies.

[0353] The aforementioned EHT TB PPDU may be replaced with NEXT TB PPDU. Therefore, in the embodiment described above, when EHT TB PPDU is specified as the format for TB PPDU, either NEXT TB PPDU or EHT TB PPDU may be transmitted as TB PPDU. In this case, the station that receives the trigger frame can decide which PPDU, EHT TB PPDU or NEXT TB PPDU, to transmit as a response to the trigger frame, based on the Format Identifier subfield. Specifically, the station can transmit TB PPDU in the format of TB PPDU indicated by the Format Identifier subfield.

[0354] The Special User Info field may contain information necessary when sending an EHT TB PPDU as a response to a trigger frame. Specifically, the Special User Info field may contain information necessary to set the signaling field of the PPDU in the EHT TB PPDU sent as a response to a trigger frame. In this case, the signaling field of the PPDU may be the U-SIG field. In Figure 29, the Special User Info field may include the AID12 subfield, the PHY Version ID subfield, the UL Bandwidth Extension subfield, the Spatial Reuse1 subfield, the Spatial Reuse 2 subfield, the U-SIG Disregard And Validate subfield, the Reserved subfield, and the Trigger Dependent User Info field subfield. In this case, the AID12 subfield may be a 12-bit field. The PHY Version ID subfield may be a 2-bit field. The UL Bandwidth Extension subfield may be a 2-bit field. The Spatial Reuse1 subfield may be a 4-bit field. Furthermore, the Spatial Reuse 2 subfield may be a 4-bit field. The U-SIG Disregard And Validate subfield may be a 12-bit field. The Reserved subfield may be a 3-bit field. The Trigger Dependent User Info field subfield may have a variable length. The specific format of the Special User Info field may be as shown in Figure 29.

[0355] The PHY Version ID subfield may be the Format Identifier subfield, the PHY version identifier subfield, or the PHY version subfield mentioned above. When the value of the PHY version ID subfield is set to 0, the PHY version ID subfield can indicate the EHT physical layer. A station that receives a trigger frame can set the U-SIG field of the TB PPDU to be sent as a response to the trigger frame based on the Special User Info field. Specifically, a station that receives a trigger frame can set the values ​​of the subfields in the U-SIG field of the TB PPDU to the values ​​of the subfields in the Special User Info field. In this case, the subfields of the U-SIG field may include the PHY Version ID subfield, the Spatial Reuse1 subfield, the Spatial Reuse 2 subfield, and the U-SIG Disregard And Validate subfield. Furthermore, the station that receives the trigger frame can set the bandwidth (BW) subfield of the U-SIG field of the TB PPDU based on the UL Bandwidth Extension subfield of the Special User Info field and the UL BW subfield of the Common Info field.

[0356] Furthermore, a station that receives a trigger frame can perform a spatial reuse (SR) operation based on the Spatial Reuse 1 subfield or the Spatial Reuse 2 subfield. Specifically, if a station that receives a trigger frame determines that the trigger frame is an Inter-BSS frame, the station can perform an SR operation. An SR operation may be a type of channel access. When a station performs an SR operation, it can transmit a PPDU based on the information contained in the trigger frame and the transmit power of the PPDU it intends to transmit in the SR operation.

[0357] The UL Bandwidth Extension subfield may be used when the frequency bandwidth indicated by the trigger frame exceeds 160 MHz. The UL Bandwidth Extension subfield can indicate 320 MHz. The UL BW subfield of the Common Info field can indicate that the frequency bandwidth indicated by the trigger frame is one of 20 MHz, 40 MHz, 80 MHz, and 160 MHz. Values ​​0, 1, 2, and 3 of the UL BW subfield can indicate 20 MHz, 40 MHz, 80 MHz, and 160 MHz, respectively.

[0358] Furthermore, trigger frames can indicate the frequency bandwidth using the UL BW subfield in the Common Info field and the UL Bandwidth Extension subfield in the Special User Info field. Therefore, a station receiving a trigger frame can determine the frequency bandwidth indicated by the trigger frame based on the UL BW subfield in the Common Info field and the UL Bandwidth Extension subfield in the Special User Info field. The UL BW subfield in the Common Info field and the UL Bandwidth Extension subfield in the Special User Info field can indicate 20MHz, 40MHz, 80MHz, 160MHz, and 320MHz. In this case, the UL BW subfield and the UL Bandwidth Extension subfield can distinguish the 320MHz frequency band into 320-1MHz and 320-2MHz depending on the channel center frequency or starting frequency. When only the UL Bandwidth field is used without the UL Bandwidth Extension subfield, the value of the UL Bandwidth Extension subfield indicating 160MHz can indicate one of 160MHz, 320MHz-1, or 320MHz-2 together with the UL Bandwidth Extension subfield. Specifically, the value of the UL BW subfield, the frequency bandwidth indicated by the UL BW subfield when only the UL BW subfield is used without the UL Bandwidth Extension subfield, the value of the UL Bandwidth Extension subfield, and the frequency bandwidth indicated by the UL BW subfield and UL Bandwidth Extension subfield together are as shown in Table 2.

[0359] [Table 2]

[0360] In the embodiment described above, the frequency bandwidth indicated by the trigger frame can represent the frequency bandwidth used in the TB PPDU, frame, or transmission sequence transmitted based on the trigger frame.

[0361] The existence and length of the Trigger Dependent User Info subfield contained within the Special User Info field may be determined based on the type of trigger frame. That is, the existence and length of the Trigger Dependent User Info subfield contained within the Special User Info field may be determined based on which variant the trigger frame belongs to. The type of trigger frame can be indicated by the Trigger Type subfield contained within the Common Info field. The value of the Trigger Type subfield may be set to 0 to 7. In this case, the values ​​0 to 7 of the Trigger Type subfield can indicate a basic trigger frame, a BFRP (Beamforming Report Poll) frame, a MU-BAR frame, a MU-RTS frame, a Buffer Status Report Poll (BSRP) frame, a GCR MU-BAR frame, a BQRP (Bandwidth Query Report Poll) frame, and an NFRP (NDP Feedback Report Poll) frame, respectively.

[0362] In the embodiment described above, the HE station that transmits the TB PPDU based on the RA-RU of the trigger frame can also transmit the HE TB PPDU based on the RA-RU even if the trigger frame contains the Special User Info field. The method for resolving this issue is described below.

[0363] A station can determine the format of the TB PPDU it sends as a response to a trigger frame based on the variant of the User Info field corresponding to the station. Specifically, if the User Info field corresponding to the station in the trigger frame is the HE variant, the station can send an HE TB PPDU as a response to the trigger frame. If the User Info field corresponding to the station in the trigger frame is the ETH variant, the station can send an EHT TB PPDU as a response to the trigger frame. If the User Info field corresponding to the station in the trigger frame is the NEXT variant, the station can send a NEXT TB PPDU as a response to the trigger frame.

[0364] If the HE / EHT P160 subfield specifies that the format of the TB PPDU transmitted as a response to a trigger frame on the primary 160MHz channel is EHT TB PPDU, then the User Info field corresponding to the station may be the EHT variant. Also, if the HE / EHT P160 subfield specifies that the format of the TB PPDU transmitted as a response to a trigger frame on the primary 160MHz channel is HE TB PPDU, and the RU assigned to the station that received the trigger frame is not included in the primary 160MHz, then the User Info field corresponding to the station may be the EHT variant. Also, if the HE / EHT P160 subfield specifies that the format of the TB PPDU transmitted as a response to a trigger frame on the primary 160MHz channel is HE TB PPDU, and the RU assigned to the station that received the trigger frame is included in the primary 160MHz, then the User Info field corresponding to the station may be the HE variant.

[0365] MU-RTS frames may include the Special User Info field described above. Specifically, modified MU-RTS frames may include the Special User Info field. MU-RTS frames can indicate the bandwidth on which the MU-RTS frame is transmitted. Modified MU-RTS frames can also be assigned to shared TXOPs, as described above. Modified MU-RTS frames can indicate the bandwidth used by the shared TXOP. When a bandwidth exceeding 160 MHz is used by the shared TXOP, modified MU-RTS frames can use the Special User Info field to indicate a bandwidth exceeding 160 MHz. Specifically, in the embodiment described in Figure 29, the Special User Info field can indicate a bandwidth exceeding 160 MHz. In such embodiments, the fields of the Special User Info field, excluding the UL Bandwidth Extension field, may be set as reserved fields. Specifically, the values ​​of the fields of the Special User Info field, excluding the UL Bandwidth Extension field, may be set to 0. Furthermore, the UL Bandwidth Extension field in the Special User Info field may be set according to the embodiment described in Figure 29 above.

[0366] Figure 30 shows how a station according to an embodiment of the present invention sets the TXVECTOR parameter when transmitting a frame in response to a modified MU-RTS frame.

[0367] The method by which a station sets the TXVECTOR parameter when responding to a modified MU-RTS frame may differ from the method by which it sets the TXVECTOR parameter when responding to a MU-RTS frame that is not a modified MU-RTS frame. In this case, the TXVECTOR parameter may include TRIGGER_RESPONDING, which is set to true or false. The TXVECTOR parameter may be a parameter transmitted from the MAC layer to the physical layer. Specifically, when a station transmits, it propagates the TXVECTOR set at the MAC layer to the physical layer. The RXVECTOR parameter may be a parameter transmitted from the physical layer to the MAC layer. Specifically, when a station receives, the value of the RXVECTOR parameter is set at the physical layer, and the RXVECTOR parameter is propagated from the physical layer to the MAC layer.

[0368] The TXVECTOR parameter TRIGGER_RESPONDING may be set when a non-HT PPDU or non-HT duplicate PPDU is transmitted. Therefore, among the embodiments of the present invention, the embodiment relating to the TRIGGER_RESPONDING setting may be applied when a non-HT PPDU or non-HT duplicate PPDU is transmitted.

[0369] A station can set the TRIGGER_RESPONDING parameter of the TXVECTOR based on whether it sends a PPDU in response to a MU-RTS frame. For example, if a station sends a PPDU in response to a MU-RTS frame, the station may set the TRIGGER_RESPONDING parameter of the TXVECTOR to true. If a station does not send a PPDU in response to a MU-RTS frame, the station may set the TRIGGER_RESPONDING parameter of the TXVECTOR to false.

[0370] Furthermore, the transmission conditions of a station may change depending on the value of the TRIGGER_RESPONDING parameter of TXVECTOR. For example, if the TRIGGER_RESPONDING parameter of TXVECTOR is set to true, the station can transmit according to the pre-specified transmission conditions. If the TRIGGER_RESPONDING parameter of TXVECTOR is set to false, the station can transmit regardless of the pre-specified transmission conditions or under more relaxed transmission conditions than the pre-specified conditions. Therefore, the transmission conditions that a station must follow may change depending on whether or not the station transmits a TB PPDU. Specifically, when a station transmits a TB PPDU, the station can transmit according to the pre-specified conditions. Also, when a station transmits a PPDU that is not a TB PPDU, the station can transmit regardless of the pre-specified conditions or under more relaxed transmission conditions than the pre-specified conditions. When a station transmits a non-HT (duplicate) PPDU or a TB PPDU as a response to a MU-RTS frame, multiple stations can transmit PPDUs simultaneously. Therefore, the transmission parameter settings of multiple stations can make it difficult for a station receiving a PPDU to receive it. Furthermore, the transmissions of multiple PPDUs may not be synchronized, potentially causing interference between them. Additionally, the transmission power difference between multiple PPDUs may increase.

[0371] The pre-specified transmission conditions may include pre-correction accuracy requirements. They may also include pre-corrected transmission time, pre-corrected transmission frequency and transmission sampling symbol clock, and pre-corrected transmission power. In this case, the pre-corrected transmission frequency and transmission sampling symbol clock conditions can prevent inter-carrier interference. Furthermore, the pre-corrected transmission power conditions can adjust for interference between PPDUs. The pre-specified conditions may also include per-chain power conditions. Additionally, the pre-specified transmission conditions may include EVM (error vector magnitude) conditions and spectral mask conditions. Furthermore, the pre-specified conditions may include absolute transmit power accuracy conditions (accuracy of achieving a specified transmit power), RSSI measurement accuracy conditions (the difference between the RSSI and the received power), and relative transmit power accuracy conditions (accuracy of achieving a change in transmit power for consecutive PPDUs). The pre-specified conditions may also include correcting carrier frequency offset (CFO) errors and symbol clock errors. The carrier frequency offset error correction condition may be that the carrier frequency offset error does not exceed a pre-set level after carrier frequency correction.

[0372] Specifically, when a station transmits a triggered PPDU, i.e., a PPDU containing trigger information, as described below, it can correct carrier frequency offset (CFO) errors and symbol clock errors. In this case, the trigger information may include a trigger frame and a TRS Control field. - HE TB PPDU or EHT TB PPDU - Non-HT PPDU or non-HT duplicate PPDU with the TXVECTOR parameter TRIGGER_RESPONDING set to true.

[0373] When measured from 10% of the CCDF (complementary cumulative distribution function) of the AWGN carrier frequency offset error at a received power of -60 dBM at a primary of 20 MHz after correction, the absolute value of the remaining carrier frequency offset error corresponding to the triggering PPDU must not exceed the following level. - 350Hz for data subcarriers of HE TB PPDU or EHT TB PPDU - 2kHz for non-HT PPDU or non-HT duplicate PPDU

[0374] The excess carrier frequency offset error measurement of the EHT TB PPDU should be performed after the HE-SIG-A field or U-SIG field.

[0375] The remaining carrier frequency offset error measurement for non-HT PPDU or non-HT duplicate PPDU should be performed after the L-STF field. The symbol clock error must be compensated down to a ppm amount equal to the carrier frequency offset error alone.

[0376] A station transmitting an HE TB PPDU, EHT TB PPDU, non-HT PPDU, or non-HT duplicate PPDU in response to a triggering PPDU must ensure that the transmission start time of the HE TB PPDU, EHT TB PPDU, non-HT PPDU, or non-HT duplicate PPDU at the station's transmit antenna connector is within ±0.4us + 16us from the end of the last OFDM symbol of the triggering PPDU or the end of the PE field of the triggering PPDU.

[0377] However, a single station can transmit a response to a modified MU-RTS frame. Therefore, the aforementioned pre-specified transmission conditions are either not required for transmitting a response to a modified MU-RTS frame, or they may be relaxed.

[0378] A station can set the TRIGGER_RESPONDING parameter of the TXVECTOR differently when sending a response to a modified MU-RTS frame and when sending a response to a MU-RTS frame that is not a modified MU-RTS frame. Specifically, when a station sends a response to a modified MU-RTS frame, it can set the value of the TRIGGER_RESPONDING parameter of the TXVECTOR to false. Also, when a station sends a response to a MU-RTS frame that is not a modified MU-RTS frame, it can set the value of the TRIGGER_RESPONDING parameter of the TXVECTOR to true. Such embodiments may be applied when a station sends a non-HT PPDU or a non-HT duplicate PPDU, as described above.

[0379] In the embodiment shown in Figure 30, the first station (STA1) transmits a MU-RTS frame that is not a modified MU-RTS frame. The second station (STA2) transmits a CTS frame as a response to the MU-RTS frame that is not a modified MU-RTS frame. As in the embodiment described above, the second station transmits the CTS frame with the value of the TRIGGER_RESPONDING parameter of TXVECTOR set to true. The first station (STA1) transmits a modified MU-RTS frame. The second station (STA2) transmits a response to the modified MU-RTS frame to the first station (STA1). At this time, the second station transmits the response to the modified MU-RTS frame with the value of the TRIGGER_RESPONDING parameter of TXVECTOR set to false.

[0380] For the sake of explanation, the modified MU-RTS frame will be referred to as the MU-RTS TXOP Sharing (TXS) trigger frame.

[0381] Figure 31 shows the configuration of the management frame and the MU EDCA Parameter Set element according to an embodiment of the present invention.

[0382] A station can perform channel access based on multiple EDCA parameter sets. Channel access may include EDCA (enhanced distributed channel access). An EDCA parameter set may include an EDCA parameter set for each AC (access category). Furthermore, AC-specific EDCA parameter sets included in a single EDCA parameter set may have different parameter values. Also, when multiple EDCA parameter sets are distinguished as a first EDCA parameter set and a second parameter set, the values ​​of the EDCA parameters in the first EDCA parameter set for a single AC may differ from the values ​​of the EDCA parameters in the second EDCA parameter set. Furthermore, an AC may include AC_BE (best effort), AC_BK (background), AC_VI (video), and AC_VO (voice).

[0383] EDCA provides priority for each traffic, specifically CSMA / CA access by AC. Multiple EDCA parameter sets may include legacy EDCA parameter sets and MU EDCA parameter sets. Specifically, multiple EDCA parameter sets can be divided into legacy EDCA parameter sets and MU EDCA parameter sets. Legacy EDCA parameter sets may be stored in dot11EDCATable, and MU EDCA parameter sets may be stored in dot11MUEDCATable. EDCA parameter sets may include CWmin, CWmax, AIFSN, TXOP limit, and MSDU lifetime. MU EDCA parameter sets may include CWmin, CWmax, AIFSN, and MUEDCATimer. As mentioned above, EDCA parameter sets may include parameter values ​​for each AC. Therefore, EDCA parameter sets may be displayed as CWmin[AC], CWmax[AC], AIFSN[AC], TXOP limit[AC], and MSDU lifetime[AC]. Furthermore, the MU EDCA parameter set may be expressed as CWmin[AC], CWmax[AC], AIFSN[AC], and MUEDCATimer[AC].

[0384] In one embodiment, the contention window (CW) may be determined based on CWmin or CWmax. Furthermore, the backoff procedure may be invoked, the backoff counter reset, or a new one selected based on CW. For example, a randomly selected integer from 0 to CW can be used as the backoff counter. Also, when initializing CW, it may be initialized to CWmin. Furthermore, the smallest possible value for CW may be CWmin, and the largest possible value for CW may be CWmax.

[0385] Based on the AIFSN (arbitration interframe space number), the AIFS, as explained in Figure 6, may be determined. For example, the AIFS may be AIFSN*(slot time(aSlotTime))+SIFS(aSIFSTime). Specifically, the AIFS may be the waiting time when a station detects that a channel is busy and then attempts to access the channel again. The AIFS can also determine the slot boundary used when a station detects that a channel is busy and then attempts to access the channel again.

[0386] A station that has obtained a TXOP (transmit opportunity) can determine the end point of its transmission sequence based on the TXOP limit. Specifically, in principle, a station should end its transmission sequence within the TXOP limit, but in some exceptional circumstances, it may be permitted to perform a transmission sequence with a duration exceeding the TXOP limit.

[0387] The station can receive an element from the connected AP that indicates the value of a parameter in the EDCA parameter set, and can set the EDCA parameter set according to the value of the parameter indicated by the received element. Furthermore, if the station is unable to receive an element indicating the value of a parameter in the EDCA parameter set from the connected AP, the station can set the parameter value in the EDCA parameter set to its default value.

[0388] The AP can transmit a management frame containing elements that indicate the parameter values ​​of an EDCA parameter set. The management frame may include a beacon frame, a binding response frame, a rebinding response frame, and a probe response frame. The management frame may also contain multiple elements indicating each of several EDCA parameter sets. An element indicating the parameter values ​​of a legacy EDCA parameter set may be an EDCA Parameter Set element. Similarly, an element indicating the parameter values ​​of an MU EDCA parameter set may be a MU EDCA Parameter Set element.

[0389] In Figure 31, the management frame includes an EDCA Parameter Set element, a Capabilities element, an Operation element, and an MU EDCA Parameter Set element. The Capabilities and Operation elements may have separate elements defined for HT stations, VHT stations, HE stations, and EHT stations.

[0390] Elements may be identified by the Element ID field or Element ID Extension field they contain. The Element ID field and Element ID Extension field of an EDCA Parameter Set element indicate that it is an EDCA Parameter Set element. Similarly, the Element ID field and Element ID Extension field of a MU EDCA Parameter Set element indicate that it is a MU EDCA Parameter Set element.

[0391] The EDCA Parameter Set element and the MU EDCA Parameter Set element may include parameter record fields corresponding to each AC. The EDCA Parameter Set element may include parameter record fields specific to each AC. The MU EDCA Parameter Set element may also include MU parameter record fields specific to each AC. The parameter record field may include a subfield, the ACI field (AC Index), which indicates which AC each parameter record field corresponds to.

[0392] Furthermore, the parameter record field may include a subfield indicating CWmin, an ECWmin field, and a subfield indicating CWmax, an ECWmax field. In this case, the values ​​of CWmin and CWmax may be as follows. In this case, ECWmin indicates the value of the ECWmin subfield, and ECWmax indicates the value of the ECWmax subfield. CWmin = 2^ECWmin - 1 CWmax = 2^ECWmax - 1

[0393] Furthermore, the parameter record field may include a TXOP Limit subfield or a MU EDCA Timer subfield. Specifically, the Parameter Record field may include a TXOP Limit subfield, which can specify the TXOP limit. The MU Parameter Record field may include a MU EDCA Timer subfield, which can specify the MU EDCA timer.

[0394] A non-AP station can access a channel using a first EDCA parameter set. If the non-AP station successfully transmits a signal triggered by an AP, it can access the channel using a second EDCA parameter set. Accessing a channel using an EDCA parameter set may involve updating EDCA parameters, such as CWmin, CWmax, AIFSN, and the MU EDCA timer, based on the values ​​of the parameters in the EDCA parameter set. In this case, the first EDCA parameter set may be a legacy EDCA parameter set, and the second EDCA parameter set may be the MU EDCA parameter set. In this case, the non-AP station can set a timer that indicates the residual duration to which the second EDCA parameter set is applied when using the second EDCA parameter set. The timer value decreases steadily over time, and the non-AP station can use the second EDCA parameter set until the timer value reaches 0. When the timer value reaches 0, the non-AP station can access the channel using the first EDCA parameter set. Furthermore, when a non-AP station receives an element instructing it to reset the EDCA parameter set, the non-AP station may set the timer value to 0. In this case, the timer may be a MU EDCA timer. For the sake of clarity, in this specification, setting the timer value to a non-zero value is referred to as "setting the timer," and the EDCA timer that indicates the residual duration to which the second parameter set is applied is referred to as the timer for applying the second parameter set. In this case, the non-zero value may be a default value included in the EDCA parameter set.

[0395] Furthermore, the parameter values ​​of the first EDCA parameter set may be smaller than those of the second EDCA parameter set. In this case, the success rate of channel access using the second EDCA parameter set may be smaller than the success rate of channel access using the first EDCA parameter set. This allows for adjustment of channel access fairness between stations.

[0396] When a non-AP station successfully transmits a transmission triggered by an AP, this can represent a successful transmission solicited by a basic trigger frame. Furthermore, a successful transmission solicited by a basic trigger frame may be limited to cases where the non-AP station successfully transmits a QoS data frame solicited by a basic trigger frame. When a non-AP station successfully transmits a QoS data frame, it may be defined as follows: When the QoS data frame requests an immediate response, the non-AP station may be considered to have successfully transmitted the QoS data frame when it receives an immediate response to the QoS data frame. Also, when the QoS data frame does not request an immediate response, the non-AP station may be considered to have successfully transmitted the QoS data frame when it transmits the QoS data frame. Therefore, when a non-AP station transmits a QoS data frame requesting an immediate response and receives an immediate response to the QoS data frame, the non-AP station can update its EDCA parameters with the second EDCA parameter set. Furthermore, when a non-AP station sends a QoS data frame that does not request an immediate response, the non-AP station can update its EDCA parameters using a second EDCA parameter set. In this case, the non-AP station can update the EDCA parameters corresponding to the AC in the QoS data frame using the second EDCA parameter set. Also, when a non-AP station sends a QoS data frame that requests an immediate response and receives an immediate response to the QoS data frame, the non-AP station can set a timer for applying the second EDCA parameter set. In this case, the EDCA timer may start at the end of the PPDU containing the immediate response.Furthermore, when a non-AP station sends a QoS data frame that does not require an immediate response, the non-AP station can set a timer for applying the second EDCA parameter set. In this case, the timer for applying the second EDCA parameter set may start at the end of the PPDU containing the QoS data frame.

[0397] Figure 32 shows how a station to which a shared TXOP according to an embodiment of the present invention is assigned sets the MU EDCA parameter set.

[0398] The first EDCA parameter set and the second EDCA parameter set in the embodiment described in Figure 32 may be the same as the first EDCA parameter set and the second EDCA parameter set in the embodiment described in Figure 31.

[0399] A station assigned a TXOP share can access the channel using the second EDCA parameter set described above. In this case, the second EDCA parameter set may be the MU EDCA parameter set described above. Furthermore, in other specific embodiments, the second EDCA parameter set may be an EDCA parameter set with a lower priority than the legacy EDCA parameter set described above. Such embodiments can adjust the fairness of channel access between stations that have been assigned a shared TXOP and stations that have not been assigned a shared TXOP. For the sake of explanation, a station that assigns a shared TXOP will be referred to as the shared TXOP assignor, and a shared TXOP holder will be referred to as the shared TXOP holder.

[0400] When a station receives a MU-RTS TXS trigger frame and sends a response to the MU-RTS TXS trigger frame, the station can switch the EDCA parameters used for channel access from the first EDCA parameter set to the second EDCA parameter set. The response frame to the MU-RTS TXS trigger frame may be a CTS frame. Therefore, the response to the MU-RTS TXS trigger frame may represent a CTS frame or a PPDU containing a CTS frame. When a station receives a MU-RTS TXS trigger frame and sends a response to the MU-RTS TXS trigger frame, the station can perform channel access using the second EDCA parameter set within the shared TXOP. Such an embodiment may only apply if the shared TXOP holder allows the MU-RTS TXS trigger frame to be transmitted to only one station, e.g., an AP. That is, such an embodiment may not apply if the shared TXOP holder allows the MU-RTS TXS trigger frame to be transmitted to multiple stations, e.g., an AP and other non-AP stations.

[0401] In yet another specific embodiment, if a station to which a shared TXOP has been assigned sends at least one frame to the shared TXOP assignor, the station may switch the EDCA parameters used for channel access from a first EDCA parameter set to a second EDCA parameter set.

[0402] Furthermore, a station assigned a shared TXOP can set a timer for applying the second EDCA parameter set at the time the shared TXOP terminates. In yet another specific embodiment, a station assigned a shared TXOP can set a timer for applying the second EDCA parameter set at the time it receives a response corresponding to the signaling for terminating the shared TXOP. In yet another specific embodiment, a station assigned a shared TXOP can set a timer for applying the second EDCA parameter set at the earlier of the time the shared TXOP terminates or the time it receives a response corresponding to the signaling for terminating the shared TXOP. In this case, setting the timer for applying the second EDCA parameter set may be done by setting the value of the timer for applying the second EDCA parameter set to a value greater than 0, as described above.

[0403] In the embodiment shown in Figure 32, the first station (STA1) sends a MU-RTS TXS trigger frame to the second station (STA2) and assigns a shared TXOP to the second station (STA2). At this time, the second station (STA2) sends a CTS frame to the first station (STA1). As mentioned above, when the second station (STA2) sends a CTS frame to the first station (STA1), the second station (STA2) switches from the first EDCA parameter set to the second EDCA parameter set and performs channel access using the second EDCA parameter set. The second station (STA2) can also set a timer for applying the second EDCA parameters when the shared TXOP ends. This is to prevent the timer value from continuously decreasing even if the shared TXOP holder does not perform channel access, when the timer for applying the second EDCA parameters is set when the shared TXOP holder switches to the second EDCA parameter set. This ensures fairness with other stations.

[0404] Figure 32 illustrates an example in which, after the shared TXOP holder transmits a frame within the shared TXOP, the shared TXOP holder switches the EDCA parameters used for channel access from a first parameter set, such as the legacy EDCA parameter set, to a second parameter set, such as the MU EDCA parameter set. Such an example may be applied only when the shared TXOP holder successfully transmits a frame. Therefore, when the shared TXOP holder successfully transmits a frame, the shared TXOP holder can switch the EDCA parameters used for channel access from the first parameter set to the second parameter set. Furthermore, such an example may be applied only when the shared TXOP holder successfully transmits a QoS data frame. Furthermore, when the shared TXOP holder successfully transmits a QoS data frame, the shared TXOP holder can switch the EDCA parameters used for channel access from the first parameter set to the second parameter set. When a QoS data frame requires an immediate response, successfully transmitting a QoS data frame may mean transmitting the QoS data frame and receiving an ACK for the transmitted QoS data frame. Furthermore, if the QoS data frame does not require an immediate response, successfully transmitting the QoS data frame may be considered as transmitting the QoS data frame. When a shared TXOP holder successfully transmits a QoS data frame to a shared TXOP assignor within the shared TXOP, the shared TXOP holder sets the value of the EDCA timer for applying the second parameter set, for example, the MU EDCA timer, to a non-zero value.

[0405] Therefore, if a QoS data frame requires an immediate response, the shared TXOP holder can send the QoS data frame to the shared TXOP assignor within the shared TXOP and set an EDCA timer for applying the second parameter set at the end of the PPDU containing the immediate response to the QoS data frame received from the shared TXOP assignor. If a QoS data frame does not require an immediate response, the EDCA timer for applying the second parameter set can be set at the end of the PPDU containing the QoS data frame sent to the shared TXOP assignor within the shared TXOP.

[0406] In the previously described embodiment, the embodiment in which the shared TXOP holder switches the EDCA parameters used for channel access from the first EDCA parameter set to the second EDCA parameter set after the shared TXOP holder transmits a frame within the shared TXOP is applicable only in the first shared TXOP mode. This is because it can be difficult for the shared TXOP assignee to monitor frame exchange between the shared TXOP holder and other stations. Furthermore, if the shared TXOP holder does not exchange frames with the shared TXOP assignee, it is difficult to say that the shared TXOP holder has gained any advantage over other stations in frame exchange with the shared TXOP assignee.

[0407] Figure 33 shows the operation of a station according to an embodiment of the present invention to recover a shared TXOP after it has been allocated.

[0408] Within a shared TXOP, the shared TXOP assignee can only transmit if the pre-specified conditions are met. These pre-specified conditions may include at least one of the following: the shared TXOP assignee transmits an immediate response to a transmission by the shared TXOP holder within the shared TXOP, or a TXOP recovery operation is performed. In this case, the TXOP recovery operation may be performed when no frames are exchanged within the shared TXOP. If no transmission or reception occurs within the shared TXOP for a certain period of time or longer, the station can determine that no frames are being exchanged. Also, if a transmission failure occurs within the shared TXOP, the station can determine that no frames are being exchanged. In this case, if no immediate response is given to the transmitted frame, the station can determine that the transmission failed.

[0409] Furthermore, when a station receives a frame that does not require an immediate response, the station can determine that the frame will not be exchanged. Specifically, if a station receives an A-MPDU that contains only MPDUs that do not require an immediate response, the station can determine that the frame will not be exchanged. If the station fails to successfully receive all MPDUs in the A-MPDU, it cannot determine whether the A-MPDU contains only MPDUs that do not require an immediate response. Therefore, if the station fails to successfully receive all MPDUs in the A-MPDU, the station cannot perform TXOP recovery.

[0410] As mentioned above, if no transmission or reception occurs within a shared TXOP for a certain period of time, the station can determine that no frames are being exchanged. Specifically, if a channel that has been shared within a shared TXOP for a certain period of time is idle, the station can determine that no frames are being exchanged. In this case, the certain period of time may be PIFS (Public-Input Fastest). Furthermore, a channel being idle may be indicated by an idle CS (carrier sense) result for the channel. In this case, CS may be ED (energy detection). If the station detects the energy of a signal above the ED threshold in the ED, the station can determine that the medium is busy. Conversely, if the station detects the energy of a signal below the ED threshold in the ED, the station can determine that the medium is idle.

[0411] In this specification, a channel being idle at a TxPIFS slot boundary may be considered as a CS result being idle in PIFS, or as a channel being idle in PIFS. Furthermore, in this specification, initiating transmission after PIFS from a specific point in time, particularly from the end of the PPDU, may be explained on the premise that the channel is idle in PIFS. Furthermore, in this specification, the inability to initiate transmission after PIFS from a specific point in time, particularly from the end of the PPDU, may be explained on the premise that the channel is busy in PIFS.

[0412] Furthermore, PIFS may be the sum of SIFS (aSIFSTime) and slot time (aSlotTime). Also, the TxPIFS slot boundary may be the time from PIFS later than the time the channel switches to idle state until aRxTxTurnaroundTime. Therefore, the TxPIFS slot boundary may be TxSIFS slot boundary + aSlotIme. TxSIFS may be the time from SIFS later than the time the channel switches to idle state until aRxTxTurnaroundTime. aRxTxTurnaroundTime may be a value determined based on the time it takes for the station to switch from receive state to transmit state. Specifically, aRxTxTurnaroundTime may be the time it takes for the station to switch from receive state to transmit state. In other specific embodiments, aRxTxTurnaroundTime may be the maximum time it takes for the station to switch from receive state to transmit state. SIFS may be 16us, slot time 9us, and PIFS 25us. Specifically, when frame exchange takes place in the 5GHz or 6GHz band, SIFS may be 16us, slot time 9us, and PIFS 25us. Alternatively, SIFS may be 10us, slot time 9us, and PIFS 19us. Specifically, when frame exchange takes place in the 2.4GHz band, SIFS may be 10us, slot time 9us, and PIFS 19us.

[0413] Furthermore, the aforementioned embodiment of TXOP recovery may be applied only in the first shared TXOP mode. Specifically, it may be applied only when it is not permitted for the shared TXOP holder to transmit P2P frames within the shared TXOP.

[0414] Furthermore, the aforementioned TXOP recovery may only be applied if the shared TXOP holder receives or transmits the last frame before PIFS after the termination of the shared TXOP. In this case, if the shared TXOP holder receives or transmits the last frame after PIFS earlier than the termination of the shared TXOP, the station can access the channel after the shared TXOP.

[0415] Furthermore, although the above-described embodiment explained that TXOP recovery is performed by the shared TXOP assignee, the shared TXOP holder can also perform TXOP recovery according to the above-described embodiment.

[0416] In the embodiment shown in Figure 33, the first station (STA1) sends a MU-RTS TXS trigger frame to the second station (STA2) and assigns a shared TXOP to the second station (STA2). At this time, the second station (STA2) sends a CTS frame to the first station (STA1). Within the shared TXOP, the first station (STA1) sends a frame (DL frame 1) to the second station (STA2) and determines that the channel is idle in PIFS. When the first station (STA1) determines that the channel is idle in PIFS, the first station (STA1) sends a frame (DL frame 2) as a TXOP recovery operation.

[0417] Figure 33 illustrates how to recover a TXOP within a shared TXOP. When a shared TXOP terminates, the TXOP acquired by the shared TXOP assignee may not terminate. In this case, the shared TXOP assignee may need a way to recover the TXOP. This is explained in Figure 34.

[0418] Figure 34 shows an embodiment of the present invention in which a shared TXOP assignor performs TXOP recovery after the shared TXOP has terminated.

[0419] First, within a shared TXOP, the assignee of the shared TXOP can send messages under the following conditions:

[0420] When a shared TXOP assignee who has sent a MU-RTS TXS trigger frame in first shared TXOP mode receives a CTS frame from the shared TXOP holder, the shared TXOP assignee may initiate transmission within the shared TXOP only in the following cases:

[0421] A shared TXOP assignee can initiate transmission within the shared TXOP if they receive a PPDU requesting an immediate response from a shared TXOP holder within the shared TXOP. Additionally, a shared TXOP assignee can initiate transmission within the shared TXOP if the channel is idle at a TxPIFS slot boundary from the end of the last immediate response transmission sent to the station or the last non-immediate response frame transmission received from the TXOP holder in first shared TXOP mode.

[0422] When a shared TXOP assignee who has sent a MU-RTS TXS trigger frame in second shared TXOP mode receives a CTS frame from the shared TXOP holder, the shared TXOP assignee may initiate transmission within the shared TXOP only in the following cases:

[0423] When a shared TXOP assignor receives a PPDU requesting an immediate response from a shared TXOP holder within the shared TXOP, the shared TXOP assignor can initiate transmission within the shared TXOP.

[0424] Furthermore, when the TXNAV timer expires, that is, when the TXOP acquired by the shared TXOP assignee expires, the shared TXOP assignee cannot send any PPDUs without performing a new backoff procedure.

[0425] If a shared TXOP does not terminate after it has finished, the shared TXOP assigner can start sending when any one of the pre-specified conditions is met.

[0426] Condition 1: The shared TXOP assignor can perform a CS at the end of the shared TXOP and determine that the channel is idle at PIFS. In this case, the shared TXOP assignor can send the PPDU at a point in time that is PIFS later than the end of the shared TXOP.

[0427] Condition 2: The shared TXOP assignee's PPDU transmission may end after a point in time SIFS earlier than the end of the shared TXOP. In this case, the shared TXOP assignee can send a PPDU at a point in time SIFS later than the end of the PPDU sent by the shared TXOP assignee. Specifically, the shared TXOP assignee can send a PPDU SIFS later than the end of the PPDU sent by the shared TXOP assignee without performing a CS.

[0428] Third condition: The shared TXOP assignor can perform a CS at the end of the shared TXOP and determine that the channel is not idle. In this case, the shared TXOP assignor can send a PPDU when the channel is idle, i.e., when the channel is idle at the TxPIFS slot boundary.

[0429] Condition 4: The shared TXOP assignor can acquire the TXOP by performing the backoff procedure required to acquire it. At this point, the shared TXOP assignor can send a PPDU.

[0430] In the embodiment shown in Figure 34, the first station (STA1) sends a MU-RTS TXS trigger frame to the second station (STA2) and assigns a shared TXOP to the second station (STA2). At this time, the second station (STA2) sends a CTS frame to the first station (STA1).

[0431] In the embodiment shown in Figure 34(a), when the first station (STA1) transmits the first frame (DL frame 1) within the shared TXOP, there is a time remaining that is less than PIFS but greater than SIFS until the end of the shared TXOP. At this time, the first station (STA1) performs a CS at the end of the shared TXOP and determines that the channel is idle at PIFS. Therefore, the first station (STA1) can transmit the second frame (DL frame 2) at a time that is PIFS later than the end of the shared TXOP. However, the interval between the first frame (DL frame 1) and the second frame (DL frame 2) is greater than 25us. Therefore, this may constitute a violation of existing regulations. Specifically, this may violate the provision in the wireless LAN standard that states that when a station that has acquired a TXOP performs frame exchange, the interval between frames is not permitted to be greater than 25us.

[0432] In the embodiment shown in Figure 34(b), when the second station (STA1) transmits a frame (UL frame or P2P frame) within the shared TXOP, a time interval smaller than PIFS but larger than SIFS remains until the end of the shared TXOP. At this time, the first station (STA1) performs a CS at the end of the shared TXOP and determines that the channel is idle at PIFS. Therefore, the first station (STA1) can transmit a frame (DL frame) at a time later than PIFS from the end of the shared TXOP. At this time, the interval between PPDUs transmitted by the first station (STA1) is greater than 25us. Also, the interval between a PPDU transmitted by the second station (STA2) and a PPDU transmitted by the first station (STA1) is greater than 25us. Therefore, this may also violate the aforementioned regulations regarding transmission intervals within a TXOP.

[0433] Furthermore, if the first station (STA1) fails to detect all frame exchanges within the shared TXOP and either performs a CS at the end of the shared TXOP or the frame exchange ends at the end of the shared TXOP, the interval between PPDUs is greater than 25us. This is also true when PPDU transmission occurs under condition 3 mentioned above. That is, the interval between the last PPDU transmitted within the shared TXOP and the first PPDU transmitted by the first station (STA1) after the shared TXOP is greater than 25us. This, too, may violate the aforementioned regulations regarding transmission intervals within a TXOP.

[0434] In the embodiment shown in Figure 34(c), the transmission of the first frame (DL frame 1) by the first station (STA1) ends after SIFS from the end of the shared TXOP. At this time, the first station (STA1) can transmit the second frame (DL frame 2) after SIFS from the end of the PPDU containing the first frame (DL frame 1).

[0435] Figure 35 illustrates TXOP recovery after the termination of a shared TXOP, which does not violate the regulations regarding the interval between PPDUs transmitted within the TXOP.

[0436] Figure 35 shows a diagram illustrating how a shared TXOP assigner performs TXOP recovery after the shared TXOP has terminated, according to yet another embodiment of the present invention.

[0437] The first condition described in Figure 34 may be modified as follows: The end of the last PPDU in the shared TXOP may be PIFS earlier than the end of the shared TXOP. In this case, if the channel is idle between the end of the last PPDU transmitted in the shared TXOP and PIFS, the shared TXOP assignor can transmit a PPDU at a time PIFS later than the end of the last PPDU transmitted in the shared TXOP. Such an embodiment may only be applied when the shared TXOP holder is not permitted to transmit to stations other than the shared TXOP assignor within the shared TXOP. In this specification, a PPDU transmitted in a shared TXOP may refer only to a PPDU transmitted by the shared TXOP holder within the shared TXOP, and a PPDU transmitted in response to a PPDU transmitted by the shared TXOP holder. For convenience of explanation, the last PPDU transmitted in the shared TXOP will be referred to as the last PPDU of the shared TXOP. Furthermore, the case in which the shared TXOP holder is not permitted to transmit to stations other than the shared TXOP assignor within the shared TXOP will be referred to as the first TXOP sharing mode. Furthermore, the case in which a shared TXOP holder is permitted to transmit to stations other than the shared TXOP assignee within a shared TXOP is referred to as the second TXOP sharing mode.

[0438] In this case, the last PPDU of the shared TXOP may be the PPDU sent by the shared TXOP holder. In this case, the shared TXOP assignor can perform TXOP recovery according to the embodiment described above, but only if the PPDU does not contain a frame requesting an immediate response.

[0439] In the embodiment shown in Figure 35, the first station (STA1) sends a MU-RTS TXS trigger frame to the second station (STA2) and assigns a shared TXOP to the second station (STA2). At this time, the second station (STA2) sends a CTS frame to the first station (STA1).

[0440] In the embodiment shown in Figure 35(a), when the first station (STA1) transmits the first frame (DL frame 1) within the shared TXOP, a time interval smaller than PIFS but larger than SIFS remains until the end of the shared TXOP. At this time, the first station (STA1) performs a CS at the end of the first frame (DL frame 1) and determines that the channel is idle at PIFS. Therefore, the first station (STA1) can transmit the second frame (DL frame 2) at a time PIFS later than the end of the first frame (DL frame 1). Consequently, the interval between the first frame (DL frame 1) and the second frame (DL frame 2) is less than 25us.

[0441] In the embodiment shown in Figure 35(b), when the second station (STA1) transmits a frame (UL frame) within the shared TXOP, a time interval smaller than PIFS but larger than SIFS remains until the end of the shared TXOP. At this time, the first station (STA1) performs a CS at the end of the PPDU containing the frame (UL frame) and determines that the channel is idle at PIFS. Therefore, the first station (STA1) can transmit a frame (DL frame) at a time later by PIFS from the end of the PPDU containing the frame (UL frame). At this time, the interval between the PPDU transmitted by the second station (STA2) and the PPDU transmitted by the first station (STA1) is less than 25us.

[0442] In another specific embodiment, if the duration of the residual shared TXOP is less than PIFS, the shared TXOP holder does not need to be allowed to start transmitting. If the duration of the residual shared TXOP is less than PIFS, the shared TXOP assignor can transmit the PPDU at a time SIFS later than the end of the PPDU transmitted as the last PPDU of the shared TXOP. In this case, the shared TXOP assignor can transmit the PPDU at a time SIFS later than the end of the PPDU transmitted as the last PPDU of the shared TXOP without performing a CS. This is because they can be confident that the shared TXOP holder will not transmit because the duration of the residual shared TXOP is less than PIFS. In such an embodiment, if the last PPDU of the shared TXOP is the PPDU transmitted by the shared TXOP assignor, and the duration of the residual shared TXOP is less than SIFS, the assigned station can transmit the PPDU according to the second condition described in Figure 34.

[0443] If the duration of the residual shared TXOP is less than PIFS, the shared TXOP holder and the station that assigned the TXOP are not permitted to start transmitting. Specifically, if the duration of the residual shared TXOP is less than PIFS but greater than SIFS, the shared TXOP holder and the station that assigned the TXOP are not permitted to start transmitting.

[0444] Furthermore, if a shared TXOP does not terminate after it has finished, the following condition may be added to the conditions for the shared TXOP assignee to start sending:

[0445] Condition 5: The shared TXOP assignor can receive a frame requesting an immediate response from the shared TXOP holder. In this case, the shared TXOP assignor can send the PPDU at a time SIFS later than the end of the PPDU containing the frame requesting an immediate response. In this case, the interval between the end of the PPDU containing the frame requesting an immediate response and the end of the shared TXOP may be less than or equal to a predetermined value. The predetermined value may be SIFS. The predetermined value may be 0.

[0446] As mentioned above, the embodiment described in Figure 35 may be applied in the first shared TXOP mode. Figure 36 describes the TXOP recovery after the termination of the shared TXOP in the second shared TXOP mode.

[0447] Figure 36 shows a diagram illustrating how a shared TXOP assignor performs TXOP recovery after the shared TXOP has terminated, according to yet another embodiment of the present invention.

[0448] The embodiment described in Figure 35 may also be applied in the second shared TXOP mode. However, the embodiment described in Figure 35 may also be applied in the second shared TXOP mode only if the last PPDU of the shared TXOP contains a frame in which the shared TXOP assignor is the intended recipient.

[0449] Therefore, in the second shared TXOP mode, the last PPDU of the shared TXOP may contain a frame in which the shared TXOP assignor is the intended recipient, and the end of the last PPDU of the shared TXOP may be PIFS earlier than the end of the shared TXOP. In this case, if the channel is idle between the end of the last PPDU of the shared TXOP and PIFS, the shared TXOP assignor can send a PPDU at a time PIFS later than the end of the last PPDU of the shared TXOP. Such an embodiment may be applied only when the last PPDU of the shared TXOP does not contain a frame requesting an immediate response.

[0450] Furthermore, if the duration of the residual shared TXOP is less than PIFS, the shared TXOP holder is not permitted to start transmitting. If the duration of the residual shared TXOP is less than PIFS, the shared TXOP assignor can send the PPDU at a point SIFS later than the end of the last PPDU of the shared TXOP. In this case, the shared TXOP assignor can send the PPDU at a point SIFS later than the end of the last PPDU of the shared TXOP without performing a CS.

[0451] In other specific embodiments, if the duration of the residual shared TXOP is less than PIFS, the shared TXOP holder and the station that assigned the TXOP may not be permitted to start transmitting. Specifically, if the duration of the residual shared TXOP is less than PIFS but greater than SIFS, the shared TXOP holder and the station that assigned the TXOP may not be permitted to start transmitting.

[0452] However, unlike the embodiment in Figure 36, the shared TXOP assignor needs to determine whether the last PPDU of the shared TXOP contains a frame that the shared TXOP assignor is intended to receive. Specifically, the shared TXOP assignor can determine whether the frame contained in the last PPDU of the shared TXOP is a frame that the shared TXOP holder will send to the shared TXOP assignor.

[0453] In the embodiment shown in Figure 36, the first station (STA1) sends a MU-RTS TXS trigger frame to the second station (STA2) and assigns a shared TXOP to the second station (STA2). At this time, the second station (STA2) sends a CTS frame to the first station (STA1). In the embodiment shown in Figure 36(a), when the second station (STA2) sends a UL frame within the shared TXOP, there is a time remaining until the end of the shared TXOP that is less than PIFS but greater than SIFS. At this time, the first station (STA1) performs a CS at the end of the UL frame and determines that the channel is idle at PIFS. Therefore, the first station (STA1) can send a DL frame at a time PIFS later than the end of the UL frame. Thus, the interval between the UL frame and the DL frame is less than 25us.

[0454] If the intended recipient of the frame containing the last PPDU of a shared TXOP is the shared TXOP holder, the shared TXOP assignor may be permitted to perform TXOP recovery as in the embodiment shown in Figure 36(a).

[0455] If the sender of the frame contained in the last PPDU of a shared TXOP is the station that received the TXOP assignment, and the intended receiver is a station other than the shared TXOP assignor, the shared TXOP assignor can perform TXOP recovery based on whether the last PPDU of the shared TXOP contains a frame requesting an immediate response. However, if the sender of the frame contained in the last PPDU of a shared TXOP is the station that received the TXOP assignment, the intended receiver is a station other than the shared TXOP assignor, and the last PPDU of the shared TXOP contains a frame requesting an immediate response, the shared TXOP assignor is not permitted to perform TXOP recovery as described in the embodiment in Figure 36(a). This is because the shared TXOP assignor may have difficulty receiving response frames transmitted by P2P peer stations within the shared TXOP. If the channel is idle between the PPDU containing the immediate response to the aforementioned frame requesting an immediate response and the PIFS, the station that assigned the TXOP can start transmitting at a time later than the PIFS from the PPDU containing the immediate response. In yet another specific embodiment, a station assigned a TXOP can begin transmitting a PPDU with an immediate response only SIFS later.

[0456] In Figure 36(b), when the second station (STA2) transmits a P2P frame within the shared TXOP, a time interval of less than PIFS but greater than SIFS remains until the end of the shared TXOP. At this time, the P2P frame does not request an immediate response. The first station (STA1) performs a CS at the end of the P2P frame and determines that the channel is idle at PIFS. Therefore, the first station (STA1) can transmit a DL frame at a time PIFS later than the end of the P2P frame. Consequently, the interval between the P2P frame and the DL frame is less than 25us.

[0457] In Figure 36(C), when a P2P frame is transmitted to the second station (STA2) within the shared TXOP, a time interval smaller than PIFS but larger than SIFS remains until the end of the shared TXOP. The first station (STA1) performs a CS at the end of the P2P frame and determines that the channel is idle at PIFS. Therefore, the first station (STA1) can transmit a DL frame at a time PIFS later than the end of the UL frame. Consequently, the interval between the UL frame and the DL frame is less than 25us.

[0458] In the embodiment described above, the station to which the TXOP is assigned can determine the intended recipient of the received frame based on the recipient address of the received frame, for example, the RA field. Specifically, the station to which the TXOP is assigned can determine the station indicated by the recipient address of the receiving station as the intended recipient. The station to which the TXOP is assigned can also determine the sender of the received frame based on the sender address of the received frame, for example, the TA field. Specifically, the station to which the TXOP is assigned can determine the station indicated by the sender address of the receiving station as the sender. Furthermore, the station to which the TXOP is assigned can determine the intended recipient of the frame contained in the received PPDU based on the STA-ID field in the signaling field of the received PPDU. Furthermore, the station to which the TXOP is assigned can determine the intended recipient of the frame contained in the received PPDU based on the STA-ID field and the BSS color field in the signaling field of the received PPDU. Furthermore, the station that assigned the TXOP can determine the intended recipient of the frame contained in the received PPDU based on the STA-ID field, BSS color field, and UL / DL field in the signaling field of the received PPDU. In this case, the STA-ID field indicates the ID of the station that is the intended recipient of the frame contained in the PPDU. The BSS color field indicates the BSS color of the BSS from which the PPDU was transmitted. The UL / DL field indicates whether the PPDU is an uplink or downlink PPDU.

[0459] If the channel is busy at the end of a shared TXOP, even if the shared TXOP is included within a TXOP acquired by the shared TXOP assignee, the shared TXOP assignee is not permitted to start frame exchange without performing the backoff procedure to acquire the TXOP. A situation may arise where a station permitted to transmit within a shared TXOP is unable to transmit. In this case, even if the shared TXOP assignee starts transmitting immediately after the shared TXOP ends, the interval between the PPDU transmitted by the shared TXOP assignee and the PPDU transmitted within the shared TXOP may be greater than 25us. Therefore, the shared TXOP assignee can perform the backoff procedure to acquire the TXOP again.

[0460] Furthermore, it is possible that the frame containing the last PPDU of a shared TXOP is not successfully received, or that the frame containing the last PPDU of a shared TXOP is not included in the frame exchange of the shared TXOP holder. In this case, even within a TXOP acquired by the shared TXOP assignee, which contains the shared TXOP, it is not permissible for the shared TXOP assignee to initiate a frame exchange without performing the backoff procedure to acquire the TXOP. The case in which the frame containing the last PPDU of a shared TXOP is not included in the frame exchange of the shared TXOP holder is when the recipient of the frame containing the last PPDU of the shared TXOP is not the shared TXOP holder, and the sender of the frame containing the last PPDU of the shared TXOP is not the shared TXOP holder. This is because, in cases where the frame containing the last PPDU of a shared TXOP is not successfully received, or the frame containing the last PPDU of a shared TXOP is not included in the frame exchange of the shared TXOP holder, it is not guaranteed that the interval between the PPDU sent by the shared TXOP assignee and the PPDU sent within the shared TXOP will be within 25us.

[0461] Furthermore, in other specific embodiments, even within a TXOP acquired by the shared TXOP assignee that contains the shared TXOP after the termination of the second shared TXOP mode, the shared TXOP assignee is not permitted to initiate a frame exchange without a backoff procedure to acquire the TXOP.

[0462] Furthermore, the third condition explained in Figure 34 may be modified as follows.

[0463] The shared TXOP assignor can perform a CS at the end of the shared TXOP and determine that the channel is not idle. Furthermore, the transmission that occupies the channel at the end of the TXOP may be a frame exchange by the shared TXOP holder. In such cases, the shared TXOP assignor can transmit a PPDU when the channel is idle, i.e., when the channel is idle at the TxPIFS slot boundary.

[0464] The transmission that occupies the channel at the end of a TXOP does not have to be a frame exchange by the shared TXOP holder. In such cases, even within a TXOP acquired by the shared TXOP assignee that includes the shared TXOP after the TXOP has ended, the shared TXOP assignee is not permitted to initiate a frame exchange without a backoff procedure to acquire the TXOP. This is because, when the channel is occupied by a transmission that is not a frame exchange by the shared TXOP holder, and the shared TXOP assignee transmits according to existing condition 3, the interval between the last PPDU of the shared TXOP and the PPDUs transmitted by the shared TXOP assignee after the shared TXOP may be greater than 25us. This embodiment of modifying the application conditions of the third condition applies to the second shared TXOP mode and does not have to apply to the first shared TXOP mode.

[0465] In the embodiment described earlier in relation to TXOP recovery, the time interval indicated by the point in time earlier than PIFS from the end of the shared TXOP may include a point in time that is PIFS earlier than the end of the shared TXOP. Also, if the end time of the remaining shared TXOP is less than PIFS, this may include the case where the end time of the remaining shared TXOP is PIFS. Also, the time interval indicated by the point in time earlier than SIFS from the end of the shared TXOP may include a point in time that is SIFS earlier than the end of the shared TXOP. Also, if the end time of the remaining shared TXOP is greater than SIFS, this may include the case where the end time of the remaining shared TXOP is SIFS.

[0466] Figure 37 shows the format of a frame according to an embodiment of the present invention.

[0467] Figure 37(a) shows the format of a MAC frame. A MAC frame includes a MAC header, a frame body, and an FCS field. The MAC header may also include a Frame Control field, a Duration / ID field, a MAC address field, a Sequence Control field, a QoS Control field, and an HT Control field. The Frame Control field indicates the frame type and subtype by its Type subfield and Subtype subfield, respectively. The Frame Control field can also indicate whether the frame includes an HT Control field by its +HTC subfield. The Duration / ID field indicates the duration of the frame. The Duration / ID field indicates the duration of the frame if the frame containing the Duration / ID field is not a PS-Poll frame. The station can also set the NAV (network allocation vector) based on the duration of the frame indicated by the Duration / ID field of the received frame. If the frame containing the Duration / ID field is a PS-Poll frame, the Duration / ID field can indicate an ID, such as an AID. The MAC address field may also include one or more address fields. The Address field can specify the MAC address. The Address field may also contain at least one of the following fields: Basic Service Set Identifier (BSSID), Source Address (SA), Destination Address (DA), Transmitting STA Address or Transmitter Address (TA), and Receiving STA Address or Receiver Address (RA). The Sequence Control field can specify a fragment number or sequence number.Furthermore, the QoS Control field may include at least one of the following: the TID of the traffic contained in the frame, the Ack Policy for the frame, the TXOP limit of the frame exchange containing the frame, the buffer state of the station that sent the frame, and the queue size of the station that sent the frame. Additionally, the QoS Control field may include the aforementioned RDG / More PPDU subfield and AC Constraint subfield. For example, the QoS Control field included in DMG PPDU may include the aforementioned RDG / More PPDU subfield and AC Constraint subfield.

[0468] The HT Control field may include the aforementioned RDG / More PPDU subfield and AC Constraint subfield. As previously mentioned, the RDG / More PPDU subfield can signal whether the frame contains an RDG or whether there is a PPDU following the frame. The AC Constraint subfield can indicate whether the TID or AC of the response to the RDG (RD data frame) is restricted. The HT Control field may consist of 4 octets, i.e., 32 bits.

[0469] The length of the MAC header and the fields it contains may be set by pre-specified values.

[0470] The Frame Body field contains the frame's content. The Frame Body field may also contain information about the frame's type and subtype.

[0471] The FCS field may include the FCS (Frame Check Sequence). The value of the FCS field may be set based on the values ​​of the MAC header field and the Frame Body field. A station that receives a MAC frame can calculate the FCS using the values ​​of the MAC header field and the Frame Body field and compare it to the value of the FCS field. This allows the station that receives the MAC frame to determine whether the MAC frame was successfully received.

[0472] Figure 37(b) shows the format of the HT Control field. As previously mentioned, the HT Control field may include the AC Constraint subfield and the RDG / More PPDU subfield.

[0473] For example, the HT Control field may consist of 32 bits (B0-B31). In this case, the 31st bit (B30) and the 32nd bit (B31) may be the AC Constraint subfield and the RDG / More PPDU subfield, respectively. This may be the case when the HT Control field is an HT variant or a VHT variant. The HT Control field may have multiple forms or variants. For example, the HT Control field may be an HT variant, a VHT variant, an HE variant, an EHT variant, or a variant of the EHT standard. The examples described herein as applying to the HE variant may also apply identically to variants defined in the HE standard. The HT Control field may also include signaling to indicate which variant the HT Control field is. For example, some bits of the HT Control field can indicate which variant the HT Control field is. For example, if the value of the first bit (B0) is 0, the HT Control field may be an HT variant. Furthermore, if the value of the first bit (B0) is 1, the HT Control field may be a VHT variant, an HE variant, or an EHT variant. Also, if the value of the first bit (B0) is 1 and the value of the second bit (B1) is 0, the HT Control field may be a VHT variant. Also, if the value of the first bit (B0) is 1 and the value of the second bit (B1) is 1, the HT Control field may be an HE variant or an EHT variant. Or, if the value of the first bit (B0) is 1 and the value of the second bit (B1) is 1, the HT Control field may be an HE variant, an EHT variant, or a variant of the EHT standard or later.

[0474] If the HT Control field is an HE variant, an EHT variant, or a standard variant after EHT, the HT Control field may include an A-Control subfield. The A-Control subfield contains one or more control information. For example, bits 3 (B2) to 32 (B31) of the HT Control field may be the A-Control subfield.

[0475] Figure 37(c) shows the format of the A-Control subfield. In Figure 37(c), the A-Control subfield includes a Control List subfield and a Padding subfield. The Control List subfield may contain one or more control information. The Control List subfield may also contain one or more Control subfields. The A-Control field may selectively include a Padding subfield. For example, the l...

Claims

1. A station in a wireless communication system, Transceiver unit, and Includes a processor that controls the aforementioned transmitting and receiving unit, The aforementioned processor, Receiving a trigger frame from an Access Point (AP), wherein the trigger frame allocates a portion of the transmission opportunity (TXOP) acquired by the AP to the station as a shared TXOP. Sending a CTS frame as a response to the aforementioned trigger frame, Sending a non-TB (Trigger-Based) PPDU (Physical Layer Protocol Data Unit) within the aforementioned shared TXOP, When a QoS (quality of service) data frame is successfully transmitted to the AP within the shared TXOP, the first EDCA (enhanced distributed channel access) parameter set used for channel access is switched to the second EDCA parameter set. Performing the channel access according to the second EDCA parameter set, It is configured to perform, The second EDCA parameter set is used in place of the first EDCA parameter set, based on whether the UL MU (multiuser) transmission was successfully performed. Station.

2. The station according to claim 1, wherein the processor is configured to switch the first EDCA parameter set to the second EDCA parameter set when the station transmits a QoS data frame requesting an immediate response to the AP via the non-TB PPDU and receives a response to the QoS data frame requesting an immediate response within the shared TXOP.

3. The station according to claim 1, wherein the processor is configured to switch the first EDCA parameter set to the second EDCA parameter set when the station transmits the non-TB PPDU containing a QoS data frame that does not request an immediate response from the AP within the shared TXOP.

4. The station according to claim 1, wherein the timer value for residual duration applied to the second EDCA parameter set is set to a value greater than 0 when the QoS data frame is successfully transmitted to the AP.

5. The station according to claim 4, wherein the processor is configured not to set the timer value to 0 even if the station successfully transmits a signal to the AP that deactivates the UL MU transmission operation within the shared TXOP.

6. The station according to claim 4, wherein the processor is configured to set the timer value to 0 when the station successfully transmits a signaling to the AP that deactivates the shared TXOP operation.

7. The station according to claim 1, wherein if the residual duration of the shared TXOP is shorter than the point coordination function (PCF) interframe space (PIFS), the AP's transmissions are not permitted except for one or more predetermined transmissions, which are performed by the AP after a short interframe space (SIFS) from the end of the transmission of the last PPDU transmitted from the station within the shared TXOP, and the last PPDU does not require an immediate response.

8. A method for operating a station in a wireless communication system, The steps include: receiving a trigger frame from an Access Point (AP) to trigger an uplink transmission, wherein the trigger frame allocates a portion of the transmission opportunities (TXOPs) acquired by the AP to the station as a shared TXOP; The steps include transmitting a CTS frame as a response to the trigger frame, The steps include sending a non-TB (Trigger-Based) PPDU (Physical Layer Protocol Data Unit) within the shared TXOP, When a QoS (quality of service) data frame is successfully transmitted to the AP within the shared TXOP, the first EDCA (enhanced distributed channel access) parameter set used for channel access is switched to the second EDCA parameter set. The steps include: performing the channel access according to the second EDCA parameter set; Includes, The second EDCA parameter set is used in place of the first EDCA parameter set, based on whether the UL MU (multiuser) transmission was successfully performed. method.

9. The method according to claim 8, wherein the step of switching the first EDCA parameter set to the second EDCA parameter set when the station successfully transmits the QoS data frame to the AP within the shared TXOP includes the step of switching the first EDCA parameter set to the second EDCA parameter set when the station transmits a QoS data frame requesting an immediate response via the non-TB PPDU to the AP and receives a response to the QoS data frame requesting an immediate response within the shared TXOP.

10. The method according to claim 8, wherein the step of switching the first EDCA parameter set to the second EDCA parameter set when the station successfully transmits the QoS data frame to the AP within the shared TXOP includes the step of switching the first EDCA parameter set to the second EDCA parameter set when the station transmits the non-TB PPDU, which includes a QoS data frame that does not require an immediate response, to the AP within the shared TXOP.

11. The method according to claim 9, wherein the step of switching the first EDCA parameter set to the second EDCA parameter set includes setting a timer value for residual duration applied to the second EDCA parameter set to a value greater than 0 when the QoS data frame is successfully transmitted to the AP.

12. The method according to claim 11, further comprising the step of not setting the timer value to 0 even if the station successfully transmits a signaling to the AP within the shared TXOP to deactivate the UL MU transmission operation.

13. The method according to claim 11, further comprising the step of setting the timer value to 0 when the station successfully transmits a signaling to the AP for deactivating the shared TXOP operation.

14. The method according to claim 8, wherein if the residual duration of the shared TXOP is shorter than the point coordination function (PCF) interframe space (PIFS), the AP's transmissions are not permitted except for one or more predetermined transmissions, which are performed by the AP after the short interframe space (SIFS) from the end of the transmission of the last PPDU transmitted from the station within the shared TXOP, and the last PPDU does not require an immediate response.

Images