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

Abstract

To provide a wireless communication method using shared TXOP, and a wireless communication terminal using the same.SOLUTION: A station in a wireless communication system is disclosed. The station includes a transceiver and a processor for controlling the transceiver. The processor receives a trigger frame for triggering uplink transmission from an access point (AP), and the trigger frame allocates, to the station, a part of a transmission opportunity (TXOP) acquired by the AP, as a shared TXOP, transmits a CTS frame as a response to the trigger frame, and switches a first enhanced distributed channel access (EDCA) parameter set used for channel access to a second EDCA parameter set based on transmission for the AP within the shared TXOP.SELECTED DRAWING: Figure 33

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 technology]

[0002] Recently, as the popularity of mobile devices has increased, wireless LAN technology, which can provide them with high-speed wireless Internet services, has been gaining attention. Wireless LAN technology is a technology that uses short-range wireless communication technology to enable mobile devices such as smartphones, smart pads, laptop PCs, portable multimedia players, embedded devices, etc. to connect to the Internet wirelessly at home, in business, or in specific service areas.

[0003] Since supporting early wireless LAN technology using the 2.4 GHz frequency band, IEEE (Institute of Electronics Engineers) 802.11 has since implemented or is developing standards for a variety of technologies. First, IEEE 802.11b uses the 2.4 GHz frequency band and supports communication speeds of up to 11 Mbps. IEEE 802.11a, which was commercialized after IEEE 802.11b, uses the 5 GHz frequency band instead of the 2.4 GHz band, reducing the impact of interference compared to the significantly more congested 2.4 GHz frequency band, and uses OFDM technology to increase communication speeds to up to 54 Mbps. However, IEEE 802.11a has the disadvantage of a shorter communication distance than IEEE 802.11b. IEEE 802.11g has attracted considerable attention because it uses the same 2.4GHz band as IEEE 802.11b, achieving a maximum communication speed of 54Mbps and satisfying backward compatibility, but it also has an advantage over IEEE 802.11a in terms of communication distance.

[0004] IEEE 802.11n is a technical standard established to overcome the communication speed limitations that have been identified as a weakness of wireless LANs. IEEE 802.11n aims to increase network speed and reliability and extend the operating distance of wireless networks. Specifically, IEEE 802.11n supports high throughput (HT) of up to 540 Mbps and is based on MIMO (Multiple Inputs and Multiple Outputs) technology, which uses multiple antennas on both the transmitting and receiving ends to minimize transmission errors and optimize data speed. This standard also uses a coding method that transmits multiple duplicate copies to increase data reliability.

[0005] As WLAN adoption continues to grow and applications become more diverse, the need for new WLAN systems is emerging to support data throughput rates (Very High Throughput, VHT) higher than those supported by IEEE 802.11n. Among these, IEEE 802.11ac supports wide bandwidth (80MHz-160MHz) in the 5GHz frequency band. While the IEEE 802.11ac standard is defined only in the 5GHz band, initial 802.11ac chipsets are expected to support operation in the 2.4GHz band as well for backward compatibility with existing 2.4GHz products. Theoretically, this standard enables multi-station WLAN speeds of at least 1Gbps and maximum single-link speeds of at least 500Mbps. This is achieved by expanding the air interface concepts adopted in 802.11n, including wider radio frequency bandwidth (up to 160MHz), more MIMO spatial streams (up to 8), multi-user MIMO, and denser modulation (up to 256QAM). IEEE 802.11ad is a method of transmitting data using the 60GHz band instead of the conventional 24GHz / 5GHz band. IEEE 802.11ad is a transmission standard that uses beamforming technology to provide speeds of up to 7Gbps, making it suitable for streaming large amounts of data and high-bitrate videos such as uncompressed HD video. However, the 60GHz frequency band has the disadvantage of being difficult to pass through obstacles and can only be used between devices in close proximity.

[0006] Meanwhile, the IEEE 802.11ax (High Efficiency WLAN, HEW) standard is being developed and is nearing completion as the successor to 802.11ac and 802.11ad in order to provide high-efficiency and high-performance WLAN communication technology in high-density environments where APs and terminals are densely packed. In an 802.11ax-based WLAN environment, high-frequency-efficient communication must be provided both indoors and outdoors in the presence of a high density of stations and APs (Access Points), and various technologies are being developed to achieve this.

[0007] Additionally, new WLAN standards have begun to be developed to increase maximum transmission speeds in order to support new multimedia applications such as high-definition video and real-time gaming. IEEE 802.11be (Extremely High Throughput, EHT), the seventh generation WLAN standard, is currently being developed with the goal of supporting transmission rates of up to 30Gbps in the 2.4 / 5 / 6GHz bands through wider bandwidth, increased spatial streams, and multi-AP cooperation. Summary of the Invention [Problem to be solved by the invention]

[0008] An object of one embodiment of the present invention is 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 in a wireless communication system according to an embodiment of the present invention includes a transceiver unit and a processor controlling the transceiver unit, the processor receiving a trigger frame from an access point (AP) to trigger uplink transmission, the trigger frame allocating a portion of a transmission opportunity (TXOP) acquired by the AP to the station as a shared TXOP, transmitting a CTS frame in response to the trigger frame, and switching a first enhanced distributed channel access (EDCA) parameter set used for channel access to a second EDCA parameter set based on the transmission to the AP in the shared TXOP.

[0010] The processor may switch the first EDCA parameter set to the second EDCA parameter set when a quality of service (QoS) 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 sharing station transmits a QoS data frame requesting an immediate response to the AP within a TXOP and receives a response to the QoS data frame requesting an immediate response.

[0012] The processor may switch from the first EDCA parameter set to the second EDCA parameter set when the station transmits a QoS data frame in the shared TXOP that does not require an immediate response from the AP.

[0013] The second EDCA parameter set may be used instead of the first EDCA parameter set based on whether an UL multiuser (MU) transmission is successful.

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

[0015] The processor may not set the timer value to 0 even if the station successfully sends signaling to the AP to deactivate UL MU transmission operation in the shared TXOP.

[0016] The processor may set the value of the timer to 0 if the station successfully sends signaling to the AP to deactivate the shared TXOP operation.

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

[0018] The step of switching a first EDCA parameter set used for the channel access to a 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 quality of service (QoS) 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 has successfully transmitted a QoS data frame to the AP within the shared TXOP may include the step of transmitting a QoS data frame requesting an immediate response to the AP within the shared TXOP by the station, and switching the first EDCA parameter set to the second EDCA parameter set when the station has received 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 within the shared TXOP to the AP that does not require an immediate response.

[0021] The second EDCA parameter set may be used instead of the first EDCA parameter set based on whether an UL multiuser (MU) transmission is successful.

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

[0023] The step of setting the value of the timer for the remaining duration to which the second EDCA parameter set is applied to a value greater than 0 may include a step of not setting the value of the timer to 0 even if the station successfully transmits signaling to the AP in the shared TXOP to deactivate UL MU transmission operation.

[0024] The step of setting the value of the timer for the remaining duration to which the second EDCA parameter set is applied to a value greater than 0 may include the step of setting the value of the timer to 0 if the station successfully sends signaling to the AP to deactivate the shared TXOP operation. [Effects of the Invention]

[0025] An embodiment of the present invention provides a wireless communication method for efficiently using a shared TXOP and a wireless communication terminal using the same. [Brief explanation of the drawings]

[0026] [Figure 1] 1 is a diagram illustrating a wireless LAN system according to an embodiment of the present invention. [Figure 2] FIG. 10 is a diagram showing a wireless LAN system according to another embodiment of the present invention. [Figure 3] FIG. 2 is a diagram showing the configuration of a station according to an embodiment of the present invention. [Figure 4] FIG. 2 is a diagram illustrating a configuration of an access point according to an embodiment of the present invention. [Figure 5] 1 is a diagram illustrating a process in which a STA establishes a link with an AP. [Figure 6] FIG. 1 is a diagram illustrating a CSMA (Carrier Sense Multiple Access) / CA (Collision Avoidance) method used in wireless LAN communication. [Figure 7] 1 shows examples of various standard generation PPDU (PLCP Protocol Data Unit) formats. [Figure 8] 1 illustrates an example of various Extremely High Throughput (EHT) Physical Protocol Data Unit (PPDU) formats and methods for indicating the same, according to an embodiment of the present invention. [Figure 9] 1 shows a multi-link device according to an embodiment of the present invention; [Figure 10] 1 illustrates a multi-link mapped by a TID-to-link mapping method according to an embodiment of the present invention. [Figure 11] FIG. 10 is a diagram illustrating an example of a multi-link NAV setting operation according to one embodiment of the present invention. [Figure 12] FIG. 10 is a diagram illustrating yet another example of a multi-link NAV setting operation according to one embodiment of the present invention. [Figure 13] FIG. 1 is a diagram illustrating an example of BSS classification and operations based thereon according to an embodiment of the present invention. [Figure 14]FIG. 2 is a diagram illustrating a wireless LAN function according to an embodiment of the present invention. [Figure 15] FIG. 2 is a diagram illustrating an uplink (UL) multi-user (MU) operation according to one embodiment of the present invention. [Figure 16] FIG. 1 is a diagram illustrating a trigger frame format according to one embodiment of the present invention. [Figure 17] A diagram showing a method for indicating a trigger-based PPDU format according to one embodiment of the present invention. [Figure 18] FIG. 10 is a diagram illustrating an example of UL MU operation according to one embodiment of the present invention. [Figure 19] A diagram showing a method for sharing a TXOP according to one embodiment of the present invention. [Figure 20] A diagram illustrating a method related to TXOP sharing and NAV setting in one embodiment of the present invention. [Figure 21] A diagram showing TXOP sharing and CTS frame transmission in one embodiment of the present invention. [Figure 22] A figure showing an example of a trigger frame for sharing a TXOP in one embodiment of the present invention. [Figure 23] FIG. 10 is a diagram illustrating a NAV time out according to one embodiment of the present invention. [Figure 24] A diagram illustrating TXOP sharing and NAV timeout in one embodiment of the present invention. [Figure 25] A diagram showing TXOP sharing and NAV timeout in yet another embodiment of the present invention. [Figure 26] A diagram showing TXOP sharing and NAV timeout in yet another embodiment of the present invention. [Figure 27] A diagram showing that STA and AP apply NAV when TXOP sharing is applied according to one embodiment of the present invention. [Figure 28] A diagram showing a STA ending TXOP sharing according to one embodiment of the present invention. [Figure 29]10 is a diagram illustrating a method for signaling the format of a TB PPDU responding to a trigger frame using a Common Info field and a Special User Info field included in the trigger frame according to an embodiment of the present invention. [Figure 30] 10 is a diagram illustrating a method for setting a TXVECTOR parameter when a station according to an embodiment of the present invention transmits a frame in response to a modified MU-RTS frame. [Figure 31] 10A and 10B are diagrams illustrating the configuration of a management frame and an MU EDCA Parameter Set element according to an embodiment of the present invention. [Figure 32] A method for a station allocated a shared TXOP to configure an MU EDCA parameter set according to an embodiment of the present invention will now be described. [Figure 33] FIG. 10 is a diagram illustrating the operation of a station recovering a TXOP after allocating a shared TXOP according to an embodiment of the present invention. [Figure 34] FIG. 10 illustrates a shared TXOP allocator performing TXOP recovery after the end of a shared TXOP according to an embodiment of the present invention. [Figure 35] FIG. 10 illustrates a shared TXOP allocator performing TXOP recovery after the end of a shared TXOP according to yet another embodiment of the present invention. [Figure 36] FIG. 10 illustrates a shared TXOP allocator performing TXOP recovery after the end of a shared TXOP according to yet another embodiment of the present invention. [Figure 37] FIG. 2 is a diagram showing a frame format according to an embodiment of the present invention. [Figure 38] 10 is a diagram illustrating a method in which an AP decodes a UL MU Disable subfield and a UL MU Data Disable subfield of an OM Control field according to an embodiment of the present invention. [Figure 39]10 is a diagram illustrating a method for a station to configure an MU EDCA parameter set based on a UL MU Disable subfield and a UL MU Data subfield according to an embodiment of the present invention. [Figure 40] 10 is a diagram illustrating a method in which an AP decodes a UL MU Disable subfield and a UL MU Data Disable subfield of an OM Control field according to yet another embodiment of the present invention. [Figure 41] 10 is a diagram illustrating an operation of a station setting an MU EDCA parameter set based on a shared TXOP operation according to an embodiment of the present invention. [Figure 42] 10 is a diagram illustrating an operation of a station setting an MU EDCA parameter set based on a shared TXOP operation according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0027] The terms used in this specification are generally used as widely as possible, taking into consideration the functions of the present invention. However, these may vary depending on the intentions of engineers in the relevant technical field, customs, or the emergence of new technologies. In addition, in certain cases, the applicant has arbitrarily selected terms, and in such cases, the meanings thereof will be described in the relevant description of the invention. Therefore, it is clear that the terms used in this specification should be interpreted not simply as names of terms, but based on the substantive meanings of the terms and the overall content of this specification.

[0028] Throughout the specification, when a component is "coupled" to another component, this includes not only when it is "directly coupled" to another component, but also when it is "electrically coupled" with another component in between. Furthermore, when a component "comprises" a specific component, this means that it may further include the other component, not excluding the other component, unless otherwise specified. In addition, limitations such as "greater than" or "less than" based on a specific threshold value may be appropriately replaced with "exceed" or "less than," respectively, depending on the embodiment.

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

[0030] FIG. 1 is a diagram showing a wireless LAN system according to an embodiment of the present invention.

[0031] A wireless LAN system includes one or more Basic Service Sets (BSSs), which are a set of devices that can synchronize and 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 FIG. 1, the infrastructure BSSs BSS1 and BSS2 include one or more stations STA1, STA2, STA3, STA4, and STA5, access points AP-1 and AP-2 that are stations providing distribution services, and a distribution system DS that connects multiple access points AP-1 and AP-2.

[0033] A station (STA) is any device that includes a medium access control (MAC) and a physical layer interface for a wireless medium in accordance with the IEEE 802.11 standard. In a broad sense, the term "station" encompasses not only non-AP stations but also APs. In this specification, the term "terminal" refers to either a non-AP or an AP, or both. A station for wireless communication includes a processor and a communication unit, and, depending on the embodiment, may further include a user interface unit and a display unit. The processor generates frames to be transmitted over a wireless network, processes frames received over the wireless network, and performs various other processes for controlling the station. The communication unit is functionally connected to the processor and transmits and receives frames over the wireless network for the station. In this specification, the term "terminal" encompasses user equipment (UE).

[0034] An access point (AP) is an entity that provides a connection to a distribution system (DS) via a wireless medium for associated stations. In an infrastructure BSS, communication between non-AP stations is generally performed via the AP. However, if a direct link is established, direct communication is also possible between non-AP stations. Meanwhile, in the present invention, the term AP is used as a concept including a personal BSS coordination point (PCP), but in a broader sense, it also includes concepts such as a central controller, a base station (BS), a node B, a base transceiver system (BTS), or a site controller. In the present invention, an AP is also referred to as a base wireless communication terminal, but in a broader sense, the term base wireless communication terminal is used as a term including an AP, a base station, an eNodeB (eNB), and a transmission point (TP). In addition, the base wireless communication terminal includes various types of wireless communication terminals that allocate communication medium resources and perform scheduling for communication with multiple wireless communication terminals.

[0035] A plurality of infrastructure BSSs are connected to each other via a distribution system DS, and the plurality of BSSs connected via the distribution system are called an Extended Service Set (ESS).

[0036] 2 is a diagram showing an independent BSS, which is a wireless LAN system according to another embodiment of the present invention. In the embodiment of FIG. 2, the same or corresponding parts as those in the embodiment of FIG. 1 will not be described again.

[0037] BSS3 shown in Figure 2 is an independent BSS and does not include an AP, so none of the stations (STA6, STA7) are connected to an AP. 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 each other.

[0038] 3 is a block diagram showing the configuration of a station 100 according to an 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 WLAN packets and may be incorporated into or external to the station 100. According to an embodiment, the communication unit 120 may include at least one communication module using different frequency bands. For example, the communication unit 120 may include communication modules for different frequency bands, such as 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz. According to an embodiment, the station 100 may include a communication module using a frequency band above 7.125 GHz and a communication module using a frequency band below 7.125 GHz. Each communication module may perform wireless communication with an AP or an external station based on the WLAN standard of the frequency band supported by the communication module. The communication unit 120 may operate only one communication module at a time or multiple communication modules simultaneously, depending on the performance and requirements of the station 100. When the station 100 includes multiple communication modules, each communication module may be provided independently, or multiple modules may be integrated into a single chip. In the embodiment of the present invention, the communication unit 120 may represent a radio frequency (RF) communication module that processes RF signals.

[0040] Next, the user interface 140 includes various types of input / output means provided in the station 100. That is, 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. Also, the user interface unit 140 performs output based on instructions from the processor 110 using various output means.

[0041] The display unit 150 then outputs an image on a display screen. The display unit 150 outputs various display objects, such as a user interface, based on the contents or control commands of the processor 110. The memory 160 also stores control programs and various data used by the station 100. The control programs include a connection program required for the station 100 to connect to an AP or an external station.

[0042] The processor 110 of the present invention executes various commands or programs to process 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 the units. According to an embodiment of the present invention, the processor 110 executes a program for connection with an AP stored in the memory 160 and receives a communication setup message transmitted by the AP. The processor 110 also reads information about the station 100's priorities contained in the communication setup message and requests connection to the AP based on the information about the station 100's priorities. The processor 110 of the present invention may refer to a main control unit of the station 100, or, depending on the embodiment, may refer to a control unit for individually controlling some components of the station 100, such as the communication unit 120. That is, the processor 110 may be a modem or a modulator and / or demodulator that modulates and demodulates wireless signals transmitted and received by the communication unit 120. The processor 110 controls various operations for transmitting and receiving wireless signals in 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 FIG. 3 is a block diagram according to an embodiment of the present invention, and the separate blocks indicate the logically separated elements of the device. Therefore, the above-described device elements may be mounted on a single chip or multiple chips depending on the device design. For example, the processor 110 and the communication unit 120 may be integrated into a single chip or may be mounted on separate chips. Furthermore, in embodiments 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] 4 is a block diagram showing the configuration of an AP 200 according to an embodiment of the present invention. As shown, the AP 200 according to the embodiment of the present invention includes a processor 210, a communication unit 220, and a memory 260. In FIG. 4, duplicated descriptions of parts of the configuration of the AP 200 that are the same as or correspond to the configuration of the station 100 in FIG. 3 will be omitted.

[0045] Referring to FIG. 4, the AP 200 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 FIG. 3, the communication unit 220 of the AP 200 may also include multiple communication modules using different frequency bands. That is, the AP 200 according to the 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 AP 200 may include a communication module using a frequency band above 7.125 GHz and a communication module using a frequency band below 7.125 GHz. Each communication module can wirelessly communicate with a station based on the WLAN standard of the frequency band supported by the communication module. The communication unit 220 may operate only one communication module at a time or multiple communication modules simultaneously, depending on the performance and requirements of the AP 200. In the embodiment of the present invention, the communication unit 220 may represent an RF (Radio Frequency) communication module that processes RF signals.

[0046] The memory 260 stores control programs used by the AP 200 and various data associated therewith. These control programs include a connection program that manages station connections. The processor 210 also controls each unit of the AP 200 and controls data transmission and reception between the units. According to an embodiment of the present invention, the processor 210 executes a program for connecting with a station stored in the memory 260 and transmits a communication setup message to one or more stations. The communication setup message includes information regarding connection preferences for each station. The processor 210 also performs connection setup in response to a station connection request. According to an embodiment, the processor 210 is a modem or a modulation / demodulation unit that modulates and demodulates wireless signals transmitted and received by the communication unit 220. The processor 210 controls various operations for transmitting and receiving wireless signals by the AP 200 according to an embodiment of the present invention. A detailed embodiment of this will be described later.

[0047] FIG. 5 is a diagram illustrating a process in which a STA establishes a link with an AP.

[0048] 5, a link between the STA 100 and the AP 200 is established through three steps: scanning, authentication, and association. First, the scanning step is a step in which the STA 100 acquires connection information for a BSS operated by the AP 200. There are two scanning methods: a passive scanning method in which the STA 100 acquires information using only a beacon message S101 periodically transmitted by the AP 200, and an active scanning method in which the STA 100 transmits a probe request to the AP S103, receives a probe response from the AP S105, and acquires connection information.

[0049] The STA 100 that successfully receives wireless connection information in the scanning step transmits an authentication request (S107a), receives an authentication response from the AP 200, and performs the authentication step (S107b). After the authentication step is performed, the STA 100 transmits an association request (S109a), receives an association response from the AP 200, and performs the association step (S109b). In this specification, association basically means wireless association, but the present invention is not limited to this, and association in a broad sense includes both wireless association and wired association.

[0050] Meanwhile, an 802.1X-based authentication step S111 and an IP address acquisition step S113 via DHCP are additionally performed. In Fig. 5, server 300 is a server that processes 802.1X-based authentication with STA 100, and may be physically connected to AP 200 or may exist as a separate server.

[0051] FIG. 6 is a diagram showing a CSMA (Carrier Sense Multiple Access) / CA (Collision Avoidance) method used in wireless LAN communication.

[0052] A terminal performing WLAN communication performs carrier sensing to check whether a channel is occupied before transmitting data. If a wireless signal above a certain strength is detected, the channel is determined to be occupied, and the terminal delays access to the channel. This process is called Clear Channel Assessment (CCA), and the level that determines whether or not the signal is detected is called the CCA threshold. If a wireless signal above the CCA threshold received by a terminal is designated as the receiver, the terminal processes the received wireless signal. On the other hand, if no wireless signal is detected from the channel or a wireless signal with a strength below the CCA threshold is detected, the channel is determined to be idle.

[0053] If the channel is determined to be idle, each terminal having data to transmit performs a backoff procedure after an Inter Frame Space (IFS), such as an Arbitration IFS (AIFS) or a PCF IFS (PIFS), depending on the status of each terminal. In some embodiments, the AIFS is used as a configuration replacing the conventional DCF IFS (DIFS). Each terminal waits while decrementing a slot time equal to a random number determined for the terminal during the idle interval of the channel, and a terminal that has exhausted all of its slot time attempts to access the channel. The period during which each terminal performs the backoff procedure is called a contention window period. In this case, the random number can be called a backoff counter. That is, the initial value of the backoff counter is set by an integer, which is a random number obtained by the terminal. If the terminal detects that the channel is idle during the slot time, the terminal can decrement the backoff counter by 1. If the backoff counter reaches 0, the terminal may be allowed to perform channel access on the channel. Therefore, if the channel is idle during the AIFS time and the backoff counter slot time, the terminal may be allowed to transmit.

[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 assigned new random numbers and perform a backoff procedure again. According to one embodiment, the new random numbers assigned to each terminal are determined within a range (2*CW) twice the range of the random numbers previously assigned to the terminal (contention window, CW). Meanwhile, each terminal attempts access by performing a backoff procedure again in the next contention window period. At this time, each terminal performs the backoff procedure from the slot time remaining in the previous contention window period. In this way, terminals communicating via a wireless LAN can avoid collisions with each other on a specific channel.

[0055] <Examples of various PPDU formats> Figure 7 shows examples of various standard generation 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. Also, Figure 7(d) shows detailed field configurations of L-SIG and RL-SIG commonly used in the PPDU formats.

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

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

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

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

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

[0061] The unit of the L_LENGTH field is byte, and a total of 12 bits are allocated, allowing signaling up to 4095. In combination with the L_RATE field, the length of the PPDU can be indicated. In this case, legacy and non-legacy terminals can interpret the L_LENGTH field in different ways.

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

[0063]

number

[0064] At this time,

number

[0065]

number

[0066] Here, TXTIME is the total transmission time constituting the PPDU, and is expressed as the following equation 3. 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 ​​of 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 remains in the EHT PPDU and subsequent generation WLAN PPDUs, and serves to distinguish which generation of PPDU it is, including 11be. The U-SIG is two 64FFT-based OFDM symbols and can transmit a total of 52 bits of information. Of these, 43 bits excluding 9 bits of CRC / tail are roughly divided into a VI (Version Independent) field and a VD (Version Dependent) field.

[0070] The VI bit will maintain its current bit configuration, so even if a subsequent generation PPDU is defined, current 11be UEs can obtain information about the PPDU from the VI field of the PPDU. 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 long and serves to sequentially distinguish between 11be and subsequent generations of WLAN standards. 11be has a value of 000b. The UL / DL field identifies whether the PPDU is an uplink or downlink PPDU. The BSS color represents a BSS identifier defined in 11ax and has a value of 6 or more bits. The TXOP represents the transmit opportunity duration (Transmit Opportunity Duration) transmitted in the MAC header. By adding it to the PHY header, the length of the TXOP containing the PPDU can be inferred without decoding the MPDU, and has a value of 7 or more bits.

[0071] The VD field, which is signaling information useful only for 11be version PPDUs, may consist of fields commonly used in any PPDU format, such as the PPDU format and BW, as well as fields defined differently for each PPDU format. The PPDU format is a separator that distinguishes between EHT SU (Single User), EHT MU (Multiple User), EHT TB (Trigger-based), and EHT ER (Extended Range) PPDUs. The BW field broadly signals five basic PPDU BW options: 20, 40, 80, 160 (80 + 80), and 320 (160 + 160) MHz (BWs that can be expressed in the form of a power of 20 * 2 can be called basic BWs), as well as various remaining PPDU BWs formed by preamble puncturing. After signaling at 320 MHz, a portion of 80 MHz may be punctured. In addition, the punctured and modified channel shape may be signaled directly in the BW field, or may be signaled using both the BW field and a field that appears after the BW field (for example, a field in 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] The fields located after the BW field vary depending on the type and format of the PPDU. MU PPDUs and SU PPDUs may be signaled in the same PPDU format, and a field for distinguishing 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 an EHT-SIG field, but some fields not required in the SU PPDU may be compressed. In this case, the information of the compressed field may be omitted or may have a reduced size compared to the size of the original field included in the MU PPDU. For example, the SU PPDU may have a different configuration, such as the common field of the EHT-SIG being omitted or replaced, or the user-specific field being replaced or reduced to one.

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

[0074] When a portion of the EHT-SIG field of the SU PPDU is compressed, the information included in the compressed field may be signaled together in an 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 recognize the location of the RU to which the MU PPDU is transmitted, the STA to which each RU is assigned, and whether the transmitted MU PPDU was sent to it. Therefore, the AP must transmit the above information in the EHT-SIG field. To this end, the U-SIG field signals information for efficiently transmitting the EHT-SIG field, which may be the number of symbols in the EHT-SIG field and / or the MCS, which is the modulation method. The EHT-SIG field may include information on the size and location of the RU assigned to each user.

[0075] In the case of an SU PPDU, a STA may be assigned multiple RUs, and the multiple RUs may be contiguous or discontinuous. If the RUs assigned to the STA are not contiguous, the STA can efficiently receive the SU PPDU only by recognizing the punctured RUs in between. Therefore, the AP can transmit the SU PPDU including information on 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, a puncturing mode field including information indicating whether a puncturing mode is applied and the puncturing pattern in a bitmap format, etc., may be included in the EHT-SIG field, and the puncturing mode field can signal the type of discontinuous channels appearing within the bandwidth.

[0076] The type of signaled discontinuous channel is limited, and indicates the BW and discontinuous channel information of the SU PPDU in combination with the value of the BW field. For example, since the SU PPDU is a PPDU transmitted only to a single UE, the STA can recognize its allocated bandwidth from the BW field included in the PPDU and can recognize 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 UE can receive the PPDU in the remaining resource units other than the specific channel of the punctured resource units. In this case, multiple RUs allocated to the STA may be configured with different frequency bands or tones.

[0077] The reason why only limited discontinuous channel types are signaled is to reduce the signaling overhead of the SU PPDU. Since puncturing can be performed for each 20 MHz subchannel, if puncturing is performed on a BW having multiple 20 MHz subchannels, such as 80, 160, and 320 MHz, in the case of 320 MHz, the discontinuous channel type (when only the end 20 MHz is punctured and considered discontinuous) must be signaled by expressing whether or not the remaining 15 20 MHz subchannels other than the primary channel are used. Using 15 bits to signal the discontinuous channel type for single-user transmission can result in excessive signaling overhead when considering the low transmission rate of the signaling part.

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

[0079] In addition, one embodiment of the present invention proposes a method of varying the PPDU configuration indicated by the preamble puncturing BW value depending on the PPDU format signaled in the PPDU format field. Assuming that the BW field is 4 bits, in the case of an EHT SU PPDU or TB PPDU, an EHT-SIG-A symbol can be further signaled after the U-SIG, or no EHT-SIG-A can be signaled at all. Taking this into consideration, up to 11 puncturing modes must be fully signaled using only the BW field of the U-SIG. However, in the case of an EHT MU PPDU, an EHT-SIG-B symbol is further signaled after the U-SIG, so up to 11 puncturing modes can be signaled in a different manner than in the case of 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 20 MHz or 10 MHz bandwidth. Detailed puncturing patterns for each PPDU type will be described in detail below with reference to FIGS. 11 and 12.

[0080] Figure 7(f) shows the format-specific field configuration of the VD field when the PPDU format field of the U-SIG indicates an EHT MU PPDU. For an MU PPDU, SIG-B, a signaling field for simultaneous reception by multiple users, is required. SIG-B may be transmitted after the U-SIG without a separate SIG-A. For this purpose, the U-SIG must signal information for decoding SIG-B. These fields include the SIG-B MCS, SIG-B DCM, number of SIG-B symbols, SIG-B compression, and number of EHT-LTF symbols.

[0081] FIG. 8 illustrates an example of various Extremely High Throughput (EHT) Physical Protocol Data Unit (PPDU) formats and methods for indicating the same according to an embodiment of the present invention.

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

[0083] 8(a) shows an example of an 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 an EHT-SIG-A field for additional signaling may be located after the U-SIG field.

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

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

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

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

[0088] Specifically, the resource unit allocation (RA) field of the HE-SIG-B field included in the HE MU PPDU may include information regarding the configuration of resource units (e.g., the division form of resource units) in a specific bandwidth (e.g., 20 MHz) on the frequency axis. That is, the RA field may indicate the configuration of resource units divided by the bandwidth for transmitting the HE MU PPDU so that the STA can receive the PPDU. Information about the STA allocated (or designated) to each divided resource unit may be included in a user specific field of the EHT-SIG-B and transmitted to the STA. That is, the user specific field may include 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 include the AID of the receiver or sender, and the user field corresponding to the remaining resource units not used for data transmission may include a null STA ID that has already been set.

[0090] For ease of explanation, the term 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 improved. 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, when the frequency band of one link is being used by another wireless communication device, the wireless communication device can continue communication using another link. In this way, the wireless communication device can effectively use multiple channels. Furthermore, when a wireless communication device simultaneously communicates using multiple links, the overall throughput can be improved. However, existing wireless LANs are specified on the assumption that one wireless communication device uses one link. Therefore, a wireless LAN operation method for using multiple links is required. A wireless communication method for a wireless communication device using multiple links will be described with reference to FIGS. 9 to 26. First, a specific embodiment of a wireless communication device using multiple links will be described with reference to FIG. 9.

[0092] FIG. 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 multiple links described above. The multi-link device may represent a device having one or more affiliated stations. Depending on a specific embodiment, the multi-link device may represent a device having two or more affiliated stations. The multi-link device may also exchange multi-link elements. The multi-link element includes information about one or more stations or one or more links. The multi-link element may include a multi-link setup element, which will be described later. In this case, the multi-link device may be a logical entity. Specifically, the multi-link device may have multiple affiliated stations. The multi-link device may be referred to as a multi-link logical entity (MLLE) or a multi-link entity (MLE). The multi-link device may have one medium access control service access point (SAP) up to a logical link control (LLC). The MLD may also have one MAC data service.

[0094] Multiple stations included in a multilink device can operate on multiple links. Also, multiple stations included in a multilink device can operate on multiple channels. Specifically, multiple stations included in a multilink device can operate on different links or different channels. For example, multiple stations included in a multilink device can operate on different channels, such as 2.4 GHz, 5 GHz, and 6 GHz.

[0095] The operation of the multilink device can be referred to as multilink operation, MLD operation, or multi-band operation. If the station associated with the multilink device is an AP, the multilink device can be referred to as AP MLD. If the station associated with the multilink device is a non-AP station, the multilink device can be referred to as non-AP MLD.

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

[0097] The multilink operation may include a multilink setup operation. The multilink setup corresponds to the association operation of the single-link operation described above and must be preceded by a frame exchange in the multilink. The multilink device can obtain information required for the multilink setup from the multi-link setup element. Specifically, the multi-link setup element may include capability information related to the 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 at the same time. The capability information may also include information about links available to each station included in the MLD. The capability information may also include information about channels available to each station included in the MLD.

[0098] Multilink configuration may be established through negotiation between peer stations. Specifically, multilink configuration may be established through communication between stations without communication with an AP. Multilink configuration may also be established through any one of the links. For example, even if the first to third links are established through multilink, multilink configuration may be established through the first link.

[0099] In addition, a mapping between a traffic identifier (TID) and a link may be configured. Specifically, frames corresponding to a specific TID value may be exchanged only through a pre-specified link. The mapping between a TID and a link may be configured on a directional basis. For example, when multiple links are configured between a first multilink device and a second multilink device, the first multilink device may be configured to transmit frames of the first TID to the multiple first links, and the second multilink device may be configured to transmit frames of the second TID to the first links. In addition, a default setting may exist for the mapping between TIDs and links. Specifically, if no additional settings are configured in the multilink configuration, the multilink device may exchange frames corresponding to TIDs on each link according to a default setting. In this case, the default setting may be that all TIDs are exchanged on any one link.

[0100] The TID will be described in detail. The TID is an ID for classifying traffic and data to support quality of service (QoS). The TID may be used or assigned in a layer higher than the MAC layer. The TID may indicate a traffic category (TC) or a traffic stream (TS). There may be 16 distinct TIDs. For example, the TID may be designated as any one of 0 to 15. Different TID values ​​may be designated depending on an access policy, channel access, or medium access method. For example, when enhanced distributed channel access (EDCA) or hybrid coordination function contention-based channel access (HCAF) is used, the TID may be assigned a value ranging from 0 to 7. When EDCA is used, the TID may indicate a user priority (UP). In this case, the UP may be designated by the TC or the TS. The UP may be assigned in a layer higher than the MAC. Furthermore, when HCCA (HCF controlled channel access) or SPCA is used, the TID may be assigned a value in the range of 8 to 15. When HCCA or SPCA is used, the TID may indicate a TSID. Furthermore, when HEMM or SEMM is used, the TID may be assigned a value in the range of 8 to 15. When HEMM or SEMM is used, the TID may indicate a 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 ACs. ACs may include AC_BK, AC_BE, AC_VI, and AC_VO. AC_BK, AC_BE, AC_VI, and AC_VO may indicate background, best effort, video, and voice, respectively. AC_BK, AC_BE, AC_VI, and AC_VO may be classified into lower-level ACs. For example, AC_VI can be further subdivided into AC_VI primary and AC_VI alternate. AC_VO can be further subdivided into AC_VO primary and AC_VO alternate. UP or TID may be mapped to an AC. For example, 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, 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. Also, 1, 2, 0, 3, 4, 5, 6, and 7 in UP or TID may have decreasing priority in that order. That is, 1 may have a lower priority, and 7 may have a higher priority. Therefore, the order of priority may be AC_BK, AC_BE, AC_VI, and AC_VO. Also, AC_BK, AC_BE, AC_VI, and AC_VO can correspond to ACI (AC index) 0, 1, 2, and 3, respectively. Due to the characteristics of TID, the mapping between TID and link can represent the mapping between AC and link.The mapping between links and ACs can also represent the mapping between TIDs and links.

[0102] As described above, a TID may be mapped to each of multiple links. The mapping may specify the links through which traffic corresponding to a specific TID or AC can be exchanged. Furthermore, the TID or AC that can be transmitted for each transmission direction within a link may be specified. As described above, a default setting may exist for the mapping between TIDs and links. Specifically, if no additional settings are configured in the multilink configuration, the multilink device may exchange frames corresponding to the TID 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 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 the link may be transmitted on the link. Therefore, when a link is mapped to a TID or AC, frames not corresponding to a TID or AC not mapped to the link may not be transmitted on the link. When a link is mapped to a TID or AC, an 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 the TID and the link. In yet another specific embodiment, the mapping between the TID and the link may be determined based on the Block ACK agreement. Specifically, a Block ACK agreement may be set for a TID mapped to a specific link.

[0104] The above-described TID-to-link mapping may ensure QoS. Specifically, a high-priority AC or TID may be mapped to a link where a relatively small number of stations are operating or where channel conditions are good. The above-described TID-to-link mapping may also allow stations to remain in a power-saving state for a longer period of time.

[0105] FIG. 10 illustrates a multi-link mapped by a TID-to-link mapping method according to an embodiment of the present invention.

[0106] Referring to Figure 10, as described in Figure 9, there may be a mapping relationship between TIDs and links. In addition, in the present invention, the mapping relationship between TIDs and links may be referred to as TID-to-link mapping, TID to link mapping, TID mapping, link mapping, etc. The TID may be a traffic identifier. The TID may also be an ID (identifier) ​​that classifies traffic, data, etc. to support quality of service (QoS).

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

[0108] There may also be a mapping relationship between UP and access category (AC). An AC may be a label for providing QoS in EDCA or a label indicating a set of EDCA parameters. The EDCA parameters or a set of EDCA parameters may be used for channel connection. An AC may be used by a QoS STA.

[0109] The AC value may be set as one of AC_BK, AC_BE, AC_VI, and 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 further subdivided. For example, AC_VI may be further subdivided into AC_VI primary and AC_VI alternate. Furthermore, AC_VO may be further subdivided into AC_VO primary and AC_VO alternate. Furthermore, UP values ​​or TID values ​​may be mapped to AC values. For example, UP values ​​or TID values ​​of 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 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. UP or TID values ​​1, 2, 0, 3, 4, 5, 6, and 7 may have increasing priority in that order. That is, 1 may have a lower priority, and 7 may have a higher priority. Therefore, the order of priority may be AC_BK, AC_BE, AC_VI, and AC_VO. AC_BK, AC_BE, AC_VI, and AC_VO may correspond to AC indices (ACIs) 0, 1, 2, and 3, respectively.

[0110] Therefore, there may be a relationship between a TID and an AC. Therefore, the TID-to-link mapping of the present invention may be a mapping relationship between an AC and a link. Also, in the present invention, mapping a TID may mean mapping an AC, or vice versa.

[0111] According to one embodiment of the present invention, a TID may be mapped to each link of a multilink. For example, there may be a mapping of which links among multiple links a specific TID or a specific AC is allowed to transmit and receive on. Such mapping may be defined separately for each of the two directions of the link. As described above, a default setting may exist 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. According to one embodiment, at a specific time, a certain TID or a certain AC may be mapped to at least one link. Furthermore, management frames or control frames may be transmitted on all links.

[0112] In the present invention, a data frame corresponding to a TID or AC mapped to a certain direction of a link may be transmitted, and a data frame corresponding to a TID or AC not mapped to a certain direction of a link may not be transmitted.

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

[0114] By performing TID-to-link mapping, it is possible to provide QoS services. For example, by mapping a high-priority AC and TID to a link with good channel conditions or few STAs, it may be possible to transmit data of the AC and TID faster. Alternatively, by performing TID-to-link mapping, it may be possible to help STAs on a specific link save power (or enter a doze state).

[0115] 10, there may be an AP MLD including AP1 and AP2. There may also be a Non-AP MLD including STA1 and STA2. There may also be multiple links, Link1 and Link2, in the AP MLD. AP1 and STA1 may be associated via Link1, and AP2 and STA2 may be associated via Link2.

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

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

[0118] FIG. 11 is a diagram illustrating an example of a multi-link NAV setting operation according to an embodiment of the present invention.

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

[0120] Therefore, according to an embodiment of the present invention, simultaneous transmission or reception may be restricted when the spacing between links is m MHz, and simultaneous transmission or reception may not be restricted when the spacing between links is n MHz for n greater than m. This embodiment may be intended to solve the problem of simultaneous transmission or reception being restricted, and redundant description will be omitted. This embodiment can also be applied to STR-disabled MLD.

[0121] According to an embodiment of the present invention, duration information may be shared between links operating in a multi-link configuration. As an example, the duration information may be TXOP duration information transmitted in a signaling field of a 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. As another example, the duration information may be indicated by a Duration / ID field included in a MAC header. As another example, the duration information may be indicated by a Length field (L Length field) included in an L-SIG field. According to an example, 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 an example, the duration information indicated by the L-SIG field may be a value indicating the length of a physical layer protocol data unit (PPDU) including the L-SIG field or the end of the PPDU including the L-SIG field.

[0122] Furthermore, according to an embodiment of the present invention, transmission or channel access can be restricted for a period based on period information shared between links. The method of restricting transmission or channel access can include setting a NAV. Alternatively, the NAV can be reset to resume transmission or channel access. In this case, the NAV can be an intra-BSS NAV. The intra-BSS NAV can be a NAV set by an intra-BSS frame (or PPDU). That is, a STA belonging to an MLD can set its 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 STAs of multiple links belonging to an MLD when operating with multiple links. For example, transmission on link 2 may be prohibited based on the inter-link NAV set based on period information received on link 1. Furthermore, the inter-link NAV may exist or be used for an STR-disabled MLD. For example, when an inter-link NAV is set, the MLD that set the inter-link NAV may not transmit or connect channels on multiple links (or all links used by the MLD).

[0124] In addition to the intra-BSS NAV, a basic NAV may also exist as a type of NAV. The basic NAV may be a NAV set by an inter-BSS frame (or a PPDU), and the basic NAV may also be set by a frame (or a PPDU) in which it is not determined whether it is an intra-BSS or an inter-BSS frame (or a PPDU).

[0125] Using the inter-link NAV separately may have advantages over not using the inter-link NAV in situations where the NAV setting is updated. For example, situations may arise where it is acceptable to reset the NAV set by another link. For example, if the inter-link NAV is set based on a certain frame (or PPDU), but it is determined that the frame (or PPDU) is not intended for the same MLD, the set inter-link NAV may be reset. For example, if an MLD exists that operates on link 1 and link 2, the NAV for link 1 may be set based on a frame received on link 1. Then, the NAV for link 1 can be updated based on a frame from link 2. If the NAV for link 1 is reset when it is no longer necessary to maintain the NAV for link 2, the NAV information set based on the frame received on link 1 may be lost. If the inter-link NAV is used together with the NAV for each link, the NAV for each link can be maintained even if the inter-link NAV is reset, thereby solving this problem.

[0126] Although the embodiment of the present invention focuses on setting the NAV, the embodiment of the present invention is not limited to this and may also be applied to instructing the physical layer to suspend the channel connection or to instructing the channel state to be busy. Furthermore, the embodiment is not limited to resetting the NAV and may also be applied to instructing the physical layer to continue the channel connection or to instructing the channel state to be idle. In this case, a primitive exchanged between the physical layer and the MAC layer may be used. Alternatively, a primitive exchanged between one STA in the MLD and another STA may be used. Alternatively, a primitive exchanged between one MAC layer in the MLD and another MAC layer may be used.

[0127] According to an embodiment of the present invention, when a STA belonging to an MLD starts receiving a PPDU, other STAs belonging to the MLD may need to terminate their channel connection. As described above, the channel connection can be terminated based on the received duration information. However, there may be a time lag between the start of PPDU reception and the acquisition of the duration information, depending on the position of the field containing the duration information or the time required for decoding. Therefore, if a STA accesses the channel and starts transmission during this time, the above-mentioned problem may occur. Therefore, according to an embodiment of the present invention, an STA in an MLD can terminate its channel connection from the time another STA in the MLD starts receiving. Furthermore, if the other STA in the MLD starts receiving and determines that the received frame is not intended for the other STA, the STA can resume its channel connection.

[0128] FIG. 12 is a diagram illustrating yet another example of a multi-link NAV setting operation according to an embodiment of the present invention.

[0129] FIG. 12 embodies the explanation of the specific method of the embodiment explained in FIG. 11, and duplicated explanations may be omitted.

[0130] As described above, based on a frame or PPDU received by a STA belonging to the same MLD, other STAs belonging to the same MLD can suspend or resume their channel access or transmission. In the present invention, suspending channel access or transmission may include operations such as setting (updating) the NAV, determining the channel as busy, and suspending CCA. Resuming channel access or transmission may include operations such as resetting the NAV, canceling the NAV setting, determining the channel as idle, and performing CCA. Hereinafter, these operations may be referred to as suspending and resuming channel access. Hereinafter, it may be assumed that STA1 and STA2 belong to the MLD and operate on link 1 and link 2, respectively. In addition, a combination of frames and PPDUs may be used for the instruction. In this case, the NAV may be the intra-BSS NAV or the inter-link NAV, as described in FIG. 11.

[0131] According to an embodiment of the present invention, when STA1 starts receiving a frame, STA2 can suspend the channel connection. Also, when STA1 acquires duration information from the L-SIG, STA2 can maintain the suspended channel connection. In this case, STA2 can determine that the suspended channel connection will last until the end of the frame received by STA1. Also, if STA1 cannot correctly decode the L-SIG (if the L-SIG is invalid), STA2 can resume the channel connection.

[0132] STA1 may also receive the TXOP duration and BSS color from the U-SIG of the received frame. If the received BSS color indicates intra-BSS or the BSS color is the BSS color corresponding to STA1, the channel connection can be suspended. In one embodiment, the duration for suspending the channel connection may be until the end of the received frame. In this case, there is an advantage that the channel connection can be resumed sooner after the end of the received frame. In another embodiment, the duration for suspending the channel connection may be the TXOP duration. In this case, the duration of the suspended channel connection can be updated based on the L-SIG. In this case, there is an advantage that the sequence following the received frame can be better protected.

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

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

[0135] Although the case of receiving U-SIG has been described, the same embodiment can also be applied to the case of receiving HE-SIG-A when receiving HE PPDU. For example, HE-SIG-A may include TXOP duration and BSS color, which allows the same operation as described above to be performed.

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

[0137] Alternatively, STA1 may receive a STA-ID from the EHT-SIG of the received frame. 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 belongs, or if the STA-ID does not indicate broadcast, STA2 can resume the channel connection. Alternatively, STA2 can resume the channel connection even if STA1 fails to successfully decode the EHT-SIG.

[0138] Although the case of receiving EHT-SIG has been described, the same embodiment can also be applied to the case of receiving HE-SIG-B when receiving HE PPDU. For example, HE-SIG-B may include STA-ID, which allows the same operation as described above to be performed.

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

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

[0141] The channel connection suspension and resumption described in FIG. 12 can be performed sequentially in the order in which frames (or PPDUs) are decoded by starting reception of the frames (or PPDUs) at STA1 and decoding them in that order. The decoding order can be based on the PPDU format, frame format, etc. For example, the L-SIG, U-SIG, EHT-SIG, and MAC header can be decoded in this order (for EHT PPDUs). Alternatively, the L-SIG, HE-SIG-A, and MAC header can be decoded in this order (for HE SU PPDUs and HE TB PPDUs). Alternatively, the L-SIG, HE-SIG-A, HE-SIG-B, and MAC header can be decoded in this order (for HE MU PPDUs). Alternatively, the L-SIG and MAC header can be decoded in this order (for 11a / g PPDUs).

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

[0143] FIG. 13 is a diagram illustrating an example of BSS classification and operations based thereon according to an embodiment of the present invention.

[0144] According to one embodiment of the present invention, a STA can classify (or determine) a BSS based on a received frame or a received PPDU. Classifying a BSS may include an operation of classifying whether a received frame or a received PPDU corresponds to a BSS to which the classifying STA belongs. Alternatively, classifying a BSS may mean an operation of classifying whether a received frame or a received PPDU is transmitted from a BSS to which the classifying STA belongs. Classifying a BSS may also include an operation of classifying whether a received frame or a received PPDU corresponds to a BSS to which the classifying STA does not belong. Alternatively, classifying a BSS may also mean an operation of classifying whether a received frame or a received PPDU is transmitted from a BSS to which the classifying STA does not belong. Classifying a BSS may also include an operation of classifying to which BSS a received frame or a received PPDU belongs. Alternatively, classifying a BSS may mean an operation of classifying from which BSS a received frame or a received PPDU is transmitted. According to one embodiment of the present invention, a BSS to which a classification STA belongs may be referred to as an intra-BSS. Alternatively, a BSS including a BSS to which a classification STA belongs may be referred to as an intra-BSS. Furthermore, a BSS that is not an intra-BSS may be referred to as 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 a classification STA does not belong may be referred to as an inter-BSS.

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

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

[0147] The BSS classification conditions may include a condition based on BSS color. BSS color may be an identifier for a BSS. BSS color may be included in the preamble of a PPDU, more specifically, in the signaling field (e.g., the HE-SIG-A field, the U-SIG field, or the VHT-SIG-A field). BSS color may be included in the TXVECTOR transmitted from the MAC layer of the sender to the PHY layer. BSS color may be included in the RXVECTOR transmitted from the PHY layer of the receiver to the MAC layer. Parameters included in the TXVECTOR and RXVECTOR may be referred to as the TXVECTOR parameter and the RXVECTOR parameter, respectively. BSS color may be included in the TXVECTOR parameter or the RXVECTOR parameter. The BSS color set by the AP may be notified to the STA. According to an embodiment, BSSs may be classified based on the BSS color included in the received PPDU. If the BSS color included in a PPDU received by a 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 a PPDU received by a 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 a PPDU received by a 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 condition may include a condition based on a MAC address. The MAC address may be included in the MAC header of the frame. The MAC address may include a receiver address (RA), a transmitter address (TA), a BSSID, a source address (SA), a destination address (DA), etc. According to one embodiment, a BSS may be classified based on a MAC address included in a received frame. If the MAC address included in the received frame is different from the BSSID of the BSS corresponding to the STA, the received frame may be classified as an inter-BSS frame. More specifically, if all of the MAC addresses included in the received frame are different from the BSSID of the BSS corresponding to the STA, the received frame may be classified as an inter-BSS frame. Furthermore, if the MAC address included in the received frame is the same as the BSSID of the BSS corresponding to the STA, the received frame may 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 the BSS corresponding to the STA, the received frame may be classified as an intra-BSS frame.

[0149] The corresponding BSS may include a BSS to which the STA is associated. The corresponding BSS may also include a BSS included in the same multiple BSSID set as the BSS to which the STA is associated. The corresponding BSS may also include a BSS included in the same co-hosted BSSID set as the BSS to which the STA is associated. Information about one or more BSSs included in the same multiple BSSID set or the same co-hosted BSSID set may be transmitted in one frame.

[0150] The BSS classification condition may include a condition based on the value of the Partial AID field included in the VHT PPDU. The Partial AID field may be included in the preamble of the VHT PPDU. The Partial AID field may also be included in the VHT-SIG-A field included in the VHT PPDU. According to one embodiment, the Partial AID field may indicate a portion of the BSS color. For example, when the partial BSS color function is used, the Partial AID field may indicate a portion of the BSS color. Alternatively, when an AID assignment rule is used, the Partial AID field may indicate a portion of the BSS color. The AID assignment rule may be a method of assigning an AID based on the BSS color. Furthermore, when the Group ID field included in the VHT-SIG-A field of the VHT PPDU is a previously set value (e.g., when the Group ID field is set to 63), the Partial AID field may indicate a portion of the BSS color. According to one embodiment, when the Partial AID field of a received PPDU indicates part of a BSS color, if the received Partial AID field value is different from part of the BSS color corresponding to the receiving STA, the received PPDU can be classified as an inter-BSS PPDU.

[0151] Furthermore, when the Partial AID field of a received PPDU indicates a portion of a BSS color, if the value of the received Partial AID field is identical to a portion of the BSS color corresponding to the receiving STA, the received PPDU can be classified as an intra-BSS PPDU. In this case, the portion of the BSS color may be the 4 LSBs of the BSS color. According to another embodiment, the Partial AID field may indicate a portion of a BSSID. For example, if the Group ID field included in the VHT-SIG-A field of the VHT PPDU is a pre-set value (e.g., if the Group ID field is set to 0), the Partial AID field may indicate a portion of the BSSID. According to one embodiment, when the Partial AID field of a received PPDU indicates a portion of a BSSID, if the value of the received Partial AID field is different from a portion of the BSSID corresponding to the receiving STA, the received PPDU can be classified as an inter-BSS PPDU. In addition, if the Partial AID field of a received PPDU indicates a portion of a BSSID, and the received Partial AID field value is identical to a portion of the BSSID corresponding to the receiving STA, the received PPDU can be classified as an intra-BSS PPDU. In this case, the portion of the BSSID may be the 9 MSBs of the BSSID. In addition, the Partial AID field value may be included in the TXVECTOR parameter PARTIAL_AID or the RXVECTOR parameter PARTIAL_AID. In addition, the Group ID field value may be included in the TXVECTOR parameter GROUP_ID or the RXVECTOR parameter GROUP_ID.

[0152] The BSS classification condition may include a condition under which the AP receives a PPDU of a pre-set condition. For example, the PPDU of the pre-set condition may include a downlink PPDU. According to an embodiment, the downlink PPDU may include a VHT MU PPDU. Also, the downlink PPDU may include a PPDU in which signaling indicating whether it is uplink or downlink is set to a pre-set value. The signaling indicating whether it is uplink or downlink may be included in the signaling field of the HE PPDU. Alternatively, the signaling indicating whether it is uplink or downlink may be included in the U-SIG. The U-SIG may be included in the preamble of the EHT PPDU or a post-EHT standard PPDU.

[0153] In addition, there may be cases where a PPDU cannot be classified as an intra-BSS PPDU or an inter-BSS PPDU. For example, if neither the above-mentioned conditions for classification as an intra-BSS PPDU nor the conditions for classification as an inter-BSS PPDU are met, the PPDU may not be classified as an intra-BSS PPDU or an inter-BSS PPDU.

[0154] In addition, when classifying BSSs, if the classification results based on multiple conditions do not match, the final result can be determined based on the previously set conditions. For example, if the results based on the BSS color and the MAC address do not match, the result based on the MAC address can take precedence, or the result based on the MAC address can be determined as the final result. Alternatively, if both the conditions for classification as an intra-BSS PPDU and the conditions for classification as an inter-BSS PPDU are met, the PPDU can be classified as an intra-BSS PPDU.

[0155] According to an embodiment of the present invention, a STA may perform an operation based on a classified BSS. The operation based on the classified BSS may include an intra-PPDU power save operation. The intra-PPDU power save operation may be a power save operation based on a received PPDU. The intra-PPDU power save operation can be performed when a pre-defined condition is met. The pre-defined condition may include a condition for classifying a received PPDU as an intra-BSS PPDU. The pre-defined condition may also include a condition that the intended receiver of the received PPDU is not 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 may not be the STA that received the PPDU. The ID may be included in the preamble of the PPDU. For example, the ID may be the STA_ID included in the preamble of the PPDU. The STA_ID may be included in an HE MU PPDU or an EHT PPDU. The address may also be the MAC address described above. Furthermore, if the signaling indicating uplink or downlink included in the received PPDU indicates uplink, the intended recipient of the PPDU may not be the STA that received the PPDU. Furthermore, if the configuration of the received PPDU is set to a format that the STA that received the PPDU does not support, the intended recipient of the PPDU may not be the STA that received the PPDU. The configuration of the received PPDU may include the MCS, number of spatial streams, channel width, etc. of the PPDU. Furthermore, if the configuration of the received PPDU is not supported by the STA that received the PPDU, a PHY-RXEND.indication(UnsupportedRate) primitive may be received. Furthermore, if the received PPDU is in a pre-configured format, the intended recipient of the PPDU may not be the STA that received the PPDU. The pre-configured format may include a TB PPDU.The TB PPDU may include an HE TB PPDU and an EHT TB PPDU. The TB PPDU may be a PPDU transmitted in response to a triggering frame. The triggering frame may include a trigger frame. The triggering frame may include a frame including triggering information. The triggering information may be included in a MAC header, for example, an A-control field. The triggering information or information included in the trigger frame may include the length of the response PPDU, the RU to be used when responding, the PHY configuration to be used when responding, the MAC configuration, etc. The intra-PPDU power save operation may be an operation that can enter a doze state until the end of the received PPDU. As another example, if a STA determines that the intended recipient of a received PPDU or frame is not the STA, the STA may suspend reception or decoding of the PPDU or frame.

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

[0157] The operation based on the classified BSS may include a spatial reuse operation. The operation based on the classified BSS may include a channel access operation. The spatial reuse operation may be a channel access operation. When a STA receives a PPDU or a frame, the spatial reuse operation can be performed if a pre-set condition is met. The pre-set condition may include a condition that the received PPDU or the received frame corresponds to an inter-BSS. The pre-set condition may also include a condition that the signal strength of the received PPDU or the received frame is lower than a threshold. For example, the threshold may be variable. The threshold may also be a threshold for an OBSS PD-based spatial reuse operation. The threshold may also be a value equal to or greater than the CCA threshold. The threshold may also be a value based on the transmission power. The spatial reuse operation may also include an operation of transmitting a PPDU. The spatial reuse operation may also include an operation of resetting a PHY. For example, the operation of resetting a PHY may be an operation of issuing a PHY-CCARESET.request primitive. Additionally, spatial reuse operations may include operations that do not set a NAV based on a received PPDU or a received frame. If a STA performs spatial reuse operations, the STA may be able to transmit a PPDU while a received PPDU or a received frame is being transmitted or received.

[0158] Referring to FIG. 13, BSS A and BSS B may exist, and BSS A and BSS B may be different BSSs. BSS A and BSS B may correspond to inter-BSSs. That is, a PPDU or frame transmitted by a STA associated with BSS A in BSS B may be classified as an inter-BSS PPDU or an inter-BSS frame. STA1 and STA2 may belong to BSS A (or be associated with the AP operating BSS A). STA3 and STA4 may belong to BSS B (or be associated with the AP operating BSS B). Referring to FIG. 13, STA1 may transmit a PPDU. The PPDU transmitted by STA1 may include information about the BSS. For example, the information about the BSS may be information for classifying the BSSs described above. The PPDU transmitted by STA1 may include duration information.

[0159] STA2 receives the PPDU transmitted by STA1 and can classify the BSS for this PPDU. Furthermore, since 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 for which the STA is not the intended recipient. Therefore, according to the above-described embodiment, STA2 can perform intra-PPDU power saving. Referring to FIG. 13, STA2 may enter a doze state until the end time of the received PPDU. Furthermore, STA2 can set the NAV based on the Duration information included in the received PPDU. Since STA2 has classified the received PPDU as an intra-BSS PPDU, it can set the intra-BSS NAV.

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

[0161] STA4 receives the PPDU transmitted by STA1 and can classify the BSS for this PPDU. Furthermore, 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 lower than a 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 lower than a threshold, STA4 can perform spatial reuse. Therefore, STA4 can perform channel access, a backoff procedure, and start transmission. For example, STA4 may be able to start transmission before the PPDU transmitted by STA1 has finished.

[0162] FIG. 14 shows the functions of the STA according to an embodiment of the present invention.

[0163] According to an embodiment of the present invention, a STA conforming to a certain WLAN standard may include the functionality of a previous WLAN standard. This is for backward compatibility. For example, a STA supporting a specific WLAN standard may support the functionality of a previous generation WLAN standard and also support newer functionality. For example, an HT STA may support the basic functionality of an OFDM PHY STA. Therefore, an HT STA may be classified as an OFDM PHY STA. An HT STA may also support additional functionality that an OFDM PHY STA does not support, in addition to the functionality of an OFDM PHY STA. A VHT STA may support the basic functionality of an HT STA while supporting functionality that an HT STA does not support. A VHT STA may be classified as an HT STA. An HE STA may also support the basic functionality of a VHT STA while supporting functionality that a VHT STA does not support. An HE STA may also be classified as a VHT STA. An EHT STA may also be an HE STA. An EHT STA may also support the basic functionality of an HE STA while supporting functionality that an HE STA does not support. Furthermore, an EHT STA may be classified as an HE STA. Furthermore, a new WLAN standard may be defined after the EHT standard. In the present invention, a standard after the EHT standard is called a NEXT standard, and an STA that complies with the NEXT standard is called a NEXT STA. A NEXT STA supports basic functions of an EHT STA and can also support 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 relationship between STAs supporting each WLAN standard. Referring to Figure 11, an EHT STA may be an HE STA, a VHT STA, an HT STA, or an OFDM PHY STA. Also, a NEXT STA may be an EHT STA, an HE STA, a VHT STA, an HT STA, or an OFDM PHY STA.

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

[0166] In one embodiment of the present invention, an access point may transmit a frame to solicit a multi-user (MU) transmission. Such a frame is called a triggering frame. At this time, one or more STAs that receive the triggering frame may perform uplink transmission based on the triggering frame. Specifically, one or more STAs that receive the triggering frame may 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 may receive the triggering frame and transmit simultaneous, immediate responses. In this specification, an immediate response refers to the interval between the previously received PPDU and the PPDU containing the response being SIFS. Specifically, the response may be transmitted SIFS after the end of the received PPDU.

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

[0168] The TB PPDU is a PPDU format that includes a response frame to a triggering frame. The TB PPDU may include an HE TB PPDU and an EHT TB PPDU. The TB PPDU may also include a NEXT TB PPDU defined in the NEXT WLAN standard. The HE TB PPDU may include a preamble that includes 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). The EHT TB PPDU and NEXT TB PPDU may also include a preamble that includes 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. If the value of the Type subfield (B3 B2) of the MAC frame is 01b and the value of the Subtype subfield (B7 B6 B5 B4) is 0010b, it can be indicated as a MAC frame trigger frame.

[0170] When multiple STAs responding to a trigger frame transmit TB PPDUs in different formats, it may be difficult for the access point to receive the TB PPDUs. Furthermore, when the preambles of the PPDUs transmitted by the multiple STAs are different, it may be difficult for the access point to receive the TB PPDUs. In particular, when RUs transmitting TB PPDUs in different formats overlap, it may be difficult for the access point to receive the TB PPDUs. Therefore, multiple STAs transmitting responses to a single triggering frame may use TB PPDUs in the same format. Furthermore, the preamble information of the TB PPDUs transmitted by multiple STAs transmitting responses to a single triggering frame may be the same.

[0171] As described in Figure 14, an HE STA can transmit an HE TB PPDU, an EHT STA can transmit an EHT TB PPDU or an HE TB PPDU, and a NEXT STA can transmit a NEXT TB PPDU, an EHT TB PPDU, or an HE TB PPDU.

[0172] In the embodiment of Figure 15, an AP transmits a trigger frame that schedules transmissions 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 transmitted in response to the trigger frame, the HE STA (HE STA) and the EHT STA (EHT STA) or different EHT STAs (EHT STAs) may transmit TB PPDUs in different formats. This may result in a failed TB PPDU transmission, resulting in a wasted transmission opportunity. For ease of explanation, the trigger frames defined in the HE, EHT, and NEXT standards are referred to as the HE trigger frame, EHT trigger frame, and NEXT trigger frame, respectively. Furthermore, the TRSs defined in the HE, EHT, and NEXT standards are referred to as the HE TRS, EH TRS, and NEXT TRS. The format of the trigger frame is described in Figure 13.

[0173] FIG. 16 shows the format of a trigger frame and 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 the trigger frame, and Figure 16(c) shows the User Info field of the trigger frame. The MAC header of the trigger frame includes a Frame Control field, a Duration field, and an Address field. Here, 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 includes information for all STAs triggered by the trigger frame. The User Info List field may also include a User Info field. In a specific embodiment, a specific type of trigger frame may not include a User Info List field. The trigger frame may also include a Padding field and an FCS field. The Padding field may serve to extend the frame length to allow the receiving STA time 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 a trigger frame variant. A trigger frame may indicate its type by the value of the Trigger Type subtype. The Trigger Type subfield may also determine the information included in the Trigger Dependent User Info subfield and the lengths of the Trigger Dependent Common Info and Trigger Dependent User Info subfields. For example, the Trigger Type subfield may be indicated by bits B0 to B3 of the Common Info field.

[0176] The Common Info field may also include a UL Length subfield. The UL Length subfield may include information about the length of the TB PPDU responding to the Trigger frame. Alternatively, the UL Length subfield may include information about the length of the frame responding to the Trigger frame. The UL Length subfield may indicate the value included in the Length subfield of the L-SIG of the TB PPDU responding to the Trigger frame. Therefore, a 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 included in the received Trigger frame. More specifically, a STA responding with a TB PPDU can set the Length subfield of the L-SIG of the TB PPDU to the value of the UL Length subfield included in the received Trigger frame. For example, the UL Length subfield may be indicated by bits B4 to B15 of the Common Info field.

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

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

[0179] The User Info field may include an AID12 subfield. The AID12 subfield may indicate the intended recipient of the User Info field containing the AID12 subfield or the function of the User Info field. Therefore, the AID12 subfield may indicate the intended recipient of the trigger frame containing the AID12 subfield or the function of the trigger frame. For example, if the value of the AID12 subfield is a pre-configured value, the User Info field may indicate a random access resource unit (RA-RU). More specifically, if the value of the AID12 subfield is 0, the User Info field may indicate a RA-RU for an associated STA. Also, if the value of the AID12 subfield is 2045, the User Info field may indicate a RA-RU for an unassociated STA. In addition, the value of the AID12 subfield may indicate that a User Info field including the AID12 subfield or a trigger frame including the AID12 subfield triggers a response. For example, the AID12 subfield may indicate an AID or the 12 LSBs 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 range from 1 to 2007 (inclusive). If the AID12 subfield is a pre-set value, for example, 2046, it may indicate that the corresponding RU is not assigned to any STA. If the AID12 subfield is a pre-set value, for example, 4095, it may indicate that padding of the trigger frame begins.

[0180] Furthermore, 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 may indicate the size and location of an 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. Furthermore, the User Info field may indicate a coding method (UL FEC Coding Type), a modulation method (UL HE-MCS, UL DCM), and a transmission power (UL Target RSSI) used in a response to a trigger frame including the User Info field.

[0181] As mentioned above, problems may occur depending on the PPDU format of the TB PPDU that is simultaneously transmitted in response to the trigger frame. A related trigger frame transmission method will be described with reference to FIG.

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

[0183] According to an embodiment of the present invention, an EHT STA can selectively transmit an HE TB PPDU or an EHT TB PPDU. Furthermore, a NEXT STA can selectively transmit an HE TB PPDU, an EHT TB PPDU, or a NEXT TB PPDU. This allows STAs of multiple WLAN standards to be scheduled in one frame or one PPDU, thereby improving the efficiency of transmission medium usage. For example, an HE STA and an EHT STA that do not support the EHT standard can respond with an HE TB PPDU in one frame.

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

[0185] According to an embodiment of the present invention, information regarding the format of the responding TB PPDU may be present at the MAC level. According to an embodiment of the present invention, trigger frames may be classified into HE trigger frames, EHT trigger frames, and NEXT trigger frames. Furthermore, responses triggered by the HE trigger frame, EHT trigger frame, and NEXT trigger frame may be responded with an HE TB PPDU, EHT TB PPDU, and NEXT TB PPDU, respectively.

[0186] Also, distinguishing between the HE trigger frame, EHT trigger frame, and NEXT trigger frame may mean the same as distinguishing the TB PPDU formats responding to the trigger frame as the HE TB PPDU, EHT TB PPDU, and NEXT TB PPDU, respectively. That is, the format of the corresponding TB PPDU may change depending on the format of the trigger frame, and the next-generation trigger frame can also instruct the transmission of the previous-generation TB PPDU. That is, the EHT trigger frame can instruct the transmission of the HE TB PPDU and the EHT TB PPDU simultaneously. However, the HE trigger frame cannot instruct the transmission of the EHT TB PPDU.

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

[0188] In yet another specific embodiment, whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame may be determined based on the Common Info field included in the trigger frame. For example, if the value of the Trigger Type subfield in the Common Info field of the trigger frame is a 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 a 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 a 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. Since the number of bits in the Trigger Type subfield is limited, this embodiment has the disadvantage of restricting future available trigger types using the limited bit field values.

[0189] In yet another specific embodiment, the UL Length field included in the trigger frame may determine whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame. For example, if the UL Length field of the trigger frame is divided by 3 and the remainder is a first value, the trigger frame may be classified as an HE trigger frame. If the UL Length field of the trigger frame is divided by 3 and the remainder is a second value, the trigger frame may be classified as an EHT trigger frame. If the UL Length field of the trigger frame is divided by 3 and the remainder is a third value, the trigger frame may be classified as a NEXT trigger frame. If the UL Length field of the trigger frame is divided by 3 and the remainder is not zero, the trigger frame may be classified as an HE trigger frame. If the UL Length field of the trigger frame is divided by 3 and the remainder is one, the trigger frame may be classified as an HE trigger frame. If the UL Length field of the trigger frame is divided by 3 and the remainder is zero, 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, whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame may also be determined based on at least one of the Format Identifier, PHY Identifier, and TB PPDU format signaling of the trigger frame.

[0190] In yet another specific embodiment, whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame may be determined based on the User Info field included in the trigger frame. Specifically, whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame may be determined based on the value of the AID12 subfield in the User Info field of the trigger frame. For example, whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame may be determined based on whether the value of the AID12 subfield in the User Info field of the trigger frame is a predetermined value. In this case, the User Info field including the AID12 subfield indicating the type of the trigger frame may be the first User Info field in the User Info field list. The User Info field including the AID12 subfield indicating the type of the trigger frame may be located before the User Info field including the AID12 subfield indicating the AID of the STA. This allows the STA receiving the trigger frame to quickly determine the type of the trigger frame. In yet another specific embodiment, a User Info field including an AID12 subfield indicating the type of trigger frame may be located after the User Info field for HE STAs in the User Info field list. This prevents problems caused by legacy STAs, i.e., HE STAs, being unable to determine the meaning of the value of the AID12 subfield. Also, a User Info field including an AID12 subfield indicating the type of trigger frame may not include any subfields other than the AID12 subfield. This is because the User Info field is used to indicate the trigger frame type, and therefore information other than the trigger frame type may not be necessary.In this embodiment, the length of the User Info field varies depending on the value of the AID12 subfield. Figure 17 shows the meaning of the value of the AID12 subfield when this embodiment is applied. When the value of the AID12 subfield is a first value, the AID12 subfield may indicate that a trigger frame including the AID12 field triggers transmission of an EHT TB PPDU. The first value may be 2047. When the value of the AID12 subfield is a second value, the AID12 subfield may indicate that a trigger frame including the AID12 field triggers transmission of a NEXT TB PPDU. The second value may be 2048.

[0191] In yet another specific embodiment, the STA may determine the format of the TB PPDU to be transmitted in response to the trigger frame based on the position of the User Info field that triggers the STA. Specifically, the STA may determine the format of the TB PPDU to be transmitted in response to the trigger frame based on whether the User Info field that triggers the STA is located after a User Info field including an AID12 field with a predetermined value. In this case, the STA may determine the format of the TB PPDU to be transmitted in response to the trigger frame based on whether the User Info field that triggers the STA is located after a User Info field including an AID12 field with a first value or after a User Info field including an AID12 field with a second value. In the embodiment of FIG. 17, when the User Info field that triggers the STA is located after a User Info field including an AID12 field with an AID12 field having 2047, the STA may transmit an EHT TB PPDU in response to the trigger frame. Also, when the User Info field that triggers the STA is located after the User Info field that includes an AID12 field with 2048, the STA can transmit a NEXT TB PPDU in response to the trigger frame. Also, when the User Info field that triggers the STA is located after the User Info field that includes an AID12 field with 2047 and the User Info field that includes an AID12 field with 2048, the STA can transmit a NEXT TB PPDU in response to the trigger frame. Also, when the User Info field that triggers the STA is located before the User Info field that includes an AID12 field with 2047 and the User Info field that includes an AID12 field with 2048, the STA can transmit a NEXT TB PPDU in response to the trigger frame.

[0192] Depending on the subfields of the User Info field other than the AID12 subfield, it may be determined whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame.

[0193] The padding field of the trigger frame may determine whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame. For example, whether the padding field of the trigger frame contains a predetermined value may determine whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame.

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

[0195] The above-described embodiments may also be used to determine the format of the TB PPDU sent in response to the TRS field.

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

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

[0198] A STA that is an intended recipient of a MAC frame containing a TRS can transmit a PPDU based on the field containing the TRS. In this case, the TRS may include information (UL Data Symbols) regarding the length of the PPDU or frame that the STA transmits in response to the MAC frame containing the TRS. It may also include information regarding 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 RU used when transmitting the response to the MAC frame containing the TRS (RU Allocation), and information regarding the modulation method of the response transmission to the MAC frame containing the TRS (UL HE-MCS).

[0199] The TRS may be defined for each WLAN standard. In this case, a STA that receives a MAC frame including a TRS can determine the format of a TB PPDU to be transmitted as a response to the TRS depending on the format of the TRS, i.e., the WLAN standard in which the TRS is defined. Specifically, when a STA receives an HE TRS, the STA can transmit an HE TB PPDU as a response to the TRS. Also, when a STA receives an EHT TRS, the STA can transmit an EHT TB PPDU as a response to the TRS. Also, when a STA receives a NEXT TRS, the STA can transmit a NEXT TB PPDU as a response to the TRS. In this case, the STA can determine the WLAN standard in which the TRS is defined based on the Control ID subfield of the A-Control subfield. The TRS can be classified into an HE TRS and a non-TRS TRS.

[0200] The format of the TRS may be determined depending on 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. If the HT Control field containing the TRS is a NEXT variant, the TRS may be a NEXT TRS. Furthermore, whether the TRS format is an HE variant, an EHT variant, or a NEXT variant may be determined depending on the value of a predetermined bit of the HT Control field containing the TRS. For example, if the first and second bits (B0, B1) of the HT Control field have a value of 11b, the HT Control field may be an HE variant. Furthermore, whether the HT Control field is an HE variant, an EHT variant, or a NEXT variant may be determined based on the first and second bits (B0, B1) of the HT Control field and an additional bit, for example, the 32nd bit (B31).

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

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

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

[0204] Referring to Figure 19, a part or all of the TXOP set by the AP is shared with a non-AP STA, and the non-AP STA can use the shared TXOP to transmit a PPDU (PLCP Protocol Data Unit) to another non-AP STA (third STA) and / or the AP. Hereinafter, in the present invention, sharing a TXOP with another STA can be referred to as TXOP sharing. Furthermore, the STA may be an AP or AP-STA that transmits a trigger frame, or a non-AP STA that receives a trigger frame. Furthermore, the STA can share the TXOP or receive the TXOP sharing.

[0205] Specifically, a STA can set (or acquire) a TXOP by transmitting a frame for setting a TXOP and then receiving a response thereto. After setting a TXOP, a STA can perform TXOP sharing by sharing the set TXOP. The response to the frame for setting a 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 a TXOP may be an immediate response and may be transmitted after a specific time (e.g., SIFS) from the end of the frame for setting a TXOP (e.g., PPDU).

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

[0207] TXOP sharing may be performed within a configured TXOP, and one or more TXOPs may be shared within the configured TXOP, i.e., one or more TXOPs may be shared by a STA to other STAs within a TXOP configured by a STA.

[0208] A STA that has received a shared TXOP can transmit a PPDU to the STA that shared the TXOP or to another STA using the shared TXOP. In this case, the transmitted PPDU may be a PPDU that is not a TB PPDU (e.g., a non-TB PPDU). That is, a STA that has received a shared TXOP can transmit a PPDU without receiving a trigger frame from the AP using the shared TXOP. In other words, a STA that has received a shared TXOP can transmit a PPDU using the RU assigned by the trigger frame transmitted when receiving the shared TXOP, without receiving an additional trigger frame until the shared TXOP ends, even if a separate RU is not individually assigned by the trigger frame in the shared TXOP. Therefore, examples of a PPDU transmitted by a STA using a shared TXOP may include a non-HT PPDU, a HE PPDU, a VHT PPDU, a HE SU PPDU, or an EHT MU PPDU.

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

[0210] Such TXOP sharing may be configured by a specific frame. That is, a specific frame may indicate that part or all of the configured TXOP is to be shared, and a STA may receive the frame and use the shared TXOP. In this case, the specific frame may be transmitted by the STA that shares the TXOP. For example, TXOP sharing may be performed by a trigger frame transmitted by an AP. In this case, the trigger frame for TXOP sharing may be a specific type of trigger frame (e.g., an MU-RTS frame or an MU-RTS trigger frame, etc.) and may be identified by the value of the trigger type subfield of the trigger frame described in FIG. 16. That is, if the value of the trigger type subfield is set to a previously configured value (e.g., "3"), a STA that receives the trigger frame can recognize that the TXOP is to 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 transmit a CTS frame. For example, a CTS frame may be transmitted as an immediate response to an MU-RTS frame, and the CTS frame may be a non-HT PPDU. Hereinafter, in the present invention, the MU-RTS frame for sharing a TXOP may be referred to as a modified MU-RTS frame or an MU-RTS TXS trigger frame. However, the frame for sharing a TXOP may be referred to by various names without being limited thereto.

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

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

[0214] A specific field included in the frame may indicate whether a transmitted MU-RTS frame is an MU-RTS frame for TXOP sharing (modified MU-RTS frame) or an MU-RTS frame not used for TXOP sharing. For example, if the value of a specific field included in the frame is a pre-set value, 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 included in the trigger frame indicates an 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 subfields are set to pre-set values, the trigger frame may be a trigger frame for TXOP sharing.

[0215] Alternatively, whether a received frame is an 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 the User Info List field described in FIG. 16. Specifically, whether a received MU-RTS frame is a frame for TXOP sharing may be determined based on the number of user information fields included in the MU-RTS frame. For example, if an MU-RTS frame does not include a user information field (if the number of user information fields is "0"), the MU-RTS frame may be a frame for TXOP sharing. In this case, if an MU-RTS frame is not a frame for TXOP sharing, 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 defined in the 802.11ax standard.

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

[0217] In the present invention, what is referred to as an MU-RTS frame may be an existing MU-RTS frame, i.e., what is referred to as an MU-RTS frame in the present invention 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 in response to a modified MU-RTS frame. The CTS frame may be transmitted by a STA receiving a TXOP share. In this case, the STA receiving a TXOP share may transmit the frame immediately after transmitting the CTS frame. The STA receiving a TXOP share may transmit the frame immediately after transmitting the PPDU including the CTS frame. The frame transmitted immediately after transmitting the CTS frame may be included in a PPDU transmitted by the STA receiving the TXOP share in the shared TXOP. Alternatively, the frame transmitted immediately after transmitting the CTS frame may be included in the non-TB PPDU. In addition, in the present invention, transmitting immediately may mean transmitting at a time SIFS or PIFS after the end of the PPDU including the CTS frame. The CTS frame may serve to notify the STA receiving the TXOP share that it has received the TXOP share.

[0219] According to another embodiment, a CTS frame may not be transmitted in response to a modified MU-RTS frame. A STA that receives a TXOP share may transmit a frame immediately after the modified MU-RTS frame. Alternatively, a STA that receives a TXOP share may transmit a PPDU immediately after the PPDU containing the modified MU-RTS frame. In this case, the transmitted frame may be included in the PPDU transmitted by the STA that received the TXOP share in the shared TXOP. Alternatively, the transmitted frame may be included in the non-TB PPDU. In the present invention, transmitting immediately after may mean transmitting at a point in time SIFS or PIFS later than the end of the PPDU containing the modified MU-RTS frame.

[0220] According to one embodiment, the modified MU-RTS frame may include signaling regarding whether the STA receiving the TXOP sharing should transmit a CTS frame. According to one embodiment, when the STA receiving the TXOP sharing transmits a frame to the AP, it may use a shared TXOP without a CTS frame. Furthermore, when the STA receiving the TXOP sharing transmits a P2P frame, it may transmit a CTS frame and use a shared TXOP. Even when the STA receiving the TXOP sharing transmits a P2P frame, the RA field of the CTS frame transmitted immediately after the modified MU-RTS frame may be set to the MAC address of the STA that transmitted the modified MU-RTS frame. This is because, if the STA receiving the TXOP sharing does not transmit a frame including the address of the STA that transmitted the modified MU-RTS frame after receiving the modified MU-RTS frame, it is difficult for the STA sharing the TXOP to determine whether the STA receiving the TXOP sharing successfully received the modified MU-RTS frame.

[0221] Referring to FIG. 19, STA1 and STA2 may exist and may be associated with each other. STA1 may be an AP. STA2 may be a non-AP STA. STA1 may transmit an MU-RTS frame. The MU-RTS frame may be an existing MU-RTS frame. The MU-RTS frame may include duration information regarding the TXOP duration. The MU-RTS frame may induce a CTS frame from one or more STAs. In this case, the one or more STAs may include STA2. STA2 may transmit a CTS frame in response to the MU-RTS frame. In this case, STA1 may be the TXOP holder. The TXOP holder may be the STA that obtained the TXOP. The TXOP holder can send a frame to be transmitted using the TXOP. In this case, STA2 may be the TXOP responder. The TXOP responder may be the STA that transmitted a response to the frame sent by the TXOP holder. The TXOP responder can use the TXOP to send a response to a frame sent by the TXOP holder. Alternatively, the TXOP responder can use the TXOP to send a frame accepted by the TXOP holder. In the embodiment of Fig. 19, an example in which a TXOP is acquired based on an exchange of an MU-RTS frame and a CTS frame has been described, but the present invention is not limited to this and can also be applied to a TXOP being acquired based on other frame exchanges.

[0222] In FIG. 19, STA1 can perform TXOP sharing after acquiring the TXOP. For example, STA1 can transmit a modified MU-RTS frame, which is a frame informing TXOP sharing. For example, STA1 can transmit the modified MU-RTS frame to STA2. The transmitter address (TA) of the modified MU-RTS frame may be set to the MAC address of STA1 or a value based on the MAC address of STA1. The receiver address (RA) of the modified MU-RTS frame may be set to the MAC address of STA2 or a value based on the MAC address of STA2. Furthermore, the User Info field included in the modified MU-RTS frame may have an AID12 subfield value indicating STA2. That is, the User Info field included in the modified MU-RTS frame may have an AID12 subfield value indicating the 12 LSBs of the AID of STA2. The modified MU-RTS frame may include information regarding the duration of the shared TXOP.

[0223] According to one embodiment, STA2 can transmit a CTS frame in response to the modified MU-RTS frame. STA2 can also transmit a frame after transmitting the CTS frame. The frame transmitted by STA2 after transmitting the CTS frame need not be a CTS frame. According to yet another embodiment, STA2 does not need to transmit a CTS frame in response to the modified MU-RTS frame. In this case, STA2 can transmit a frame that is not a CTS frame after transmitting the modified MU-RTS frame. According to one embodiment, the frame that is not a CTS frame transmitted by STA2 after receiving the modified MU-RTS frame may be a frame transmitted to STA1. According to another embodiment, the frame that is not a CTS frame transmitted by STA2 after receiving the modified MU-RTS frame may be a frame transmitted to STA3.

[0224] For example, an AP can set the TXOP of the AP by transmitting a trigger frame to a non-AP STA (or STAs). In this case, if the AP intends to share some or all of the TXOP set by the AP with the non-AP STA that transmitted the trigger frame, the AP can transmit the trigger frame by setting a specific field (e.g., the GI and HE-LTF type subfield) of the trigger frame to a pre-configured value. In this case, the specific field can be referred to as 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 can be set to '0' and interpreted 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 can be set to '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 called a modified MU-RTS frame or an MU-RTS TXS trigger frame. When an AP shares part or all of the TXOP set 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 is shared only with the AP that set the TXOP, or whether it is shared with a third STA (or 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," a STA with a shared TXOP can only transmit a PPDU to the AP.However, if the value of the GI and HE-LTF type / triggered TXOP sharing mode subfield is "2", the STA can transmit PPDUs not only to the AP but also to other STAs using the shared TXOP. That is, if the value of the GI and HE-LTF type / triggered TXOP sharing mode subfield is "2", the STA can also perform P2P communication using the shared TXOP.

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

[0226] [Table 1]

[0227] FIG. 20 illustrates a method related to TXOP sharing and NAV setting according to one embodiment of the present invention.

[0228] The embodiment of Fig. 20 can be an embodiment that explains the problem of difficulty in performing the operation explained in Fig. 19 and a solution to that problem. The details explained in Fig. 19 can be omitted.

[0229] According to one embodiment of the present invention, a STA may set a network allocation vector (NAV) based on duration information included in a received frame or a received PPDU. Whether a virtual carrier sense (CS) result is idle or busy may be determined based on whether the NAV is 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 clear channel assessment (CCA). If at least one of the virtual CS or the physical CS is busy, the CS result may be busy. If both the virtual CS and the physical CS are idle, the CS result may be idle. A STA may also include multiple NAVs. For example, a STA may include an intra-BSS NAV and a basic NAV. The intra-BSS NAV may be the NAV set by an intra-BSS frame or an intra-BSS PPDU. Regular NAV may be a NAV set by an inter-BSS frame, inter-BSS PPDU, or intra-BSS frame or PPDU, or a frame or PPDU that cannot be determined to be inter-BSS. Furthermore, if at least one of the intra-BSS NAV and basic NAV is greater than 0, the virtual CS may be busy. Alternatively, if at least one of the intra-BSS NAV and basic NAV is greater than 0, it can be said that the NAV is greater than 0. If both the intra-BSS NAV and basic NAV are 0, the virtual CS may be idle. Alternatively, if both the 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 an intra-BSS PPDU may be a frame or PPDU that is determined to be transmitted from the same BSS as the STA. For a given STA, an inter-BSS frame or an inter-BSS PPDU may be a frame or PPDU that is determined to be transmitted from a different BSS than the STA. Whether a frame or a PPDU is transmitted from the same BSS or a different BSS may be determined based on the BSS color field included in the PPDU preamble, the address field included in the MAC header, etc. For example, if the BSS color field or the address field contains a value corresponding to the same BSS, the frame or the PPDU can be determined to be an intra-BSS frame or an intra-BSS PPDU. If the BSS color field or the address field does not contain a value corresponding to the same BSS, the frame or the PPDU can be determined to be an inter-BSS frame or an inter-BSS PPDU. The address field may include an RA field, a TA field, a BSSID field, etc.

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

[0232] According to one embodiment of the present invention, when the CS is busy, the STA may not be able to transmit frames or PPDUs.

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

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

[0235] According to yet another embodiment, if a received frame is sent from a TXOP holder, the STA may be able to send a response to the received frame regardless of the NAV. 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 the intra-BSS NAV. Furthermore, the received frame may be an RTS frame. Whether a frame is sent from a TXOP holder can be determined based on the TA field included in the frame. The STA may store the TXOP holder address. If a STA receives an RTS frame sent by a TXOP holder and the RTS frame is addressed to the STA, the STA may respond to the RTS frame without considering the NAV. In this case, the STA may send a CTS frame in response to the RTS frame.

[0236] According to yet another embodiment, when a STA receives a trigger frame, it may be able to transmit a response thereto regardless of its NAV. In this case, the NAV may be limited to the intra-BSS NAV. Therefore, if the NAV is set by a STA in the same BSS or an AP in the same BSS, the STA may transmit a response thereto regardless of its NAV when a response is instructed by the trigger frame. When a STA receives a trigger frame, it may determine whether to transmit a response thereto, taking into account the intra-BSS NAV but not the basic NAV. Furthermore, when a STA receives a trigger frame, it may determine whether to transmit a response thereto based on a CS result. For example, the trigger frame may include signaling indicating whether to determine whether to transmit a response thereto based on the CS result when the STA receives the trigger frame. For example, the signaling may be the CS Required subfield shown in FIG. 16. If the CS Required subfield indicates that the STA determines whether to respond based on the CS result, the STA responds to the trigger frame if the virtual CS and physical CS indicate idle, and does not respond to the trigger frame if the virtual CS or physical CS indicates busy. In this case, the STA can consider basic NAV as the virtual CS, not intra-BSS NAV. Also, if the CS Required subfield indicates that the STA responds regardless of the CS result, the STA can respond to the trigger frame without checking the CS result.

[0237] In the example of Figure 19, a STA that receives a modified MU-RTS frame may have its NAV set and therefore may not be able to send any frames other than CTS frames in the shared TXOP. This is further explained in Figure 20.

[0238] The details described in FIG. 19 in relation to FIG. 20 may be omitted. Referring to FIG. 20, STA1 and STA2 may exist and may be associated with each other. STA1 may be an AP. STA2 may be a non-AP STA. STA1 may transmit an MU-RTS frame. STA2 may transmit a CTS frame in response to the MU-RTS frame. STA2 may transmit a CTS frame because its physical CS result is idle and basic NAV is not set. STA2 may transmit a CTS frame because it has received a frame addressed to itself and requiring an immediate response. Even if other frame exchanges occur in addition to the exchange of the MU-RTS frame and the CTS frame, STA2 may transmit a response frame based on the frame received from STA1 because the frame is addressed to STA2 and requires an immediate response. STA2 may have set its NAV based on the MU-RTS frame or a frame other than the MU-RTS frame transmitted by STA1. In this case, the NAV may be the intra-BSS NAV.

[0239] STA1 can also share a TXOP with STA2. That is, STA1 can transmit a modified MU-RTS frame to STA2. In this case, as described above, STA2 can use the shared TXOP to either 1) transmit a CTS frame followed by another frame, or 2) transmit another frame without transmitting a CTS frame. However, in this case, STA2 may have difficulty transmitting a frame because its NAV is set. For example, STA2's NAV may be set by a frame sent by STA1 to obtain a TXOP before allocating the shared TXOP. That is, STA2's NAV may be set by receiving a frame sent by STA1 before transmitting a modified MU-RTS frame. Alternatively, STA2's NAV may be set by receiving a frame sent from another STA with the same TXOP before receiving a modified MU-RTS frame addressed to itself. Alternatively, STA2's NAV may be set based on a modified MU-RTS frame addressed to itself. That is, STA2 may have a NAV set because it must receive at least a modified MU-RTS frame when using a shared TXOP, which may make it difficult for STA2 to transmit frames using a shared TXOP.

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

[0241] That is, when a STA receives a shared TXOP, it can transmit a PPDU regardless of the NAV set in the shared TXOP. Specifically, when an AP transmits a trigger frame for sharing a TXOP, the AP may set a NAV in the shared TXOP. In this case, the STA receiving the shared TXOP may be unable to transmit a PPDU due to the NAV set in the shared TXOP. Therefore, the STA receiving the shared TXOP can transmit a PPDU in the shared TXOP, ignoring the NAV set by the AP that shared the TXOP.

[0242] In the present invention, what is indicated as a frame may be replaced with a PPDU including a frame, and the present invention may be applied.

[0243] In this case, the frame transmitted by the STA that has received the TXOP sharing, regardless of the NAV, may be transmitted SIFS after the previous PPDU.

[0244] According to yet another embodiment, when a STA that has received a TXOP share transmits a frame, it can take the NAV into consideration if the frame is transmitted PIFS after the previous PPDU.

[0245] Referring to FIG. 20 , STA2 may have its NAV set based on the MU-RTS frame or the modified MU-RTS frame. For example, an intra-BSS NAV may be set. Alternatively, STA2 may have its NAV set based on the intra-BSS frame. Alternatively, STA2 may have its NAV set based on a frame transmitted by an associated AP. In this embodiment, the term "NAV" may refer collectively to such NAVs. STA1 may perform TXOP sharing with STA2. STA2 may receive TXOP sharing via a modified MU-RTS frame. When STA2 transmits a frame with a shared TXOP, it may transmit the frame regardless of the NAV. In this case, according to one embodiment, the transmitted frame may be a frame transmitted immediately after the CTS frame transmitted immediately after the received modified MU-RTS frame. In another embodiment, the transmitted frame may be a frame transmitted immediately after the received modified MU-RTS frame. Also, 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. Or, 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 transmitted to STA3. Also, transmitting a frame immediately after may mean that the transmission start point of the PPDU containing the frame is SIFS after the end of the previous PPDU.

[0246] FIG. 21 is a diagram illustrating TXOP sharing and CTS frame transmission according to one embodiment of the present invention.

[0247] The embodiment of Fig. 21 may be a method for solving the problems described in Fig. 19 and Fig. 20. Therefore, the above content can be omitted from the description.

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

[0249] According to an embodiment of the present invention, a STA that has received a TXOP share can transmit a CTS-to-self frame in response to a modified MU-RTS frame. The CTS-to-self frame may be a CTS frame with the RA field set to the MAC address of the STA that transmits the CTS-to-self frame. In this case, if the STA that is sharing the TXOP receives a frame including the MAC address of the STA that receives the TXOP share after transmitting a modified MU-RTS frame, it can determine that the shared TXOP allocation has been successful.

[0250] Referring to FIG. 21, STA2 can receive a modified MU-RTS frame from STA1. Also, STA2 can transmit 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 transmit the CTS frame. In this case, STA2 can consider the CTS-to-self frame sent by STA2 to be a frame addressed to itself and requiring an immediate response. Alternatively, STA2 can consider that it has received a frame addressed to itself and requiring an immediate response in response to the transmission of the CTS-to-self frame. Therefore, STA2 can transmit a frame immediately after the CTS-to-self frame even if NAV is set.

[0251] According to an embodiment of the present invention, the RA field of a CTS frame transmitted in response to an RTS frame or an MU-RTS frame may be set to a value in which the TA field value of the RTS frame or the MU-RTS frame or the Individual / Group bit in the TA field value is set to 0. However, as described in Figure 21, a further method of 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 in response to a modified MU-RTS frame may be set to the MAC address of the STA transmitting the CTS frame.

[0252] According to an embodiment of the present invention, a STA that receives a TXOP sharing may be able to perform recovery within the shared TXOP. That is, the STA that receives the TXOP sharing may perform recovery if a frame it transmitted within the shared TXOP fails. For example, if a frame it transmitted within the shared TXOP fails, the STA that received the TXOP may transmit the frame at a point PIFS later. According to an embodiment of the present invention, the TXOP holder may perform recovery. In addition, if the TXOP holder shares the TXOP, the STA that received the TXOP sharing may perform recovery. That is, recovery may be performed if the STA is 1) a TXOP responder or 2) a STA that is neither a TXOP holder nor a TXOP responder becomes the STA that received the TXOP sharing. Furthermore, the STA that received the TXOP sharing may perform recovery even if it transmits the first non-CTS frame after receiving a modified MU-RTS frame, if the non-CTS frame fails. For example, a TXOP holder may not be able to perform a recovery operation if the first frame it transmits in a sequence fails, and the TXOP may not be obtained in this case. However, a STA that receives a shared TXOP may be able to perform a recovery operation even if a frame other than the first CTS frame transmitted in the shared TXOP fails.

[0253] Referring to FIG. 21, STA2 may transmit the UL frame shown in the drawing and perform a recovery operation if the transmission fails. That is, STA2 may transmit the UL frame and retransmit the frame if it fails to receive the DL frame shown in the drawing. In this case, the retransmitted frame may start transmission PIFS after the end of the PPDU including the failed UL frame shown in the drawing. In addition, it may check whether the channel is idle during recovery. In addition, the recovery operation performed by the STA that received the TXOP sharing may consider only the physical CS, without considering the virtual CS.

[0254] FIG. 22 is a diagram illustrating an example of a trigger frame for TXOP sharing according to one embodiment of the present invention.

[0255] As described in FIG. 19, whether a frame is a modified MU-RTS frame may be determined based on the number of user information fields. However, the trigger frame defined in the 802.11ax standard may have been designed without considering feature extensions in subsequent standards. Therefore, for example, the common information field shown in FIG. 16(b) may lack signaling space to include extended features. Therefore, according to an embodiment of the present invention, the user information field including a pre-set AID12 subfield value may have a format different from that shown in FIG. 16(c). Furthermore, the user information field including a pre-set AID12 subfield value may include information corresponding to all or one or more recipients of the trigger frame including the user information field. For example, the user information field including a pre-set AID12 subfield value may include at least one of information on a PHY version ID, a bandwidth extension, a bandwidth, spatial reuse, and U-SIG reserved bits. In addition, the pre-set AID12 subfield value may be based on a value that is not assigned as an actual AID. The pre-set AID12 subfield value may be 12 LSBs of a value that is not assigned as an actual AID. For example, the pre-set AID12 subfield value may be 2007.

[0256] The expanded capabilities may include, for example, an expanded bandwidth (e.g., from a maximum of 160 MHz to a maximum of 320 MHz), and information for generating a U-SIG field.

[0257] Therefore, according to an embodiment of the present invention, in order to use the extended functionality within a modified MU-RTS frame or even within a shared TXOP, the modified MU-RTS frame may include a user information field that includes the previously configured AID12 subfield value described above.

[0258] According to an embodiment of the present invention, a modified MU-RTS frame may include no user information fields or may only include a user information field containing the previously configured AID12 subfield value. That is, if a received trigger frame does not include any user information fields or only includes a user information field containing the previously configured AID12 subfield value, the trigger frame can be determined as a modified MU-RTS frame. Alternatively, if a received MU-RTS frame does not include any user information fields or only includes a user information field containing the previously configured AID12 subfield value, the MU-RTS frame can be determined as a modified MU-RTS frame. In this case, the STA receiving the TXOP sharing may be indicated by the RA field of the trigger frame.

[0259] Referring to FIG. 22, the modified MU-RTS frame may have a Type subfield set to MU-RTS. The modified MU-RTS frame may also have one User Information field, and the AID12 subfield included in the User Information field may be set to a pre-configured value. In this case, the pre-configured value may be a value that is not assigned as an AID. The pre-configured value may be a value different from the 12 LSBs of the AID of the STA that has the RA field value of the modified MU-RTS frame as its MAC address. For example, the pre-configured value may be 2007. Alternatively, the modified MU-RTS frame may not include any User Information fields. That is, when the Type of the trigger frame is set to an MU-RTS frame, a STA that receives the trigger frame can determine that the trigger frame is a modified MU-RTS frame if the trigger frame does not include any User Information fields or only includes a User Information field with an AID12 subfield with a pre-configured value.

[0260] FIG. 23 is a diagram illustrating a NAV time out according to one embodiment of the present invention.

[0261] According to one embodiment of the present invention, a STA may be able to reset a set NAV. For example, if the NAV is set based on an RTS frame or an MU-RTS frame, the STA may be able to reset the NAV. More specifically, if the NAV is set based on an RTS frame or an MU-RTS frame, the STA may be able to reset the NAV if PPDU reception does not start successfully within the previously set time. This operation may be referred to as a NAV timeout. The previously set time may be referred to as a NAV timeout period. The NAV timeout period may start when a PHY-RXEND.indication primitive corresponding to an RTS frame or an MU-RTS frame is received.

[0262] In an embodiment of the present invention, setting a NAV based on an RTS frame or an MU-RTS frame may mean that the most recent NAV update was based on an RTS frame or an MU-RTS frame. If the duration information received by a STA from an RTS frame or an MU-RTS frame is greater than the STA's current NAV value, the STA can set or update the NAV 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 the TXOP duration or TXOP field included in the preamble of the PPDU.

[0263] In addition, in an embodiment of the present invention, a PHY-RXSTART.indication primitive may be received when PPDU reception has successfully started. Alternatively, a PHY-RXSTART.indication primitive may be issued when PPDU reception has successfully started. 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 may indicate receiving a valid PHY header. The PHY-RXSTART.indication primitive may 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 for the length indicated by the PPDU preamble. If a PHY-RXSTART.indication primitive is generated, the PHY can keep the physical medium busy for the length of the PPDU or the length indicated by the PPDU preamble even if reception fails during the PPDU. Alternatively, a PHY-RXEND.indication may be generated when PPDU reception is completed.

[0264] According to an embodiment of the present invention, the NAV timeout period may be based on a response time for an RTS frame or an MU-RTS frame. That is, if the response to an RTS frame or an MU-RTS frame is a CTS frame, the NAV timeout period may be based on the CTS frame time. The CTS frame time may be indicated as CTS_Time. Alternatively, the response time for an RTS frame or an MU-RTS frame may be indicated as CTS_Time. In this case, the response time for an RTS frame or an MU-RTS frame may refer to the length of a 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, the CTS_Time may be calculated based on a pre-set rate. That is, the CTS_Time may be the length of the CTS frame calculated based on the pre-set rate. Or, the CTS_Time may be the length of the PPDU including the CTS frame calculated based on the pre-set rate. For example, the pre-set rate may be 6 Mbps. For example, the CTS_Time may be calculated based on a data rate of 6 Mbps. Or, the pre-set rate may be the rate of the RTS frame or MU-RTS frame that sets the NAV. Or, the pre-set rate may be the rate indicated by the RTS frame or MU-RTS frame that sets the NAV.

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

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

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

[0270] According to an embodiment of the present invention, the RTS frame may be a frame indicating a CTS frame. Alternatively, the RTS frame may be a frame indicating a CTS frame from a single STA. The 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 include time information for a STA receiving the Duration field to set its NAV. The RA field may include the address of an intended immediate recipient. For example, if the RA field included in an RTS frame received by a STA is the address of the STA, the STA can respond to the RTS frame with a CTS frame. Whether a frame is an RTS frame may be determined based on the Frame Control field included in the frame. For example, whether a frame is an RTS frame may be determined based on the Type subfield and the Subtype subfield included in the Frame Control field included in the frame. For example, if the Type subfield is 01 (B3 B2) and the Subtype subfield is 1011 (B7 B6 B5 B4), it indicates that the frame including the Type subfield and the Subtype subfield is an RTS frame. For example, the RTS frame may be a Control frame.

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

[0272] Referring to the first sequence of FIG. 23, STA1, STA2, and STA3 may exist. STA1 may transmit 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 the address of STA2, the RTS frame or the MU-RTS frame may be transmitted to STA2. Alternatively, if the User Info field included in the MU-RTS frame indicates STA2, the MU-RTS frame may be transmitted to STA2. If STA2 successfully receives the RTS frame or the MU-RTS frame, it may respond with a CTS frame. In this case, STA2 may respond based on a carrier sense (CS) result. Furthermore, if STA3 receives the RTS frame or the MU-RTS frame, STA3 may set its NAV based on the duration information included in the RTS frame or the MU-RTS frame or the duration information included in the PPDU including the RTS frame or the MU-RTS frame. Also, if STA1 successfully receives the CTS frame transmitted by STA2, STA1 can transmit a frame to STA2. Also, after STA3 sets the NAV, it may receive the CTS frame transmitted by STA2 or a frame transmitted by STA1 to STA2. In this case, STA3 may receive a PHY-RXSTART.indication primitive within the NAVTimeout period. Therefore, it may be impossible to cancel the NAV set by STA3.

[0273] Referring to the second sequence in Figure 23, STA1, STA2, and STA3 may exist. STA1 may transmit an RTS frame or an MU-RTS frame to STA2. If STA2 does not successfully receive the RTS frame or the MU-RTS frame, it may be unable to respond with a CTS frame. Alternatively, STA2 may successfully receive the RTS frame or the MU-RTS frame but may be unable to respond with a CTS frame based on the CS result. In such cases, the frame sequence sent by STA1 to STA2 may not continue.

[0274] Furthermore, when STA3 receives the RTS frame or the MU-RTS frame, STA3 can set its NAV based on the duration information included in the RTS frame or the MU-RTS frame, or the duration information included in the PPDU including the RTS frame or the MU-RTS frame. Furthermore, after STA3 sets its NAV, STA3 may be unable to receive a CTS frame transmitted by STA2 or a frame transmitted by STA1 to STA2. In such a case, STA3 may not receive a PHY-RXSTART.indication primitive within the NAVTimeout period. Therefore, STA3 can cancel the NAV it set. This solves the problem of STA3 maintaining its NAV and being unable to access the channel even when the sequence is not continuing.

[0275] FIG. 24 is a diagram illustrating TXOP sharing and NAV timeout according to one embodiment of the present invention.

[0276] Referring to Figure 24, as described 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 the TXOP sharing. STA1 can transmit the first frame of a sequence to STA2. Referring to Figure 24, the first frame of the sequence that STA1 transmits to STA2 may be an MU-RTS frame. In addition, a CTS frame may be transmitted as a response to the MU-RTS frame.

[0277] For example, a CTS frame may be transmitted from STAs including STA2. STA1 may obtain a TXOP. STA3 may not successfully receive the MU-RTS frame and the CTS frame. STA1 may transmit a modified MU-RTS frame to STA2. That is, STA1 may share a TXOP with STA2. STA3 may successfully receive the modified MU-RTS frame. Therefore, STA3 may set its NAV based on the modified MU-RTS frame. In this case, STA3 may have set its NAV based on the MU-RTS frame. According to the TXOP sharing sequence described above, STA2 may 1) transmit a CTS frame in response to the modified MU-RTS frame, and then transmit a frame immediately after transmitting the CTS frame. Alternatively, STA2 may 2) transmit a frame without transmitting a CTS frame in response to the modified MU-RTS frame. STA3 may also fail to receive a frame or PPDU from STA2. For example, STA3 may be located in a hidden location from STA2. For example, the power transmitted by STA2 may not be sufficient for STA3 to receive the PPDU. In such a case, STA3 may not receive the PPDU within 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, the NAVTimeout period for STA3 should expire while the frame is being transmitted. Alternatively, if STA2 transmits a frame without transmitting a CTS frame, the frame is likely to be longer than the CTS frame, so the NAVTimeout period for STA3 should expire while the frame is being transmitted. Therefore, STA3 may be able to cancel NAV. If STA3 cancels NAV, STA3 may connect to the channel and disrupt the sequence in the shared TXOP.

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

[0279] 25, when a TXOP is shared by an AP, another STA (third STA) other than the STA with which the TXOP is shared by the AP may not release the shared TXOP even if a CTS frame or other frame is not transmitted from the STA with which the TXOP is shared within a certain period of time. The embodiment of FIG. 25 may be intended to solve the problems described in FIG. 23 and FIG. 24. Also, the above content may be omitted.

[0280] Specifically, a NAV timeout for releasing a TXOP may be allowed or not allowed depending on whether the trigger frame (e.g., MU-RTS frame) transmitted from the AP is a modified MU-RTS frame or an MU-RTS TXS trigger frame for sharing a TXOP. That is, whether the TXOP is a commonly set TXOP or whether all or part of the TXOP set by the AP is a shared TXOP may determine whether a NAV timeout for releasing a TXOP other than the STA that set the TXOP is allowed or not.

[0281] For example, if the NAV is configured based on an MU-RTS frame that is not a frame for sharing part or all of the configured TXOP (a modified MU-RTS frame or an MU-RTS TXS trigger frame), a NAV timeout may be allowed. That is, if an STA configures the NAV based on an MU-RTS frame, and the MU-RTS frame is not a modified MU-RTS frame, it may be possible to cancel the NAV if PPDU reception does not start successfully within the NAVTimeout period.

[0282] However, if the NAV is set by a modified MU-RTS frame or an MU-RTS TXS trigger frame, which is a frame for sharing part or all of the set TXOP, the NAV timeout may not be allowed. That is, if the STA sets the NAV based on the MU-RTS frame, and the MU-RTS frame is a modified MU-RTS frame or an MU-RTS TXS trigger frame for TXOP sharing, the STA may not be able to release the NAV even if it does not successfully start PPDU reception within the NAVTimeout period.

[0283] That is, if the last frame the STA received for NAV update was a modified MU-RTS frame or an MU-RTS TXS trigger frame, which is a frame for TXOP sharing, the STA must not reset the NAV after the NAVTimeout expires.

[0284] Whether a received MU-RTS frame is a modified MU-RTS frame can be determined according to the above-described embodiments. For example, whether a received MU-RTS frame is a modified MU-RTS frame can be determined based on the GI and HE-LTF Type subfield included in the MU-RTS frame. For example, if the GI and HE-LTF Type subfield value is 0, the MU-RTS frame including the GI and HE-LTF Type subfield may not be a modified MU-RTS frame. Also, if the GI and HE-LTF Type subfield value is not 0, the MU-RTS frame including 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 including the GI and HE-LTF Type subfield may be a modified MU-RTS frame.

[0285] An embodiment of the present invention can prevent the problem described in Figure 24, where a STA performs a NAV timeout operation after setting its NAV based on a modified MU-RTS frame, thereby disrupting the sequence of shared TXOPs.

[0286] Furthermore, such an embodiment may be performed by terminals conforming to the 802.11be standard or later (terminals conforming to standards including the EHT standard or later), but may not be performed by terminals conforming to the 802.11ax standard (HE STAs). Even if the HE STAs are unable to perform this, the probability of the problems described in the above embodiment occurring can be reduced.

[0287] Referring to FIG. 25, STA1, STA2, and STA3 may exist. STA1 may transmit an MU-RTS frame to STA2. For example, STA1 may transmit an MU-RTS frame that is not a modified MU-RTS frame. However, STA2, the intended recipient of the MU-RTS frame, may fail to respond to the MU-RTS frame. Therefore, STA2 may be unable to transmit a CTS frame. STA3 may set a NAV based on the MU-RTS frame. However, because STA2 was unable to transmit a CTS frame, STA3 may not successfully receive a PPDU within the NAV Timeout period. In this case, STA3 may cancel the set NAV based on the NAV timeout operation. This may be because the frame for which STA3 set its NAV is an MU-RTS frame that is not a modified MU-RTS frame.

[0288] STA1 may also transmit a modified MU-RTS frame. In FIG. 25, the frame before the modified MU-RTS frame may be omitted. STA2, the intended recipient of the modified MU-RTS frame, may respond to the modified MU-RTS frame. STA3 may also set its NAV based on the modified MU-RTS frame. However, STA3 may not receive the response sent by STA2 to the modified MU-RTS frame. For example, this may be because STA3 does not hear the response sent by STA2 with sufficient power. For example, this may be because STA3 and STA2 are far apart. In this case, STA3 may not successfully start PPDU reception within the NAVTimeout period. This may be because STA2 transmitted a frame after transmitting a CTS frame following the modified MU-RTS frame. Or, this may be because STA2 transmitted a frame longer than the CTS frame following the modified MU-RTS frame. Alternatively, this may be because STA2 has sent a PPDU after the modified MU-RTS frame that is longer than the PPDU containing the CTS frame. In this case, STA3 may not be able to cancel the NAV based on the NAV timeout operation. This may be because the frame that caused STA3 to set the NAV is a modified MU-RTS frame.

[0289] FIG. 26 is a diagram illustrating TXOP sharing and NAV timeout according to yet another embodiment of the present invention.

[0290] The embodiment of Fig. 26 may be intended to solve the problems described in Fig. 23 and Fig. 24. Also, the above-described contents may be omitted.

[0291] According to an embodiment of the present invention, the NAV timeout period may be determined differently depending on whether the MU-RTS frame is a modified MU-RTS frame. For example, the CTS_Time may be determined differently depending on whether the MU-RTS frame is a modified MU-RTS frame. According to an 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 may be referred to as the extended NAV Timeout period. The NAV Timeout period and the extended NAV Timeout period described in FIG. 23 may start at the same time. That is, they may start when a PHY-RXEND.indication primitive corresponding to the MU-RTS frame is received. The NAV Timeout period described in FIG. 23 may be a time based on the CTS frame time. For example, the NAVTimeout period described in FIG. 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 a STA sets a NAV based on a modified MU-RTS frame, if it fails to successfully receive a PPDU within the extended NAVTimeout period, it may be possible to cancel the NAV. When a STA sets a NAV based on a modified MU-RTS frame, if it fails to successfully start receiving a PPDU within the NAVTimeout period described in FIG. 23, it may also be unable to cancel the NAV.

[0293] In addition, if a STA sets NAV based on an MU-RTS frame that is not a modified MU-RTS frame, it may be possible to cancel the NAV if PPDU reception cannot be successfully started within the NAVTimeout period described in Figure 23.

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

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

[0296] Referring to FIG. 26, STA1, STA2, and STA3 may exist. STA1 may transmit an MU-RTS frame to STA2. For example, STA1 may transmit an MU-RTS frame that is not a modified MU-RTS frame. However, STA2, the intended recipient of the MU-RTS frame, may be unable to respond to the MU-RTS frame. Therefore, STA2 may be unable to transmit a CTS frame. STA3 may set a NAV based on the MU-RTS frame. However, because STA2 was unable to transmit a CTS frame, STA3 may not have successfully started PPDU reception within the NAVTimeout period. In this case, STA3 may cancel the set NAV based on a NAV timeout operation. This operation may be based on the determined NAVTimeout period because the frame for which STA3 set its NAV is an MU-RTS frame that is not a modified MU-RTS frame. That is, since the frame in which STA3 sets the NAV is an 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] Also, STA1 may transmit a modified MU-RTS frame. In FIG. 26, the frame before the modified MU-RTS frame may be omitted. STA2, the intended recipient of the modified MU-RTS frame, may respond to the modified MU-RTS frame. STA3 may also set its NAV based on the modified MU-RTS frame. However, STA3 may not receive the response sent by STA2 to the modified MU-RTS frame. For example, this may be because STA3 does not hear the response sent by STA2 with sufficient power. For example, this may be because STA3 and STA2 are far apart. In this case, STA3 may not successfully start PPDU reception within the NAVTimeout period described in FIG. 23. However, in this case, STA3 can successfully start PPDU reception within the extended NAVTimeout period. Therefore, STA3 does not need to perform a NAV timeout operation. The reason why STA3 was able to wait for the extended NAVTimeout period without performing NAV cancellation operation when the NAVTimeout period described in Figure 23 elapsed may be because the frame in which STA3 set the NAV was an MU-RTS frame, which is a modified MU-RTS frame.

[0298] If STA2 fails to respond after receiving the modified MU-RTS frame, STA1 can perform a recovery operation, thereby successfully starting PPDU reception before STA3 performs a NAV timeout operation.

[0299] Alternatively, if STA2 receives the modified MU-RTS frame but fails to respond, the shared TXOP sequence may be terminated. In this case, STA3 performs a NAV timeout operation to solve the problem of being unable to connect to the channel due to unnecessary NAV settings when no actual frame exchange occurs.

[0300] In TXOP sharing, a scheduled STA that receives a part or all of the TXOP set by the AP has difficulty transmitting according to the set NAV, and a solution to this problem has been described with reference to Figure 20. A solution according to another embodiment will be described with reference to Figure 27. Hereinafter, the scheduled STA and the STA that shares the TXOP are the same STA and may be used interchangeably.

[0301] FIG. 27 is a diagram illustrating STAs and APs applying 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 its NAV. Specifically, in TXOP sharing, a scheduled STA does not need to set its NAV based on a modified MU-RTS frame or an MU-RTS TXS trigger frame, which is an MU-RTS frame for TXOP sharing configuration. A STA that receives an MU-RTS frame for TXOP sharing configuration does not need to set its NAV based on the MU-RTS frame for TXOP sharing configuration. A STA scheduled by an MU-RTS frame for TXOP sharing configuration does not need to set its NAV based on the MU-RTS frame for TXOP sharing configuration. Therefore, when a STA receives a trigger frame that schedules the STA for TXOP sharing, the STA does not need to set its NAV based on the trigger frame. That is, the STA can set its NAV based on the received trigger frame depending on whether the trigger frame is a trigger frame for TXOP sharing. For example, if the received MU-RTS frame is a modified MU-RTS frame for TXOP sharing or an MU-RTS TXS trigger frame, the STA does not set its 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 an MU-RTS TXS trigger frame, the STA sets its NAV based on the received MU-RTS frame.

[0303] Also, in TXOP sharing, scheduled STAs do not need to set their NAV based on frames received within the shared TXOP.

[0304] In this case, "within a shared TXOP" may refer to the period until the shared TXOP ends, even if the entire duration of the shared TXOP is not utilized. If a scheduled STA of the shared TXOP transmits a PPDU, and the PPDU contains only frames that do not request an immediate response, the TXOP ends when the STA transmits the PPDU. Therefore, "within a shared TXOP" may be the period from when TXOP sharing is established until when a scheduled STA of the TXOP sharing transmits a PPDU containing only frames that do not request an immediate response. The shared TXOP may end when a scheduled STA of the TXOP sharing signals the end of the shared TXOP. Therefore, "within a shared TXOP" may be the period from when TXOP sharing is established until when a scheduled STA of the TXOP sharing signals the end of the shared TXOP. Furthermore, "within a TXOP" may be the period from when TXOP sharing is established until the shared TXOP duration has elapsed. Alternatively, the shared TXOP may end when the STA that received the TXOP (or the STA that shared the TXOP) sends or receives signaling indicating that the shared TXOP will end. In this case, the duration of the shared TXOP is the same as that of the TXOP used by the AP for sharing (the TXOP acquired by the AP's frame at the beginning), or the duration of the shared TXOP is shorter than that of the TXOP. Therefore, the TXOP does not have to be terminated even if the shared TXOP is terminated. In other words, if the duration of the shared TXOP is the same as that of the TXOP, the TXOP is also terminated when the shared TXOP is terminated. However, if the duration of the shared TXOP is shorter than that of the TXOP, the TXOP may be maintained even if the shared TXOP is terminated.

[0305] In yet another specific embodiment, within the shared TXOP period may be from when the TXOP sharing is established to when the shared TXOP duration has elapsed, even if the shared TXOP ends before the shared TXOP duration.

[0306] As described above, in TXOP sharing, a scheduled STA can transmit frames regardless of its NAV. That is, if a NAV is set in a TXOP set by the AP (e.g., a NAV set by an intra-BSS PPDU), the scheduled STA can transmit a PPDU in the shared TXOP regardless of the set NAV. In other words, a STA that receives a shared TXOP can transmit frames in the shared TXOP while ignoring the NAV set in a frame transmitted by the STA that shared the TXOP. In this case, the shared TXOP may end before the interval set by the MU-RTS frame. That is, a STA that receives a shared TXOP before the interval set by the MU-RTS frame in the shared TXOP can discontinue sharing the TXOP by transmitting signaling to request discontinuation of TXOP sharing. For example, if a non-AP STA receives all or part of a shared TXOP from the AP and has no PPDUs to send (or pending), it can discontinue sharing the TXOP by transmitting signaling to the AP to terminate TXOP sharing. The TXOP sharing may be discontinued when a non-AP STA transmits signaling requesting discontinuation of TXOP sharing or when a response frame to the signaling is received. In this case, the signaling for TXOP sharing may or may not require an immediate response. In this case, the non-AP STA can ignore the NAV set only until the TXOP sharing ends, since TXOP sharing is discontinued earlier than the TXOP sharing period set by the MU-RTS frame.

[0307] In this case, the STA that set up TXOP sharing can also transmit frames regardless of the NAV. In the embodiment of FIG. 27, the first STA (STA1) transmits an 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 in 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 set its NAV based on a frame transmitted by or to the second STA (STA2). For example, the second STA (STA2) can exchange frames with a third STA (STA3) within the shared TXOP. In this case, the first STA (STA1) can set its NAV based on a frame transmitted by the third STA (STA3) to the second STA (STA2). In addition, the first STA (STA1) may set its NAV based on a frame transmitted by the second STA (STA2) to the third STA (STA3). When the first STA (STA1) sets its NAV in this manner, it may be difficult for the shared TXOP to transmit a frame within the assigned TXOP. For example, when the first STA (STA1) attempts to transmit a frame after the shared TXOP ends, it may be unable to transmit the frame due to the NAV set within the shared TXOP. Specifically, if the frame included in the PPDU transmitted within the shared TXOP is not a frame that elicits an immediate response from the first STA (STA1), the first STA (STA1) may be unable to transmit the frame due to the set NAV.

[0308] The STA that set up the TXOP sharing can transmit frames within the TXOP that the STA acquired regardless of the NAV. In yet another specific embodiment, the STA that set up the TXOP sharing can transmit frames within the TXOP acquired from the time the shared TXOP ends regardless of the NAV. The STA that set up the TXOP sharing can be the STA that sent the MU-RTS frame to set up the TXOP sharing or the TXOP holder.

[0309] As described above, the shared TXOP may be terminated before the interval set by the MU-RTS frame. That is, before the interval set by the MU-RTS in the shared TXOP, the STA that received the TXOP sharing can terminate the TXOP sharing by transmitting signaling to request termination of the TXOP sharing. For example, when a non-AP STA receives all or part of the TXOP from the AP, if there is no PPDU to transmit (or pending), the STA can terminate the TXOP sharing by transmitting signaling to terminate the TXOP sharing to the AP to terminate the shared TXOP. The TXOP sharing can be terminated at one of the times when the non-AP STA transmits signaling requesting termination of the TXOP sharing or when it receives a response frame to the signaling. In this case, the signaling for TXOP sharing may or may not require an immediate response. In this case, since TXOP sharing is interrupted earlier than the period in which the TXOP set by the MU-RTS frame is shared, from the point at which TXOP sharing ends, the AP can ignore the NAV set by the AP based on the PPDU sent and received by the non-AP STA.

[0310] In the above-described embodiment, the STA that set up the TXOP sharing to transmit a frame regardless of the NAV may indicate that the STA transmits the frame regardless of the NAV set based on a frame exchanged by a scheduled STA within the TXOP sharing. If the STA that set up the TXOP sharing transmits a frame regardless of the NAV set based on a frame not exchanged by a scheduled STA within the TXOP sharing, it may interfere with the frame exchange of other STAs. Furthermore, the STA may determine whether a frame has been exchanged by a scheduled STA within the TXOP sharing based on the MAC header of the frame. Specifically, the STA may determine whether a frame has been 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, the TA field, and the BSSID field. For example, if one of the address fields of the frame indicates the MAC address of the STA, the STA may determine whether the frame has been exchanged by a scheduled STA within the TXOP sharing. Furthermore, the STA may determine whether a frame has been exchanged by a scheduled STA within the TXOP sharing based on the preamble of the PPDU containing the frame. Furthermore, a STA can determine whether a frame is exchanged by a scheduled STA within TXOP sharing based on at least one of a BSS color and a STA ID included in the preamble of a PPDU containing the frame. If the preamble of a PPDU includes a BSS color of a BSS to which a scheduled STA of TXOP sharing belongs and the preamble of a PPDU includes a STA ID corresponding to the scheduled STA of TXOP sharing, the STA can determine that the frame included in the PPDU is a frame exchanged by a scheduled STA. In this case, the STA ID may be a value set based on the AID of the STA.

[0311] In yet another specific embodiment, a STA configured for TXOP sharing that transmits regardless of NAV can only use physical carrier sensing (CS), such as CCA, when transmitting frames, and therefore does not need to perform virtual carrier sensing.

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

[0313] The MU-RTS frame for setting TXOP sharing can indicate the scheduled STA of the TXOP using a MAC address, for example, the RA field or the User Info field. Setting the NAV based on the duration information of the frame or PPDU can indicate that the last set NAV is set based on the duration information of the frame or PPDU.

[0314] In yet another specific embodiment, the Duration / ID field of a frame transmitted within a shared TXOP or the TXOP of a PPDU including 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 including the frame may not be allowed to be set to exceed the shared TXOP. This prevents a problem in which a STA that has set a shared TXOP cannot transmit frames even after the shared TXOP ends.

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

[0316] In yet another specific embodiment, the STA that established the shared TXOP may not set its NAV based on frames exchanged by the scheduled STAs that share the TXOP.

[0317] The STA that established the shared TXOP within the shared TXOP may not need to send a trigger frame. This is because if the STA that established the shared TXOP within the shared TXOP sends a trigger frame, the frame triggered by the trigger frame may overlap with the frame exchange of the scheduled STA. Also, if the STA that established the shared TXOP within the shared TXOP sends a trigger frame to the scheduled STA, the scheduled STA may need to send a response to the trigger frame. Therefore, this may not fulfill the purpose of establishing the shared TXOP. In such an embodiment, the trigger frame may include an MU-RTS frame for establishing TXOP sharing. In such an embodiment, the STA that established the shared TXOP may send a trigger frame after the shared TXOP ends.

[0318] In the above-described embodiment, the trigger frames that the STA that set the shared TXOP cannot transmit may be the remaining trigger frames excluding trigger frames for only the scheduled STAs that share the TXOP. Therefore, the STA that set the shared TXOP can transmit trigger frames only to the scheduled STAs that share the TXOP within the shared TXOP. For example, the STA that set the shared TXOP can transmit an MU-RTS frame to set up TXOP sharing to extend the shared TXOP. In this case, the STA that receives the MU-RTS frame to set up TXOP sharing can initiate frame exchange without transmitting a CTS frame. Specifically, if frame exchange is only permitted with the STA that set up TXOP sharing in TXOP sharing, the STA that receives the MU-RTS frame to set up TXOP sharing can initiate frame exchange without transmitting a CTS frame.

[0319] In this specification, an action performed on a shared TXOP may be an action utilizing the shared TXOP by a scheduled STA sharing the TXOP. The action performed on the shared TXOP may be a frame transmitted by the scheduled STA sharing the TXOP in response to an MU-RTS frame for establishing TXOP sharing, or a frame transmitted by the scheduled STA sharing the TXOP within the shared TXOP. In this case, the response frame to the MU-RTS frame for establishing TXOP sharing may be a CTS frame.

[0320] Signaling for TXOP sharing will now be described. A STA can signal whether it can operate as a scheduled STA for TXOP sharing. In this case, the STA can signal whether it can operate as a scheduled STA for TXOP sharing using the EHT Capabilities element. The STA can also transmit signaling indicating whether it can operate as a scheduled STA for TXOP sharing using a (re)association request frame or a probe request frame. A STA attempting to establish TXOP sharing can transmit an MU-RTS frame for establishing TXOP sharing only to a STA that has signaled that it can operate as a scheduled STA for TXOP sharing. A STA attempting to establish TXOP sharing may not transmit an MU-RTS frame for establishing TXOP sharing to a STA that has signaled that it cannot operate as a scheduled STA for TXOP sharing.

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

[0322] In the above embodiment, the GI and HE-LTF Type subfield may indicate whether the MU-RTS frame is an MU-RTS frame for setting TXOP sharing. If the MU-RTS frame is an MU-RTS frame for setting TXOP sharing, the GI and HE-LTF Type subfield may indicate the TXOP sharing mode, as described above. In this case, the GI and HE-LTF Type subfield may be referred to as the TXOP Sharing Mode subfield. The TXOP Sharing Mode subfield may be a subfield from the 21st bit (B20) to the 22nd bit (B21) of the Common Info field in FIG. 16.

[0323] A method for ending TXOP sharing is illustrated in FIG.

[0324] FIG. 28 is a diagram illustrating a STA ending TXOP sharing according to one embodiment of the present invention.

[0325] A scheduled STA sharing a TXOP can signal the end of TXOP sharing. When the STA that set up the TXOP sharing receives the end of TXOP sharing signaling, the STA that set up the TXOP sharing can become the TXOP holder. Also, when the STA that set up the TXOP sharing receives the end of TXOP sharing signaling, the STA that set up the TXOP sharing can transmit frames or PPDUs. Specifically, when the STA that set up the TXOP sharing receives the end of TXOP sharing signaling, the STA that set up the TXOP sharing can transmit frames or PPDUs even within the shared TXOP. Also, when a scheduled STA sharing a TXOP signals the end of TXOP sharing, the scheduled STA sharing a TXOP may not be able to transmit any frames or PPDUs within the remaining shared TXOP.

[0326] A scheduled STA for 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. A STA that receives the SRS Control subfield can respond to a frame including the SRS Control subfield with a PPDU that is not a TB PPDU. In addition, the length of a response PPDU for a frame including the SRS Control subfield can be determined based on the SRS Control subfield. Specifically, a STA that receives the SRS Control subfield can set the length of a response PPDU for a frame including 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 indicating the length of the PPDU, which is a response to the MAC frame including the SRS Control subfield. In this case, the field may be called a PPDU Response Duration field. The PPDU Response Duration field may indicate time in 4us units. The PPDU length indicated by the PPDU Response Duration field may be the value of the PPDU Response Duration field x 4us. Furthermore, the PPDU Response Duration field may be an 8-bit field.

[0328] In addition, a STA can signal its capability for the SRS Control subfield. Specifically, a STA can signal whether it can receive the SRS Control subfield. A STA can also signal whether it can respond to a frame including the SRS Control subfield. A STA may not be able to transmit the SRS Control subfield to a STA that has signaled that it does not support operation on the SRS Control subfield. A STA can transmit the SRS Control subfield to a STA that has signaled that it supports operation on the SRS Control subfield.

[0329] The SRS Control field may also include a field that signals the termination of TXOP sharing. The field that signals the termination of TXOP sharing may be referred to as a Shared TXOP Termination field. The Shared TXOP Termination field may be a 1-bit field. If the value of the Shared TXOP Termination field is 1, the Shared TXOP Termination field may indicate that TXOP sharing is terminated. If the value of the Shared TXOP Termination field is 0, the Shared TXOP Termination field may indicate that TXOP sharing is not terminated. If a STA receives a QoS Data frame or a QoS Null frame with a Shared TXOP Termination field value of 1, the STA can determine that TXOP sharing is terminated.

[0330] In yet another specific embodiment, a frame having a pre-specified setting may signal the end of TXOP sharing. In this case, the frame having a pre-specified setting may be a QoS Null frame. Specifically, the frame having a pre-specified setting may be a QoS Null frame that does not include an A-Control subfield. Alternatively, the frame having a pre-specified setting may be a QoS Null frame that does not include an SRS Control subfield. A scheduled STA for TXOP sharing may signal the end of TXOP sharing by transmitting a frame having a pre-specified setting. Furthermore, when a STA that set up TXOP sharing receives a frame having a pre-specified setting, the STA that set up TXOP sharing may determine that TXOP sharing will end.

[0331] A scheduled STA for TXOP sharing may transmit TXOP sharing termination signaling, but the STA that set the TXOP sharing may not receive the signaling. In this case, the scheduled STA for TXOP sharing may determine that TXOP sharing has terminated and may not transmit a frame. Also, the STA that set the TXOP sharing may determine that TXOP sharing has not terminated and may not transmit a frame.

[0332] In a specific embodiment, when a scheduled STA sharing a TXOP that has signaled the end of TXOP sharing receives a response to the signaling, the scheduled STA can determine that TXOP sharing has ended. In this case, the scheduled STA sharing a TXOP may determine that TXOP sharing has ended and not transmit a frame. The response to the signaling for ending TXOP sharing may be an immediate response. Alternatively, the response to the signaling for ending TXOP sharing may be an ACK. However, this embodiment may only be applied when the ACK policy for the signaling for ending TXOP sharing is set to require an immediate response. Specifically, if the ACK policy for the signaling for ending TXOP sharing requires an immediate response, the scheduled STA sharing a TXOP that has signaled the end of TXOP sharing may determine that TXOP sharing has ended when it receives a response to the signaling. When the ACK policy for the TXOP sharing termination signaling does not require an immediate response, e.g., No ACK, even if the TXOP sharing scheduled STA that signaled the TXOP sharing termination does not receive a response to the signaling, the TXOP sharing scheduled STA can determine that TXOP sharing has terminated. In this case, the TXOP sharing scheduled STA can determine that TXOP sharing has terminated when it transmits the TXOP sharing termination signaling. Furthermore, if the TXOP sharing termination signaling transmission fails, an error recovery operation may be performed. Specifically, the TXOP sharing scheduled STA can perform an error recovery operation. Furthermore, the STA that set up the TXOP sharing can perform an error recovery operation.

[0333] In FIG. 28(b), the first STA (STA1) transmits an MU-RTS frame for TXOP sharing setup 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 setup and transmits a CTS frame in response to the MU-RTS frame for TXOP sharing setup. Within the shared TXOP, the second STA (STA2) transmits TXOP sharing termination signaling (Frame to STA1 indicating termination) to the first STA (STA1). The first STA (STA1) fails to receive the TXOP sharing termination signaling (Frame to STA1 indicating termination). In this case, the first STA (STA1) determines that TXOP sharing has not terminated. As described above, the first STA (STA1) or the second STA (STA1) can perform error recovery operations. After the error recovery operation, the second STA (STA2) sends TXOP sharing termination signaling (Frame to STA1 indicating termination) to the first STA (STA1). The first STA (STA1) sends ACK (Ack to STA2) to the second STA (STA2) as a response to the TXOP sharing termination signaling (Frame to STA1 indicating termination). Upon receiving the ACK (Ack to STA2), the second STA (STA2) determines that TXOP sharing has ended.

[0334] Even after the TXOP sharing has ended, the scheduled STA of the TXOP sharing can transmit frames if the STA that set up the TXOP sharing indicates a response.

[0335] As described above, it may be impossible to transmit an SRS Control subfield to a STA that has signaled that it does not support operations on the SRS Control subfield. When the SRS Control subfield signals the termination of TXOP sharing, a STA that has signaled that it does not support operations on the SRS Control subfield may not receive the TXOP sharing termination signaling. Therefore, a scheduled STA for TXOP sharing may transmit an SRS Control subfield signaling the termination of TXOP sharing to a STA that has signaled that it does not support operations on the SRS Control subfield. The SRS Control subfield signaling the termination of TXOP sharing may be an SRS Control subfield with a TXOP Termination subfield value of 1. A scheduled STA for TXOP sharing may not transmit an SRS Control subfield with a TXOP Termination subfield value of 0 to a STA that has signaled that it does not support operations on the SRS Control subfield. Furthermore, the restriction that an SRS Control subfield cannot be transmitted to a STA that has signaled that it does not support operations on the SRS Control subfield may only apply when the SRS Control subfield is transmitted outside a 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 a response to the frame containing the SRS Control subfield.

[0337] If the SRS Control subfield signals the end of TXOP sharing, the STA that received the SRS Control subfield does not need to transmit a response to the frame including the SRS Control subfield. In yet another specific embodiment, if the SRS Control subfield signals the end of TXOP sharing, the STA that received the SRS Control subfield can transmit a response to the frame including the SRS Control subfield regardless of the information signaled by the SRS Control field. In this case, the STA that received the SRS Control subfield can transmit a response PPDU regardless of the length of the response PPDU signaled by the SRS Control subfield for the frame including the SRS Control subfield.

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

[0339] Alternatively, a STA receiving an SRS Control subfield in a shared TXOP may not respond based on the duration information (PPDU Response Duration subfield value) included in the SRS Control subfield. For example, a STA receiving an SRS Control subfield in a shared TXOP may be able to respond regardless of the duration information (PPDU Response Duration subfield value) included 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 a TXOP. For example, the TXOP holder may send another frame rather than the modified MU-RTS frame to obtain the TXOP. This allows the STA to set its NAV before setting it based on the modified MU-RTS frame. That is, the STA can set its NAV based on a frame transmitted before the modified MU-RTS frame in the TXOP. The NAV timeout operation described above can be performed when the NAV is set based on an RTS frame or MU-RTS frame. However, by ensuring that a frame transmission exists before the modified MU-RTS frame in the TXOP, it is possible to reduce the need to set the NAV based on an RTS frame or MU-RTS frame. Furthermore, the duration information contained in the modified MU-RTS frame does not need to increase the TXOP.

[0341] FIG. 29 illustrates a method for signaling the format of a TB PPDU responding to a trigger frame using the Common Info field and Special User Info field contained in the trigger frame according to an embodiment of the present invention.

[0342] In an embodiment of the present invention, a station receiving a trigger frame can determine the format of a TB PPDU based on the User Info field included in the trigger frame. Specifically, the special User Info field included in the trigger frame can indicate the format of a TB PPDU to be transmitted in response to the trigger frame. For convenience of explanation, the special User Info field is referred to as a 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 the AP does not assign as an AID (association ID). In addition, the format of the Special User Info field may be different from the format of a User Info field that is not the Special User Info field. The format of the subfields included in the Special User Info field may be different from the format of the subfields included in User Info fields that are not the Special User Info field. In this case, the format of the AID12 subfield included in the Special User Info field may be the same as the format of the AID12 subfield included in User Info fields that are not the Special User Info field. Therefore, the first 12 bits of the Special User Info field, i.e., the value of AID12, may be set to a pre-specified value. This allows the HE station to parse a trigger frame that includes the Special User Info field without error.

[0344] The trigger frame may also include a subfield indicating whether the trigger frame includes a Special User Info field. For convenience of explanation, the subfield indicating whether the trigger frame includes a Special User Info field is referred to as a Special User Info Field Present field. Specifically, the Common Info field of the trigger frame may include a 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 may not include a Special User Info field. Also, if the value of the Special User Info Field Present subfield is 0, the trigger frame may include a Special User Info field. This is because the 56th bit of the Common Info field of a legacy trigger frame is basically set to 1 (default). A station receiving the trigger frame can determine whether the trigger frame includes a Special User Info field based on the Special User Info field. If the value of the Special User Info Field Present subfield of the trigger frame received by the station is 1, the station can determine that the trigger frame does not contain a Special User Info field. Also, if the value of the Special User Info Field Present subfield of the trigger frame received by the station is 0, the station can determine that the trigger frame contains a Special User Info field.As in the above-mentioned embodiment, when the Special User Info Field Present subfield is included in the trigger frame, even if a station that is not associated with the AP receives the trigger frame, it can determine whether the Special User Info field is included in the trigger frame.

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

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

[0347] The way in which the User Info field of an EHT variant indicates an RU may differ from the way in which the User Info field of an HE variant indicates an RU. Specifically, the way in which the RU Allocation subfield of the User Info field of an EHT variant indicates an RU may differ from the way in which the RU Allocation subfield of the User Info field of an HE variant indicates an RU. For example, the RU Allocation subfield of the User Info field of an EHT variant can indicate an RU index for the User Info field of an EHT variant. Also, the RU Allocation subfield of the User Info field of an HE variant can indicate an RU index for the User Info field of an HE variant. The User Info field of an EHT variant can indicate an RU allocated to a station corresponding to the User Info field using the RU Allocation subfield and the PS160 subfield.

[0348] As described in FIG. 16, the RU Allocation subfield may be located immediately after the AID12 subfield. The RU Allocation subfield may be an 8-bit field. The PS160 subfield may 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 bandwidth of the subchannel may be 160 MHz. Specifically, the PS160 subfield may indicate whether the RU indicated by the RU Allocation subfield of the User Info field containing the PS160 subfield is located on the primary 160 MHz channel or the secondary 160 MHz channel. The PS160 subfield may be located immediately before the Trigger Dependent User Info subfield. The PS160 subfield may be 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 indicate the RU allocated to the station corresponding to the User Info field.

[0350] In the embodiment of Figure 29, a station receiving a trigger frame can determine the subfield indicating the format of the TB PPDU to be transmitted in response to the trigger frame on a pre-designated channel and the format of the subfield indicating the format of the TB PPDU to be transmitted in response to the trigger frame based on the Special User Info field of the trigger frame. In this case, the pre-designated channel may be the primary 160 MHz channel. For convenience of explanation, the subfield indicating the format of the TB PPDU to be transmitted in response to the trigger frame is referred to as the HE / EHT P160 subfield. If the HE / EHT P160 subfield indicates that the format of the TB PPDU to be transmitted in response to the trigger frame on the primary 160 MHz channel is EHT TB PPDU, the station receiving the trigger frame can transmit the EHT TB PPDU in 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. Also, if the HE / EHT P160 subfield indicates the format of the TB PPDU sent in response to the trigger frame on the primary 160 MHz channel as EHT TB PPDU, the trigger frame may always include a Special User Info field.

[0351] When the HE / EHT P160 subfield indicates the format of the TB PPDU transmitted in response to the trigger frame on the primary 160 MHz channel as HE TB PPDU, a station receiving the trigger frame can determine the format of the TB PPDU transmitted in 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, when the HE / EHT P160 subfield indicates the format of the TB PPDU transmitted in response to the trigger frame on the primary 160 MHz channel as HE TB PPDU and the RU assigned to the station receiving the trigger frame is not included in the primary 160 MHz, the station can transmit the EHT TB PPDU in response to the trigger frame. Furthermore, the HE / EHT P160 subfield indicates the format of the TB PPDU transmitted in response to the trigger frame on the primary 160 MHz channel as HE TB PPDU, and if the RU assigned to the station receiving the trigger frame is included in the primary 160 MHz channel, the station can transmit the HE TB PPDU in response to the trigger frame. At this time, the station can determine whether the RU assigned to the station is included in the primary 160 MHz 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, when a trigger frame includes a 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 the Special User Info field to which this embodiment is applied.

[0353] The above-mentioned EHT TB PPDU may be replaced with a NEXT TB PPDU. Therefore, in the above-mentioned embodiment, if the EHT TB PPDU is indicated as the TB PPDU format, the NEXT TB PPDU or the EHT TB PPDU may be transmitted as the TB PPDU. In this case, a station receiving a trigger frame can determine which PPDU, the EHT TB PPDU or the NEXT TB PPDU, to transmit in response to the trigger frame based on the Format Identifier subfield. Specifically, the station can transmit the TB PPDU according to the TB PPDU format indicated by the Format Identifier subfield.

[0354] The Special User Info field may include information required when transmitting an EHT TB PPDU in response to the trigger frame. Specifically, the Special User Info field may include information required to set the signaling field of the PPDU of the EHT TB PPDU transmitted in response to the trigger frame. In this case, the signaling field of the PPDU may be a U-SIG field. In FIG. 29, the Special User Info field may include an AID12 subfield, a PHY Version ID subfield, a UL Bandwidth Extension subfield, a Spatial Reuse 1 subfield, a Spatial Reuse 2 subfield, a U-SIG Disregard And Validate subfield, a Reserved subfield, and a Trigger Dependent User Info field subfield. In this case, the AID12 subfield may be a 12-bit field. Furthermore, the PHY Version ID subfield may be a 2-bit field. The UL Bandwidth Extension subfield may be a 2-bit field. Furthermore, the Spatial Reuse 1 subfield may be a 4-bit field. 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 FIG. 29.

[0355] The PHY Version ID subfield may be the aforementioned Format Identifier subfield, PHY version identifier subfield, or PHY version subfield. When the value of the PHY version ID subfield is set to 0, the PHY version ID subfield may indicate an EHT physical layer. A station that receives a trigger frame can set the U-SIG field of a TB PPDU to be transmitted in response to the trigger frame based on the Special User Info field. Specifically, a station that receives a trigger frame can set the value of a subfield included in the Special User Info field to the value of a subfield of the U-SIG field of the TB PPDU. In this case, the subfields of the U-SIG field may include a PHY Version ID subfield, a Spatial Reuse 1 subfield, a Spatial Reuse 2 subfield, and a U-SIG Disregard And Validate subfield. In addition, a station receiving a 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 the trigger frame can perform spatial reuse (SR) operation based on the Spatial Reuse 1 subfield or the Spatial Reuse 2 subfield. Specifically, if a station that receives the trigger frame determines that the trigger frame is an inter-BSS frame, the station can perform SR operation. SR operation may be a type of channel access. When a station performs SR operation, the station can transmit a PPDU based on the information included in the trigger frame and the transmission power of the PPDU to be transmitted in 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] The trigger frame can also indicate a frequency bandwidth using the UL BW subfield of the Common Info field and the UL Bandwidth Extension subfield of the Special User Info field. Therefore, a station receiving the trigger frame can determine the frequency bandwidth indicated by the trigger frame based on the UL BW subfield of the Common Info field and the UL Bandwidth Extension subfield of the Special User Info field. The UL BW subfield of the Common Info field and the UL Bandwidth Extension subfield of the Special User Info field can indicate 20 MHz, 40 MHz, 80 MHz, 160 MHz, and 320 MHz. The UL BW subfield and the UL Bandwidth Extension subfield can indicate the 320 MHz frequency band by distinguishing between 320-1 MHz and 320-2 MHz 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 160 MHz can indicate any one of 160 MHz, 320 MHz-1, and 320 MHz-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 the UL Bandwidth Extension subfield together may be as shown in Table 2.

[0359] [Table 2]

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

[0361] The presence or absence and length of the Trigger Dependent User Info subfield included in the Special User Info field may be determined based on the type of trigger frame. That is, the presence or absence and length of the Trigger Dependent User Info subfield included in the Special User Info field may be determined based on which variant the trigger frame corresponds to. The type of trigger frame may be indicated by the Trigger Type subfield included in 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 may indicate a basic trigger frame, a Beamforming Report Poll (BFRP) frame, an MU-BAR frame, an MU-RTS frame, a Buffer Status Report Poll (BSRP) frame, a GCR MU-BAR frame, a Bandwidth Query Report Poll (BQRP) frame, and an NDP Feedback Report Poll (NFRP) frame, respectively.

[0362] In the above embodiment, an HE station that transmits a TB PPDU based on the RA-RU of a trigger frame can transmit the HE TB PPDU based on the RA-RU even when the trigger frame includes a Special User Info field. A method for solving this problem will be described below.

[0363] A station can determine the format of a TB PPDU to be transmitted as a response to a trigger frame depending 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 transmit an HE TB PPDU as a response to the trigger frame. Also, if the User Info field corresponding to the station in the trigger frame is the ETH variant, the station can transmit an EHT TB PPDU as a response to the trigger frame. Also, if the User Info field corresponding to the station in the trigger frame is the NEXT variant, the station can transmit a NEXT TB PPDU as a response to the trigger frame.

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

[0365] The MU-RTS frame may include the Special User Info field described above. Specifically, a modified MU-RTS frame may include the Special User Info field. The MU-RTS frame may indicate the bandwidth in which the MU-RTS frame is transmitted. Furthermore, the modified MU-RTS frame may allocate a shared TXOP as described above. The modified MU-RTS frame may indicate the frequency bandwidth used in the shared TXOP. If a frequency bandwidth exceeding 160 MHz is used in the shared TXOP, the modified MU-RTS frame may indicate the frequency bandwidth exceeding 160 MHz using the Special User Info field. Specifically, according to the embodiment described in FIG. 29, the Special User Info field may indicate the frequency bandwidth exceeding 160 MHz. In such an embodiment, the remaining fields of the Special User Info field, except for the UL Bandwidth Extension field, may be set as reserved fields. Specifically, the values ​​of the remaining fields of the Special User Info field, except for the UL Bandwidth Extension field, may be set to 0. Also, the UL Bandwidth Extension field of the Special User Info field may be set according to the embodiment described in FIG. 29 above.

[0366] FIG. 30 illustrates 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 for setting the TXVECTOR parameter when a station responds to a modified MU-RTS frame may differ from the method for setting the TXVECTOR parameter when a station responds to a non-modified MU-RTS frame. In this case, the TXVECTOR parameter may include TRIGGER_RESPONDING. TRIGGER_RESPONDING 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, the station transmits 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 transmitted from the physical layer to the MAC layer.

[0368] The TRIGGER_RESPONDING parameter of the TXVECTOR parameter may be set when a non-HT PPDU or a 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 a non-HT duplicate PPDU is transmitted.

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

[0370] Furthermore, the transmission conditions of a station may vary depending on the value of the TRIGGER_RESPONDING parameter of the TXVECTOR. For example, when the TRIGGER_RESPONDING parameter of the TXVECTOR is set to true, the station can transmit according to pre-specified transmission conditions. When the TRIGGER_RESPONDING parameter of the TXVECTOR is set to false, the station can transmit regardless of the pre-specified transmission conditions or according to transmission conditions that are more lenient than the pre-specified transmission conditions. Therefore, the transmission conditions that a station must follow may vary depending on whether the station transmits a TB PPDU. Specifically, when a station transmits a TB PPDU, the station can transmit according to pre-specified conditions. When a station transmits a PPDU that is not a TB PPDU, the station can transmit regardless of the pre-specified conditions or according to transmission conditions that are more lenient than the pre-specified conditions. When a station transmits a non-HT (duplicate) PPDU or a TB PPDU in response to an MU-RTS frame, multiple stations can transmit PPDUs simultaneously. Therefore, depending on the transmission parameter settings of multiple stations, it may be difficult for a station receiving a PPDU to receive the PPDU. In addition, the transmission of multiple PPDUs may not be synchronized, which may cause interference between the multiple PPDU transmissions. In addition, the transmission power difference between multiple PPDUs may increase.

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

[0372] Specifically, a station can correct carrier frequency offset (CFO) errors and symbol clock errors when transmitting a triggering PPDU, i.e., a PPDU including trigger information, as follows: 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 TRIGGER_RESPONDING set to true in the TXVECTOR parameter

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

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

[0375] The residual carrier frequency offset error measurement for a non-HT PPDU or non-HT duplicate PPDU should be performed after the L-STF field. The symbol clock error needs to be compensated for up to the ppm amount of the carrier frequency offset error only.

[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 shall ensure that the start of transmission 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.4µs ​​+ 16µs of 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 response to a modified MU-RTS frame can be transmitted by a single station, so the transmission of a response to a modified MU-RTS frame does not require the above-described pre-specified transmission conditions, or the pre-specified transmission conditions may be relaxed.

[0378] A station can set the TRIGGER_RESPONDING parameter of the TXVECTOR parameter differently when transmitting a response to a modified MU-RTS frame and when transmitting a response to a non-modified MU-RTS frame. Specifically, when a station transmits a response to a modified MU-RTS frame, the station can set the value of the TRIGGER_RESPONDING parameter of the TXVECTOR parameter to false. Also, when a station transmits a response to a non-modified MU-RTS frame, the station can set the value of the TRIGGER_RESPONDING parameter of the TXVECTOR parameter to true. As described above, this embodiment can be applied when a station transmits a non-HT PPDU or a non-HT duplicate PPDU.

[0379] In the example of Figure 30, the first station (STA1) transmits an MU-RTS frame that is not a modified MU-RTS frame. The second station (STA2) transmits a CTS frame in response to the non-modified MU-RTS frame. As in the previous example, the second station transmits a CTS frame by setting the value of TRIGGER_RESPONDING in the TXVECTOR parameter 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 a response to the modified MU-RTS frame by setting the value of TRIGGER_RESPONDING in the TXVECTOR parameter to false.

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

[0381] FIG. 31 shows the configuration of a management frame and an 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. The channel access may include enhanced distributed channel access (EDCA). The EDCA parameter set may include an EDCA parameter set for each access category (AC). The AC-specific EDCA parameter sets included in one EDCA parameter set may have different parameter values. When the multiple EDCA parameter sets are classified into a first EDCA parameter set and a second parameter set, the EDCA parameter values ​​of the first EDCA parameter set for one AC may be different from the EDCA parameter values ​​of the second EDCA parameter set. The ACs may include best effort (AC_BE), background (AC_BK), video (AC_VI), and voice (AC_VO).

[0383] EDCA provides CSMA / CA access according to the priority of each traffic, specifically, AC. The multiple EDCA parameter sets may include a legacy EDCA parameter set and an MU EDCA parameter set. Specifically, the multiple EDCA parameter sets may be divided into a legacy EDCA parameter set and an MU EDCA parameter set. The legacy EDCA parameter set may be stored in dot11EDCATable, and the MU EDCA parameter set may be stored in dot11MUEDCATable. The EDCA parameter set may include CWmin, CWmax, AIFSN, TXOP limit, and MSDU lifetime. The MU EDCA parameter set may include CWmin, CWmax, AIFSN, and MUEDCATimer. As described above, the EDCA parameter set may include parameter values ​​for each AC. Therefore, the EDCA parameter set may be represented as CWmin[AC], CWmax[AC], AIFSN[AC], TXOP limit[AC], and MSDU lifetime[AC]. Additionally, the MU EDCA parameter sets may be denoted as CWmin[AC], CWmax[AC], AIFSN[AC], and MUEDCATimer[AC].

[0384] According to one embodiment, the contention window (CW) may be determined based on CWmin or CWmax. Furthermore, the CW may be used when invoking a backoff procedure, resetting a backoff counter, or selecting a new one. For example, a randomly selected number from integers between 0 and CW may be used as the backoff counter. Furthermore, when the CW is initialized, it may be initialized to CWmin. Furthermore, the minimum value that the CW can have may be CWmin. Furthermore, the maximum value that the CW can have may be CWmax.

[0385] The AIFS described in FIG. 6 may be determined based on the AIFSN (arbitration interframe space number). For example, the AIFS may be AIFSN*(slot time (aSlotTime))+SIFS (aSIFSTime). Specifically, the AIFS may be the time a station waits before attempting channel access again after detecting that the channel is busy. The AIFS may also determine the slot boundary used when a station attempts channel access again after detecting that the channel is busy.

[0386] A station that acquires a TXOP (transmit opportunity) can determine the end point of a transmission sequence based on the TXOP limit. Specifically, a station generally ends a transmission sequence within the TXOP limit, but in some exceptional circumstances, a transmission sequence with a duration exceeding the TXOP limit may be permitted.

[0387] A station can receive an element indicating the value of a parameter in an EDCA parameter set from an associated AP and set the EDCA parameter set according to the value of the parameter in the EDCA parameter set indicated by the received element. If the station fails to receive an element indicating the value of a parameter in the EDCA parameter set from the associated AP, the station can set the value of the parameter in the EDCA parameter set to a default value.

[0388] The AP may transmit a management frame including an element indicating a parameter value of an EDCA parameter set. The management frame may include a beacon frame, an association response frame, a reassociation response frame, and a probe response frame. The management frame may also include multiple elements indicating each parameter set of multiple EDCA parameter sets. The element indicating the parameter value of the legacy EDCA parameter set may be an EDCA Parameter Set element. The element indicating the parameter value of the MU EDCA parameter set may be an MU EDCA Parameter Set element.

[0389] 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 element and the Operation element may be defined separately for an HT station, a VHT station, an HE station, and an EHT station.

[0390] An element may be identified by the Element ID field or Element ID Extension field it contains. The Element ID field and Element ID Extension field of an EDCA Parameter Set element indicate that it is an EDCA Parameter Set element. Also, the Element ID field and Element ID Extension field of an MU EDCA Parameter Set element indicate that it is an MU EDCA Parameter Set element.

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

[0392] The parameter record field may also include a subfield indicating CWmin, an ECWmin field, a subfield indicating CWmax, and an ECWmax field. In this case, the values ​​of CWmin and CWmax may be as follows: 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 an MU EDCA Timer subfield. Specifically, the parameter record field may include a TXOP Limit subfield. The TXOP Limit subfield may indicate the TXOP limit. The MU parameter record field may include an MU EDCA Timer subfield. The MU EDCA Timer subfield may indicate the MU EDCA timer.

[0394] A non-AP station performs channel access using a first EDCA parameter set. If the non-AP station successfully completes AP-triggered transmission, it can perform channel access using a second EDCA parameter set. Performing channel access using an EDCA parameter set may involve updating EDCA parameters, such as CWmin, CWmax, AIFSN, and the MU EDCA timer, according to the parameter values ​​of 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 an MU EDCA parameter set. In this case, the non-AP station may set a timer indicating the remaining duration for which the second parameter set is applied when using the second EDCA parameter set. The timer value is decremented at a constant rate 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 perform channel access 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 can set the timer value to 0. In this case, the timer may be an MU EDCA timer. For convenience of explanation, setting a timer value to a non-zero value is referred to as "setting a timer," and an EDCA timer that indicates the remaining duration for which the second parameter set is applied is referred to as a 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 the parameter values ​​of the second EDCA parameter set, and the probability of successful channel access using the second EDCA parameter set may be smaller than the probability of successful channel access using the first EDCA parameter set, thereby adjusting channel access fairness among stations.

[0396] A non-AP station's successful AP-triggered transmission may refer to a non-AP station's successful solicited transmission via a basic trigger frame. Furthermore, a non-AP station's successful solicited transmission via a basic trigger frame may be limited to a non-AP station's successful transmission of a QoS data frame solicited via a basic trigger frame. A non-AP station's successful transmission of a QoS data frame may be defined as follows: If 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. Furthermore, if 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 transmits a QoS data frame that does not request an immediate response, the non-AP station can update the EDCA parameters with a second EDCA parameter set. In this case, the non-AP station can update the EDCA parameters corresponding to the AC of the QoS data frame with the second EDCA parameter set. In addition, when a non-AP station transmits 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 can be started at the end of the PPDU including the immediate response.Furthermore, when a non-AP station transmits a QoS data frame that does not require an immediate response, the non-AP station may set a timer for applying the second EDCA parameter set, which may start at the end of the PPDU including the QoS data frame.

[0397] FIG. 32 illustrates a method for a station to which a shared TXOP is allocated to configure an MU EDCA parameter set according to an embodiment of the present invention.

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

[0399] A station to which a shared TXOP is assigned may 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. In yet another specific embodiment, the second EDCA parameter set may be an EDCA parameter set with a lower priority than the legacy EDCA parameter set described above. This embodiment enables channel access fairness to be adjusted between stations to which a shared TXOP is assigned and stations to which a shared TXOP is not assigned. For convenience of explanation, a station that assigns a shared TXOP is referred to as a shared TXOP allocator, and a shared TXOP holder is referred to as a shared TXOP holder.

[0400] When a station that receives an MU-RTS TXS trigger frame transmits 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 indicate a CTS frame or a PPDU including a CTS frame. When a station that receives an MU-RTS TXS trigger frame transmits a response to the MU-RTS TXS trigger frame, the station can access the channel using the second EDCA parameter set in the shared TXOP. This embodiment may be applied only when the MU-RTS TXS trigger frame allows the shared TXOP holder to transmit only to one station, e.g., an AP. In other words, this embodiment may not be applied when the MU-RTS TXS trigger frame allows the shared TXOP holder to transmit to multiple stations, e.g., an AP and other non-AP stations.

[0401] In yet another specific embodiment, when a station to which a shared TXOP has been allocated transmits at least one frame to the shared TXOP allocator, the station can switch the EDCA parameters used for channel access from a first EDCA parameter set to a second EDCA parameter set.

[0402] Furthermore, a station to which a shared TXOP is allocated may set a timer for applying the second EDCA parameter set at the end of the shared TXOP. In yet another specific embodiment, a station to which a shared TXOP is allocated may set a timer for applying the second EDCA parameter set at the time of receiving a response corresponding to signaling to terminate the shared TXOP. In yet another specific embodiment, a station to which a shared TXOP is allocated may set a timer for applying the second EDCA parameter set at the earlier of the end of the shared TXOP or the time of receiving a response corresponding to signaling to terminate the shared TXOP. In this case, setting the timer for applying the second EDCA parameter set may be, as described above, setting the value of the timer for applying the second EDCA parameter set to a value greater than 0.

[0403] In the embodiment of FIG. 32, the first station (STA1) transmits an MU-RTS TXS trigger frame to the second station (STA2) to allocate a shared TXOP to the second station (STA2). At this time, the second station (STA2) transmits a CTS frame to the first station (STA1). As described above, when the second station (STA2) transmits the 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. In addition, the second station (STA2) can set a timer for applying the second EDCA parameters at the end of the shared TXOP. This is to prevent the timer value from continuously decreasing even though the shared TXOP holder is not accessing the channel 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] 32 and other examples have been described 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, e.g., a legacy EDCA parameter set, to a second parameter set, e.g., an MU EDCA parameter set. Such an embodiment may be applied only when the shared TXOP holder successfully transmits a frame. Thus, 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. Also, such an embodiment may be applied only when the shared TXOP holder successfully transmits a QoS data frame. Also, 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 the QoS data frame requires an immediate response, successfully transmitting the QoS data frame may mean transmitting a QoS data frame and receiving an ACK for the transmitted QoS data frame. Also, if the QoS data frame does not require an immediate response, successfully transmitting the QoS data frame may mean transmitting the QoS data frame. When the shared TXOP holder successfully transmits a QoS data frame to the shared TXOP allocator within the shared TXOP, the shared TXOP holder sets an EDCA timer for application of the second parameter set, for example, the value of the MU EDCA timer, to a non-zero value.

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

[0406] In the above-described embodiment, 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 transmitting a frame in the shared TXOP. This is applicable only to the first shared TXOP mode. This is because it may be difficult for the shared TXOP allocator to monitor frame exchanges between the shared TXOP holder and other stations. Also, if the shared TXOP holder does not exchange frames with the shared TXOP allocator, it is difficult to say that the shared TXOP holder has gained a benefit over other stations in frame exchanges with the shared TXOP allocator.

[0407] FIG. 33 illustrates the operation of a station recovering a TXOP after allocating a shared TXOP according to an embodiment of the present invention.

[0408] Within a shared TXOP, the shared TXOP allocator can transmit only if a pre-specified condition is met. The pre-specified condition may include at least one of the shared TXOP allocator transmitting an immediate response to the shared TXOP holder's transmission within the shared TXOP and performing a TXOP recovery operation. In this case, the TXOP recovery operation may be performed when a frame is not exchanged within the shared TXOP. If no transmission or reception occurs within the shared TXOP for a certain period of time, the station may determine that a frame is not exchanged. In addition, if a transmission failure occurs within the shared TXOP, the station may determine that a frame is not exchanged. In this case, if no immediate response is received for a transmitted frame, the station may determine that the transmission has failed.

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

[0410] As described 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 exchanged. Specifically, if a channel in which TXOP sharing occurs within a shared TXOP is idle for a certain period of time, the station can determine that no frames are exchanged. In this case, the certain period of time may be PIFS. Furthermore, a channel being idle may be determined by the carrier sense (CS) result of the channel being idle. In this case, CS may be energy detection (ED). If a station senses the energy of a certain signal in ED that is greater than or equal to an ED threshold, the station can determine that the medium is not idle (busy). Furthermore, if a station senses the energy of a certain signal in ED that is less than the ED threshold, 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 to mean that the CS result is idle in the PIFS or that the channel is idle in the PIFS. Also, in this specification, starting transmission at a specific time, particularly PIFS after the end of a PPDU, may be described assuming that the channel is idle in the PIFS. Also, in this specification, not starting transmission at a specific time, particularly PIFS after the end of a PPDU, may be described assuming that the channel is busy in the PIFS.

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

[0413] Additionally, the above-described embodiment of performing TXOP recovery may be applied only in the first shared TXOP mode, specifically, only when the shared TXOP holder is not allowed to send P2P frames within the shared TXOP.

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

[0415] Also, in the above embodiment, it has been described that TXOP recovery is performed by the shared TXOP allocator, but the shared TXOP holder can also perform TXOP recovery according to the above embodiment.

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

[0417] In Figure 33, we have explained how to recover a TXOP within a shared TXOP. When the shared TXOP expires, the TXOP acquired by the shared TXOP allocator may not expire. In this case, a method for the shared TXOP allocator to recover the TXOP may be required. This is explained in Figure 34.

[0418] FIG. 34 illustrates a shared TXOP allocator performing TXOP recovery after the expiration of a shared TXOP according to an embodiment of the present invention.

[0419] First, within a shared TXOP, the shared TXOP allocator can transmit under the following conditions:

[0420] When a shared TXOP allocator that sent an MU-RTS TXS trigger frame in the first shared TXOP mode receives a CTS frame from the shared TXOP holder, the shared TXOP allocator may start transmitting in the shared TXOP only if:

[0421] A shared TXOP allocator can start transmitting within a shared TXOP if it receives a PPDU requesting an immediate response from the shared TXOP holder within the shared TXOP. Also, a shared TXOP allocator can start transmitting within a shared TXOP if the channel is idle on a TxPIFS slot boundary from the end of the last immediate response transmission sent to a station in the first shared TXOP mode or the last frame transmission received from the TXOP holder that does not request an immediate response.

[0422] When a shared TXOP allocator that sent an MU-RTS TXS trigger frame in the second shared TXOP mode receives a CTS frame from the shared TXOP holder, the shared TXOP allocator may start transmitting in the shared TXOP only if:

[0423] If the shared TXOP allocator receives a PPDU from the shared TXOP holder in the shared TXOP requesting an immediate response, the shared TXOP allocator can start transmitting in the shared TXOP.

[0424] Also, when the TXNAV timer expires, i.e., when the TXOP acquired by the shared TXOP allocator expires, the shared TXOP allocator cannot transmit any PPDUs without performing a new backoff procedure.

[0425] After a shared TXOP has expired, if the shared TXOP has not expired, the shared TXOP allocator can start transmitting when any one of the pre-specified conditions is met.

[0426] First condition: The shared TXOP allocator performs CS at the end of the shared TXOP and determines that the channel is idle in PIFS. In this case, the shared TXOP allocator can transmit a PPDU PIFS later than the end of the shared TXOP.

[0427] Second condition: The PPDU transmission of the shared TXOP allocator may end SIFS earlier than the end of the shared TXOP. In this case, the shared TXOP allocator can transmit a PPDU SIFS later than the end of the PPDU transmitted by the shared TXOP allocator. Specifically, the shared TXOP allocator can transmit a PPDU SIFS later than the end of the PPDU transmitted by the shared TXOP allocator without performing CS.

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

[0429] Fourth condition: The shared TXOP allocator can perform the backoff procedure to acquire the TXOP and then acquire the TXOP. At this time, the shared TXOP allocator can transmit the PPDU.

[0430] In the embodiment of Figure 34, the first station (STA1) sends an MU-RTS TXS trigger frame to the second station (STA2) to allocate a shared TXOP to the second station (STA2), and the second station (STA2) then sends a CTS frame to the first station (STA1).

[0431] In the example of FIG. 34(a), when the first station (STA1) transmits the first frame (DL frame 1) in the shared TXOP, there is a time remaining by the end of the shared TXOP that is less than PIFS but greater than SIFS. In this case, 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 point 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 25 us. Therefore, this may violate the existing regulations. Specifically, this may violate the WLAN standard's rule that when a station that acquires a TXOP exchanges frames, the interval between frames must not be greater than 25 us.

[0432] In the example of FIG. 34(b), when the second station (STA1) transmits a frame (UL frame or P2P 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 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 point PIFS later than the end of the shared TXOP. At this time, the interval between PPDUs transmitted by the first station (STA1) is greater than 25 us. Also, the interval between the PPDU transmitted by the second station (STA2) and the PPDU transmitted by the first station (STA1) is greater than 25 us. Therefore, this may also violate the aforementioned regulation regarding the transmission interval within the TXOP.

[0433] In addition, if the first station (STA1) cannot detect all frame exchanges within the shared TXOP and performs CS at the end of the shared TXOP or the frame exchange ends at the end of the shared TXOP, the interval between PPDUs will be greater than 25 us. This also applies when PPDU transmission is performed according to the above-mentioned condition 3. 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 25 us. This may also violate the above-mentioned rule regarding the transmission interval within a TXOP.

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

[0435] TXOP recovery after the end of a shared TXOP without violating the rules on the spacing between PPDUs transmitted within a TXOP is described in FIG.

[0436] FIG. 35 is a diagram illustrating a shared TXOP allocator performing TXOP recovery after the expiration of a shared TXOP according to yet another embodiment of the present invention.

[0437] The first condition described in FIG. 34 may be modified as follows: The end of the last PPDU of a shared TXOP may be PIFS earlier than the end of the shared TXOP. In this case, if the channel is idle for PIFS from the end of the last PPDU transmitted in the shared TXOP, the shared TXOP allocator may transmit a PPDU PIFS later than the end of the last PPDU transmitted in the shared TXOP. This embodiment may be applied only when the shared TXOP holder is not permitted to transmit to stations other than the shared TXOP allocator in the shared TXOP. In this specification, the PPDU transmitted in the shared TXOP may refer only to the PPDU transmitted by the shared TXOP holder in the shared TXOP and the PPDU transmitted in response to the PPDU transmitted by the shared TXOP holder. For convenience of explanation, the last PPDU transmitted in the shared TXOP is 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 allocator in the shared TXOP is referred to as the first TXOP sharing mode. In addition, the case where the shared TXOP holder is allowed to transmit within the shared TXOP to a station other than the shared TXOP allocator is called 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, only if the PPDU does not include a frame requesting an immediate response, the shared TXOP allocator can perform TXOP recovery according to the above-described embodiment.

[0439] In the embodiment of Figure 35, the first station (STA1) sends an MU-RTS TXS trigger frame to the second station (STA2) to allocate a shared TXOP to the second station (STA2), and the second station (STA2) then sends a CTS frame to the first station (STA1).

[0440] In the example of FIG. 35(a), when the first station (STA1) transmits the first frame (DL frame 1) in the shared TXOP, there is a time remaining by the end of the shared TXOP that is less than PIFS but greater than SIFS. In this case, the first station (STA1) performs a CS at the end of the first frame (DL frame 1) and determines that the channel is idle in PIFS. Therefore, the first station (STA1) can transmit the second frame (DL frame 2) at a point that is PIFS later than the end of the first frame (DL frame 1). Therefore, the interval between the first frame (DL frame 1) and the second frame (DL frame 2) is less than 25 μs.

[0441] In the example of Figure 35(b), when a second station (STA1) transmits a frame (UL frame) within a 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 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 point that is PIFS later than 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 25 us.

[0442] In yet another specific embodiment, if the duration of the residual shared TXOP is less than PIFS, the shared TXOP holder may not be allowed to start transmission. If the duration of the residual shared TXOP is less than PIFS, the shared TXOP allocator may transmit a PPDU SIFS later than the end of the PPDU transmitted as the last PPDU of the shared TXOP. In this case, the shared TXOP allocator may transmit a PPDU SIFS later than the end of the PPDU transmitted as the last PPDU of the shared TXOP without performing CS. This is because the shared TXOP allocator can be sure that the shared TXOP holder will not transmit because the duration of the residual shared TXOP is less than PIFS. In this embodiment, if the last PPDU of the shared TXOP is the PPDU transmitted by the shared TXOP allocator and the duration of the residual shared TXOP is less than SIFS, the allocated station may transmit a PPDU according to the second condition described in FIG. 34.

[0443] If the duration of the remaining shared TXOP is less than PIFS, the shared TXOP holder and the station that allocated the TXOP may not be allowed to begin transmitting. Specifically, if the duration of the remaining shared TXOP is less than PIFS but greater than SIFS, the shared TXOP holder and the station that allocated the TXOP may not be allowed to begin transmitting.

[0444] Furthermore, the following condition may be added as a condition for the shared TXOP allocator to start transmission if the shared TXOP does not end after the shared TXOP has ended.

[0445] Fifth condition: The shared TXOP allocator can receive a frame requesting an immediate response from the shared TXOP holder. In this case, the shared TXOP allocator can transmit a PPDU at a point that is 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 for the station that has been allocated the TXOP can be less than or equal to a pre-specified value. The pre-specified value can be SIFS. The pre-specified value can be 0.

[0446] As mentioned above, the embodiment described in Fig. 35 may be applied in the first shared TXOP mode. In the second shared TXOP mode, TXOP recovery after the shared TXOP has expired is described in Fig. 36.

[0447] FIG. 36 is a diagram illustrating a shared TXOP allocator performing TXOP recovery after the expiration of a shared TXOP 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, provided that the last PPDU of the shared TXOP contains a frame for which the shared TXOP allocator is the intended recipient.

[0449] Therefore, in the second shared TXOP mode, the last PPDU of the shared TXOP may include a frame for which the shared TXOP allocator is the intended recipient, and the end of the last PPDU of the shared TXOP may be PIFS earlier or later than the end of the shared TXOP. In this case, if the channel is idle during the PIFS period from the end of the last PPDU of the shared TXOP, the shared TXOP allocator may transmit a PPDU PIFS later than the end of the last PPDU of the shared TXOP. This embodiment may be applied only when the last PPDU of the shared TXOP does not include a frame requesting an immediate response.

[0450] Also, if the duration of the remaining shared TXOP is less than PIFS, the shared TXOP holder may not be allowed to start transmission. If the duration of the remaining shared TXOP is less than PIFS, the shared TXOP allocator may transmit a PPDU SIFS later than the end of the last PPDU of the shared TXOP. In this case, the shared TXOP allocator may transmit a PPDU SIFS later than the end of the last PPDU of the shared TXOP without performing CS.

[0451] In yet another specific embodiment, if the duration of the remaining shared TXOP is less than PIFS, the shared TXOP holder and the station that allocated the TXOP may not be allowed to begin transmitting. Specifically, if the duration of the remaining shared TXOP is less than PIFS but greater than SIFS, the shared TXOP holder and the station that allocated the TXOP may not be allowed to begin transmitting.

[0452] However, unlike the embodiment of Figure 36, the shared TXOP allocator needs to determine whether the last PPDU of the shared TXOP contains a frame for which the shared TXOP allocator is the intended recipient. Specifically, the shared TXOP allocator can determine whether the last PPDU of the shared TXOP contains a frame that the shared TXOP holder will send to the shared TXOP allocator.

[0453] In the example of FIG. 36, the first station (STA1) transmits an MU-RTS TXS trigger frame to the second station (STA2) to allocate a shared TXOP to the second station (STA2). At this time, the second station (STA2) transmits a CTS frame to the first station (STA1). In the example of FIG. 36(a), when the second station (STA2) transmits a UL frame within the shared TXOP, there is a time period less than PIFS but greater than SIFS remaining until the end of the shared TXOP. At this time, the first station (STA1) performs a CS at the end of the UL frame and determines that the channel is idle in PIFS. Therefore, the first station (STA1) can transmit a DL frame at a point PIFS later than the end of the UL frame. Therefore, the interval between the UL frame and the DL frame (DL frame 2) is less than 25 μs.

[0454] If the intended recipient of the frame contained in the last PPDU of the shared TXOP is the shared TXOP holder, the shared TXOP allocator may be allowed to perform TXOP recovery according to the embodiment of Figure 36(a).

[0455] When the sender of the frame included in the last PPDU of the shared TXOP is the station that received the TXOP allocation and the intended recipient is a station other than the shared TXOP allocator, the shared TXOP allocator can perform TXOP recovery based on whether the last PPDU of the shared TXOP includes a frame requesting an immediate response. When the sender of the frame included in the last PPDU of the shared TXOP is the station that received the TXOP allocation and the intended recipient is a station other than the shared TXOP allocator, and the last PPDU of the shared TXOP includes a frame requesting an immediate response, the shared TXOP allocator may not be allowed to perform TXOP recovery according to the embodiment described in FIG. 36(a). This is because the shared TXOP allocator may have difficulty receiving a response frame transmitted by a P2P peer station within the shared TXOP. If the channel is idle during the PIFS period following the PPDU containing the immediate response to the frame requesting an immediate response, the station that allocated the TXOP can start transmission at a time PIFS later than the PPDU containing the immediate response. In yet another specific embodiment, the station that allocated the TXOP can begin transmitting SIFS later than the PPDU containing the immediate response.

[0456] In Figure 36(b), when the second station (STA2) sends a P2P frame within a shared TXOP, there is a time remaining until the end of the shared TXOP that is less than PIFS but more than SIFS. 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 in PIFS. Therefore, the first station (STA1) can send a DL frame PIFS later than the end of the P2P frame. Therefore, the interval between the P2P frame and DL frame 2 is less than 25 us.

[0457] In Figure 36(C), when a P2P frame is sent to the second station (STA2) 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. The first station (STA1) performs a CS at the end of the P2P frame and determines that the channel is idle in PIFS. Therefore, the first station (STA1) can send a DL frame PIFS later than the end of the UL frame. Therefore, the interval between the UL frame and DL frame (DL frame 2) is less than 25 us.

[0458] In the above-described embodiment, the station that allocated the TXOP can determine the intended recipient of the received frame based on the recipient address, e.g., the RA field, of the received frame. Specifically, the station that allocated the TXOP can determine the station indicated by the recipient address of the receiving station as the intended recipient. The station that allocated the TXOP can also determine the sender of the received frame based on the sender address, e.g., the TA field, of the received frame. Specifically, the station that allocated the TXOP can determine the station indicated by the sender address of the receiving station as the sender. The station that allocated the TXOP can also determine the intended recipient of the frame included in the received PPDU based on the STA-ID field in the signaling field of the received PPDU. The station that allocated the TXOP can also determine the intended recipient of the frame included in the received PPDU based on the STA-ID field and BSS color field in the signaling field of the received PPDU. The station that allocated 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. 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 upstream transmission PPDU or a downstream transmission PPDU.

[0459] If the channel is busy at the end of a shared TXOP, the shared TXOP allocator may not be allowed to start frame exchange without performing a backoff procedure to acquire the TXOP, even within a TXOP acquired by the shared TXOP, which includes the shared TXOP. A situation may occur in which a station that was allowed to transmit within the shared TXOP cannot transmit. In this case, even if the shared TXOP allocator starts transmitting immediately after the end of the shared TXOP, the interval between the PPDU transmitted by the shared TXOP allocator and the PPDU transmitted within the shared TXOP may be greater than 25 us. Therefore, the shared TXOP allocator may perform a backoff procedure again to acquire the TXOP.

[0460] In addition, the frame included in the last PPDU of the shared TXOP may not be successfully received or may not be included in the frame exchange of the shared TXOP holder. In this case, even if the shared TXOP is included in a TXOP acquired by the shared TXOP allocator, the shared TXOP allocator may not be allowed to start a frame exchange without performing a backoff procedure to acquire the TXOP. The frame included in the last PPDU of the shared TXOP may not be included in the frame exchange of the shared TXOP holder if the recipient of the frame included in the last PPDU of the shared TXOP is not the shared TXOP holder and the sender of the frame included in the last PPDU of the shared TXOP is not the shared TXOP holder. This is because if the frame included in the last PPDU of the shared TXOP is not successfully received or if the frame included in the last PPDU of the shared TXOP is not included in the frame exchange of the shared TXOP holder, the interval between the PPDU transmitted by the shared TXOP allocator and the PPDU transmitted in the shared TXOP is not guaranteed to be within 25 us.

[0461] In yet another specific embodiment, after the end of a shared TXOP, which is a second shared TXOP mode, the shared TXOP allocator may not be allowed to start a frame exchange without a backoff procedure for acquiring the TXOP, even if the shared TXOP is included in the TXOP acquired by the shared TXOP allocator.

[0462] Moreover, the third condition described with reference to FIG. 34 may be modified as follows.

[0463] The shared TXOP allocator can determine that the channel is not idle by performing a CS at the end of the shared TXOP. Also, the transmission occupying the channel at the end of the TXOP may be a frame exchange by the shared TXOP holder. In such a case, the shared TXOP allocator can transmit a PPDU when the channel is idle, i.e., when the channel is idle at a TxPIFS slot boundary.

[0464] The transmission occupying the channel at the end of a TXOP may not be a frame exchange by the shared TXOP holder. In this case, even if the shared TXOP allocator acquired a TXOP that includes a shared TXOP after the TXOP ends, the shared TXOP allocator may not be allowed to start a frame exchange without a backoff procedure to acquire the TXOP. This is because if the channel is occupied by a non-frame exchange transmission by the shared TXOP holder and the shared TXOP allocator transmits according to existing condition 3, the interval between the last PPDU of the shared TXOP and the PPDUs transmitted by the shared TXOP allocator after the shared TXOP may be greater than 25 us. This embodiment modifying the application condition of condition 3 applies to the second shared TXOP mode but not to the first shared TXOP mode.

[0465] In the embodiment described above in relation to TXOP recovery, with regard to the conditions for performing a TXOP recovery operation, the time period indicated by "after a point earlier than PIFS from the end of the shared TXOP" may include a point PIFS earlier than the end of the shared TXOP. Also, if the end time of the remaining shared TXOP is less than PIFS, it may include the case where the end time of the remaining shared TXOP is PIFS. Also, the time period indicated by "before a point earlier than SIFS from the end of the shared TXOP" may include a point SIFS ahead of the end of the shared TXOP. Also, if the end time of the remaining shared TXOP is greater than SIFS, it may include the case where the end time of the remaining shared TXOP is SIFS.

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

[0467] FIG. 37(a) shows the format of a MAC frame. The 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 using the Type subfield and the Subtype subfield, respectively. The Frame Control field may also indicate whether the frame includes an HT Control field using the +HTC subfield. The Duration / ID field may indicate the frame duration. If the frame including the Duration / ID field is not a PS-Poll frame, the Duration / ID field may indicate the frame duration. The station may also set a network allocation vector (NAV) based on the frame duration indicated by the Duration / ID field of the received frame. If the frame including the Duration / ID field is a PS-Poll frame, the Duration / ID field may indicate an ID, such as an AID. The MAC address field may also include one or more address fields. The Address field can indicate a MAC address, and may include at least one of a basic service set identifier (BSSID) field, a source address (SA) field, a destination address (DA) field, a transmitting STA address or transmitter address (TA) field, and a receiving STA address or receiver address (RA) field. The Sequence Control field can indicate a fragment number or a sequence number.The QoS Control field may also include at least one of the TID of the traffic included in the frame, the Ack Policy for the frame, the TXOP limit of the frame exchange including the frame, the buffer status of the station that transmitted the frame, and the queue size of the station that transmitted the frame. The QoS Control field may also include the above-mentioned RDG / More PPDU subfield and AC Constraint subfield. For example, the QoS Control field included in a DMG PPDU may include the above-mentioned RDG / More PPDU subfield and AC Constraint subfield.

[0468] The HT Control field may include the RDG / More PPDU subfield and AC Constraint subfield described above. As described above, the RDG / More PPDU subfield can signal whether the frame includes an RDG or whether there is a PPDU following the frame. In addition, 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 a pre-specified value.

[0470] The Frame Body field contains the contents of the frame and may contain information about the type of frame and the subtype of the frame.

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

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

[0473] For example, the HT Control field may be composed 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 an EHT or later standard. In this specification, the embodiments described as applying to an HE variant may also be applied to variants defined in an HE or later standard. In addition, the HT Control field may include signaling indicating 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. Also, 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 or later standard.

[0474] If the HT Control field is an HE variant, an EHT variant, or an EHT post-standard variant, the HT Control field may include an A-Control subfield. The A-Control subfield contains one or more pieces of control information. For example, the 3rd bit (B2) to the 32nd bit (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 include one or more pieces of control information. The Control List subfield may include one or more Control subfields. The A-Control field may optionally include a Padding subfield. For example, the remaining length obtained by subtracting the length of the Control List subfield from the predetermined length of the A-Control subfield may be the length of the Padding subfield. The value of the Padding subfield may be set to a predetermined value. Alternatively, the value of the first bit of the Padding subfield may be set to a predetermined value.

[0476] Figure 37(d) shows the format of the Control subfield. In Figure 37(d), the Control subfield in...

Claims

1. A station in a wireless communication system, comprising: a transceiver, and a processor for controlling the transceiver; The processor: receiving a trigger frame from an Access Point (AP), the trigger frame allocating a portion of a transmission opportunity (TXOP) obtained by the AP to the station as a shared TXOP; transmitting a CTS frame in response to the trigger frame; Transmitting a non-trigger-based (TB) physical layer protocol data unit (PPDU) within the shared TXOP; switching a first enhanced distributed channel access (EDCA) parameter set used for channel access to a second EDCA parameter set based on transmission of a quality of service (QoS) data frame included in the non-TB PPDU; and performing the channel access in accordance with the second EDCA parameter set; configured to perform Station.

2. The station of claim 1 , wherein the processor is configured to switch from the first EDCA parameter set to the second EDCA parameter set if the QoS data frame is successfully transmitted to the AP within the shared TXOP.

3. 3. The station of claim 2, wherein the processor is configured to switch from 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 the immediate response within the shared TXOP.

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

5. 3. The station of claim 2, wherein a value of a timer for a residual duration applied to the second EDCA parameter set is set to a value greater than 0 if the QoS data frame is successfully transmitted to the AP.

6. The station of claim 5 , wherein the processor is configured not to set the value of the timer to 0 even if the station successfully transmits signaling to the AP to deactivate UL MU transmission operation within the shared TXOP.

7. The station of claim 5 , wherein the processor is configured to set the value of the timer to 0 if the station successfully sends signaling to the AP to deactivate the shared TXOP operation.

8. The station of claim 1 , wherein the second EDCA parameter set is used instead of the first EDCA parameter set based on whether an UL multiuser (MU) transmission is successfully performed.

9. 2. The station of claim 1, wherein when the remaining duration of the shared TXOP is shorter than a point coordination function (PCF) inter-frame space (PIFS), no transmissions of the AP are permitted except for one or more predetermined transmissions, the one or more predetermined transmissions being performed by the AP a short inter-frame space (SIFS) after the end of transmission of the last PPDU transmitted from the station within the shared TXOP, and the last PPDU does not require an immediate response.

10. 1. A method of operating a station in a wireless communication system, comprising: receiving a trigger frame for triggering uplink transmission from an Access Point (AP), the trigger frame allocating a portion of a transmission opportunity (TXOP) obtained by the AP to the station as a shared TXOP; transmitting a CTS frame in response to the trigger frame; transmitting a non-trigger-based (TB) physical layer protocol data unit (PPDU) within the shared TXOP; switching a first enhanced distributed channel access (EDCA) parameter set used for channel access to a second EDCA parameter set based on transmission of a quality of service (QoS) data frame included in the non-TB PPDU; performing the channel access in accordance with the second EDCA parameter set; A method comprising:

11. 11. The method of claim 10, wherein the step of switching the first EDCA parameter set used for channel access to the second EDCA parameter set comprises 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.

12. 12. The method of claim 11, wherein the step of switching from 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 comprises the step of: transmitting a QoS data frame requesting an immediate response to the AP via the non-TB PPDU; and switching from the first EDCA parameter set to the second EDCA parameter set when the station receives a response to the QoS data frame requesting an immediate response within the shared TXOP.

13. 12. The method of claim 11, wherein the step of switching from 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 comprises the step of switching from the first EDCA parameter set to the second EDCA parameter set when the station transmits the non-TB PPDU including a QoS data frame that does not require an immediate response to the AP within the shared TXOP.

14. 12. The method of claim 11, wherein the step of switching from the first EDCA parameter set to the second EDCA parameter set comprises setting a value of a timer for a remaining duration applied to the second EDCA parameter set to a value greater than 0 if the QoS data frame is successfully transmitted to the AP.

15. 15. The method of claim 14, further comprising: not setting the timer to 0 even if the station successfully transmits signaling to deactivate UL MU transmission operation to the AP within the shared TXOP.

16. The method of claim 14 , further comprising: setting the value of the timer to 0 when the station successfully sends signaling to the AP to deactivate the shared TXOP operation.

17. The method of claim 10 , wherein the second EDCA parameter set is used instead of the first EDCA parameter set based on whether an UL multiuser (MU) transmission is successfully performed.

18. 11. The method of claim 10, wherein if the remaining duration of the shared TXOP is shorter than a point coordination function (PCF) inter-frame space (PIFS), then no transmissions of the AP are permitted except for one or more predetermined transmissions, the one or more predetermined transmissions being performed by the AP a short inter-frame space (SIFS) after the end of transmission of the last PPDU transmitted from the station within the shared TXOP, and the last PPDU does not require an immediate response.

Images