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

Abstract

A station of a wireless communication system is disclosed. The station includes a transceiver unit and a processor that controls the transceiver unit. The processor receives a trigger frame from an access point (AP) to trigger uplink transmission, the trigger frame assigning a portion of a transmission opportunity (TXOP) acquired by the AP to the station as a shared TXOP, transmits a CTS frame in response to the trigger frame, and switches a first 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.

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 use of mobile devices has become more widespread, wireless LAN technology that can provide them with high-speed wireless Internet services has been attracting attention. Wireless LAN technology is a technology that enables mobile devices such as smartphones, smart pads, laptop PCs, portable multimedia players, embedded devices, etc. to wirelessly connect to the Internet at home, in business, or in specific service areas based on short-distance wireless communication technology.

[0003] Since IEEE (Institute of Electronics Engineers) 802.11 supported the initial wireless LAN technology using 2.4GHz frequency, it has put into practical use or is developing various technology standards. First, IEEE 802.11b uses the 2.4GHz band and supports a maximum communication speed of 11Mbps. IEEE 802.11a, which was commercialized after IEEE 802.11b, uses the 5GHz band instead of the 2.4GHz band, reducing the impact of interference compared to the considerably congested 2.4GHz band, and uses OFDM technology to increase communication speed to a maximum of 54Mbps. However, IEEE 802.11a has the disadvantage of a shorter communication distance than IEEE 802.11b. IEEE 802.11g, like IEEE 802.11b, uses the 2.4GHz frequency band to achieve a maximum communication speed of 54Mbps and satisfies backward compatibility, which has attracted considerable attention, but it also has an advantage over IEEE 802.11a in communication distance.

[0004] IEEE 802.11n is a technical standard established to overcome the communication speed limitations that have been pointed out as a weakness of wireless LAN. The purpose of IEEE 802.11n is to increase the speed and reliability of the network and to extend the operating distance of wireless networks. In detail, IEEE 802.11n supports high throughput (HT) with a data processing speed of up to 540Mbps or more, and is based on MIMO (Multiple Inputs and Multiple Outputs) technology that 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 the use of wireless LANs becomes more widespread and applications using them become more diverse, the need for new wireless LAN systems to support data throughput rates (Very High Throughput, VHT) higher than those supported by IEEE 802.11n is emerging. Among them, IEEE 802.11ac supports wide bandwidth (80MHz~160MHz) at 5GHz frequency. Although the IEEE 802.11ac standard is defined only in the 5GHz band, it is expected that initial 11ac chipsets will also support operation in the 2.4GHz band for backward compatibility with existing 2.4GHz band products. Theoretically, this standard allows multi-station wireless LAN speeds of at least 1Gbps and maximum single link speeds of at least 500Mbps. This is done by extending the air interface concepts accepted by 802.11n, such as wider radio frequency bandwidth (up to 160MHz), more MIMO spatial streams (up to 8), multi-user MIMO, and high density modulation (up to 256QAM). Also, there is IEEE 802.11ad, a method of transmitting data using the 60GHz band instead of the conventional 24GHz / 5GHz. IEEE 802.11ad is a transmission standard that uses beamforming technology to provide speeds of up to 7Gbps, and is suitable for streaming large amounts of data and high bitrate videos such as uncompressed HD video. However, the 60GHz frequency band has the disadvantage that it is 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 in the final stages as the WLAN standard after 802.11ac and 802.11ad 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, it is necessary to provide high-frequency efficient communication indoors / outdoors in the presence of high density stations and APs (Access Points), and various technologies are being developed to realize this.

[0007] In addition, new WLAN standards have begun to be developed to increase maximum transmission speeds to support new multimedia applications such as high-definition video and real-time games. IEEE 802.11be (Extremely High Throughput, EHT), the 7th generation WLAN standard, is currently being developed with the goal of supporting transmission rates of up to 30 Gbps through wider bandwidth in the 2.4 / 5 / 6 GHz bands, increased spatial streams, and multiple 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 that controls the transceiver unit. The processor receives a trigger frame from an access point (AP) to trigger uplink transmission, the trigger frame assigning 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 from the first EDCA parameter set to the second EDCA parameter set if a quality of service (QoS) data frame is successfully transmitted to the AP in 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 can 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 a UL multiuser (MU) transmission is successful.

[0014] A timer value for a remaining duration for which the second EDCA parameter set is applied when a QoS data frame is successfully transmitted to the AP within the shared TXOP 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 timer value to 0 if the station successfully sends signaling to the AP to deactivate the shared TXOP operation.

[0017] An operation method of a station in a wireless communication system according to an embodiment of the present invention may include a step of receiving a trigger frame for triggering an uplink transmission from an AP (Access Point), the trigger frame allocating a portion of a transmission opportunity (TXOP) acquired by the AP to the station as a shared TXOP; a step of transmitting a CTS frame in response to the trigger frame; and a step of switching a first enhanced distributed channel access (EDCA) parameter set used for channel access to a second EDCA parameter set based on a 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 successfully transmits a QoS data frame to the AP in the shared TXOP may include the step of transmitting a QoS data frame requesting an immediate response to the AP in the shared TXOP by the station, and switching 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.

[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 in 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 in 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 a 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 a step of setting a timer value 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 timer value 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 timer value to 0 even if the station successfully transmits signaling to the AP in the shared TXOP to deactivate a UL MU transmission operation.

[0024] The step of setting a timer value for a remaining duration to which the second EDCA parameter set applies to a value greater than 0 may include setting the timer value to 0 if the station successfully sends signaling to the AP to deactivate the shared TXOP operation. Effect 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 description of the drawings]

[0026] [Figure 1] FIG. 1 is a diagram showing a wireless LAN system according to an embodiment of the present invention. [Diagram 2] FIG. 11 is a diagram showing a wireless LAN system according to another embodiment of the present invention. [Diagram 3] FIG. 2 is a diagram showing a configuration of a station according to an embodiment of the present invention. [Figure 4] FIG. 2 is a diagram showing a configuration of an access point according to an embodiment of the present invention. [Diagram 5] 1 is a diagram illustrating a process in which a STA sets up 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 illustrates a multi-link device according to an embodiment of the present invention. [Figure 10] 4 illustrates a multi-link mapped by a TID-to-link mapping method according to an embodiment of the present invention. [Figure 11] A diagram showing an example of a multi-link NAV setting operation according to one embodiment of the present invention. [Figure 12] A diagram showing yet another example of a multi-link NAV setting operation according to one embodiment of the present invention. [Figure 13] FIG. 2 is a diagram showing an example of BSS classification and an operation 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. 2 is a diagram showing 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 in one embodiment of the present invention. [Figure 18] FIG. 2 is a diagram illustrating an example of a UL MU operation according to one embodiment of the present invention. [Figure 19] A diagram showing a method for sharing a TXOP in one embodiment of the present invention. [Figure 20] A diagram showing 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] A diagram showing NAV time out in one embodiment of the present invention. [Figure 24] A diagram showing TXOP sharing and NAV timeout in one embodiment of the present invention. [Diagram 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 STA and AP applying 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]13 is a diagram showing a method of signaling the format of a TB PPDU responding to a trigger frame using a Common Info field and a Special User Info field contained in the trigger frame according to an embodiment of the present invention. [Diagram 30] A diagram showing how a station according to an embodiment of the present invention sets a TXVECTOR parameter when transmitting a frame in response to a modified MU-RTS frame. [Diagram 31] A diagram showing the configuration of a management frame and an MU EDCA Parameter Set element in an embodiment of the present invention. [Diagram 32] A method for a station that has been assigned a shared TXOP to configure an MU EDCA parameter set according to an embodiment of the present invention will now be described. [Diagram 33] A diagram showing the operation of a station recovering a TXOP after allocating a shared TXOP according to an embodiment of the present invention. [Diagram 34] A diagram illustrating a shared TXOP allocator performing TXOP recovery after the end of a shared TXOP according to an embodiment of the present invention. [Diagram 35] A diagram showing a shared TXOP allocator performing TXOP recovery after the expiration of a shared TXOP according to yet another embodiment of the present invention. [Diagram 36] A diagram showing a shared TXOP allocator performing TXOP recovery after the expiration 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] 13 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]FIG. 13 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. [Diagram 40] 13 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. [Diagram 41] FIG. 2 is a diagram illustrating an operation of a station configuring an MU EDCA parameter set based on a shared TXOP operation according to an embodiment of the present invention. [Diagram 42] FIG. 2 is a diagram illustrating an operation of a station configuring an MU EDCA parameter set based on a shared TXOP operation according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] The terms used in this specification are selected as general terms that are currently widely used as much as possible in consideration of the functions in the present invention, but this may vary depending on the intentions, customs, or the emergence of new technologies of the technical experts in the field. In addition, in certain cases, the applicant may arbitrarily select some terms, and in such cases, the meanings of the terms will be described in the description of the relevant invention. Therefore, it is clear that the terms used in this specification should be interpreted not simply as the names of terms, but based on the substantial meanings of the terms and the contents of this specification as a whole.

[0028] Throughout the specification, when a certain component is "connected" to another component, this includes not only when it is "directly connected" to another component, but also when it is "electrically connected" with another component in between. Furthermore, when a certain component "includes" a specific component, this means that it may further include the other component, not excluding the other component, unless otherwise specified to the contrary. In addition, limitations such as "greater than" or "less than" based on a specific threshold value may be appropriately replaced with "greater than" or "less than" 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 (BSS), which are a set of devices that can successfully 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, infrastructure BSS BSS1, BSS2 includes one or more stations STA1, STA2, STA3, STA4, STA5, access points AP-1, AP-2 which are stations providing a distribution service, and a distribution system DS which connects multiple access points AP-1, AP-2.

[0033] A station (STA) is any device including a medium access control (MAC) and a physical layer interface for a wireless medium according to the IEEE 802.11 standard, and in a broad sense includes 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 further includes a user interface unit and a display unit, etc., depending on the embodiment. The processor generates frames to be transmitted via a wireless network, processes frames received via 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 via the wireless network for the station. In the present invention, the term "terminal" is used to include a 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 a station associated therewith. In an infrastructure BSS, communication between non-AP stations is generally performed via the AP, but when a direct link is set up, direct communication is possible between non-AP stations. Meanwhile, in the present invention, AP is used as a concept including a personal BSS coordination point (PCP), but in a broad sense, AP includes all 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, AP is also referred to as a base wireless communication terminal, but in a broad sense, the 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 in communication with a plurality of wireless communication terminals.

[0035] A plurality of infrastructure BSSs are connected to each other via a distribution system DS. In this case, a plurality of BSSs connected to each other via the distribution system is 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 all stations (STA6, STA7) are not 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 a configuration of a station 100 according to an embodiment of the present invention. As shown in the figure, the station 100 according to the embodiment of the present invention includes a processor 110, a communication unit 120, a user interface unit 140, a display unit 150, and a memory 160.

[0039] First, the communication unit 120 transmits and receives wireless signals such as wireless LAN packets, and may be built into or externally provided in 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 of 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 of 7.125 GHz or more and a communication module using a frequency band of 7.125 GHz or less. Each communication module may perform wireless communication with an AP or an external station based on the wireless LAN standard of the frequency band supported by the communication module. The communication unit 120 may operate only one communication module at a time or operate multiple communication modules simultaneously according to the performance and requirements of the station 100. When the station 100 includes multiple communication modules, each communication module may be provided in an independent form, or multiple modules may be integrated into one chip. In an 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 a command from the processor 110 using various output means.

[0041] Then, the display unit 150 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 connection programs 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 transmission and reception of data between the units. According to an embodiment of the present invention, the processor 110 executes a program for connection to an AP stored in the memory 160 and receives a communication setup message transmitted by the AP. The processor 110 also reads information on the priority conditions of the station 100 included in the communication setup message and requests a connection to the AP based on the information on the priority conditions of the station 100. The processor 110 of the present invention may refer to a main control unit of the station 100, or may refer to a control unit for individually controlling some components of the station 100, for example, the communication unit 120, depending on the embodiment. That is, the processor 110 may be a modem that modulates and demodulates a wireless signal transmitted and received from the communication unit 120, or a modulator and / or demodulator. The processor 110 controls various operations of transmitting and receiving wireless signals of the station 100 according to the embodiment of the present invention. A detailed embodiment of the present invention 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 are used to logically distinguish the elements of the device. Thus, the above-mentioned device elements may be mounted on one chip or multiple chips depending on the design of the device. For example, the processor 110 and the communication unit 120 may be integrated and embodied on one chip, or may be embodied on separate chips. In addition, in an embodiment of the present invention, some components of the station 100, such as the user interface unit 140 and the display unit 150, may be selectively provided in the station 100.

[0044] Fig. 4 is a block diagram showing a configuration of an AP 200 according to an embodiment of the present invention. As shown in the figure, 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, a duplicated description 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 a plurality of 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, any of 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz. Preferably, the AP 200 may include a communication module using a frequency band of 7.125 GHz or higher and a communication module using a frequency band of 7.125 GHz or lower. Each communication module may perform wireless communication 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 operate multiple communication modules simultaneously according to the performance and requirements of the AP 200. In the embodiment of the present invention, the communication unit 220 may represent an RF communication module that processes RF (Radio Frequency) signals.

[0046] Next, the memory 260 stores control programs used in the AP 200 and various data associated therewith. Such control programs include a connection program for managing the connection of stations. Also, the processor 210 controls each unit of the AP 200 and controls transmission and reception of data between the units. According to an embodiment of the present invention, the processor 210 executes a program for connection with a station stored in the memory 260 and transmits a communication setting message to one or more stations. At this time, the communication setting message includes information on the connection priority conditions of each station. Also, the processor 210 performs connection setting in response to a connection request of a station. According to an embodiment, the processor 210 is a modem or a modulation / demodulation unit that modulates and demodulates a wireless signal transmitted and received from the communication unit 220. The processor 210 controls various operations of transmitting and receiving wireless signals of the AP 200 according to an embodiment of the present invention. A detailed embodiment thereof 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, the link between the STA 100 and the AP 200 is set up through three steps: scanning, authentication, and association. First, the scanning step is a step in which the STA 100 acquires connection information of the BSS operated by the AP 200. There are two methods for performing scanning: a passive scanning method in which the AP 200 acquires information by using only a beacon message S101 periodically transmitted by the AP, 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 STA100 that has successfully received wireless connection information in the scanning step transmits an authentication request (S107a), receives an authentication response from the AP 200 (S107b), and performs an authentication step. After the authentication step is performed, the STA100 transmits an association request (S109a), receives an association response from the AP 200 (S109b), and performs an association step. 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, the server 300 is a server that processes 802.1X-based authentication with the STA 100, and may be physically connected to the AP 200 or may exist as a separate server.

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

[0052] A terminal performing wireless LAN communication performs carrier sensing before transmitting data to check whether a channel is occupied or not. If a wireless signal of a certain strength or more 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 the signal is detected is called the CCA threshold. If a wireless signal of a strength greater than the CCA threshold received by a terminal is set to the terminal as a 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 of a strength less than the CCA threshold is detected, the channel is determined to be idle.

[0053] If the channel is determined to be in an idle state, each terminal having data to transmit performs a backoff procedure after an IFS (Inter Frame Space) according to the status of each terminal, for example, an AIFS (Arbitration IFS) or a PIFS (PCF IFS). In some embodiments, the AIFS is used as a configuration to replace the conventional DIFS (DCF IFS). Each terminal waits while decreasing a slot time of a random number determined for the terminal during an interval of the idle state of the channel, and a terminal that has exhausted all the slot time attempts to access the channel. In this manner, a section in which each terminal performs a backoff procedure is called a contention window section. At this time, the random number can be called a backoff counter. That is, an initial value of the backoff counter is set by an integer that is a random number obtained by the terminal. If the terminal detects that the channel is idle during the slot time, the terminal can decrease the backoff counter by 1. Also, if the backoff counter reaches 0, the terminal may be allowed to perform channel access on the channel. Thus, a terminal may be allowed to transmit if the channel is idle during the AIFS time and the backoff counter slot time.

[0054] If a specific terminal succeeds in accessing the channel, the terminal 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 random numbers newly assigned to each terminal are determined within a range (2*CW) twice the range (contention window, CW) of the random numbers previously assigned to the terminal. Meanwhile, each terminal performs a backoff procedure again in the next contention window period to attempt access, and at this time, each terminal performs the backoff procedure from the slot time remaining in the previous contention window period. In this manner, each terminal performing wireless LAN communication can avoid collision with each other on a specific channel.

[0055] <Examples of various PPDU formats> FIG. 7 shows an example of various standard generation PPDU (PLCP Protocol Data Unit) formats. More specifically, FIG. 7(a) shows an example of a legacy PPDU format based on 802.11a / g, FIG. 7(b) shows an example of a HE PPDU format based on 802.11ax, and FIG. 7(c) shows an example of a non-legacy PPDU (i.e., EHT PPDU) format based on 802.11be. Also, FIG. 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 RL-SIG (Repeated Legacy Short Training field), a HE-SIG-A (High Efficiency Signal A field), a HE-SIG-B (High Efficiency Signal B field), a HE-STF (High Efficiency Short Training field), and a HE-LTF (High Efficiency Long Training field) 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 be modified according to the HE PPDU format. For example, the 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 RL-SIG (Repeated Legacy Short Training field), a U-SIG (Universal Signal field), an EHT-SIG-A (Extremely High Throughput Signal A field), an EHT-SIG-A (Extremely High Throughput Signal B field), an EHT-STF (Extremely High Throughput Short Training field), and an EHT-LTF (Extremely High Throughput Long Training field) 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 can be called an EHT preamble. The specific configuration of the non-legacy preamble may be modified according to the EHT PPDU format. For example, EHT-SIG-A and EHT-SIG-B may be used only in some formats of the EHT PPDU format.

[0059] The L-SIG field included in the preamble of the PPDU is configured with a total of 64 subcarriers by applying 64 FFT OFDM. Of these, 48 subcarriers excluding the guard subcarrier, DC subcarrier, and pilot subcarrier are used for data transmission of the L-SIG. 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 configuration 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 / 54 Mbps, which is a combination of a modulation method such as BPSK / QPSK / 16-QAM / 64-QAM and a code rate such as 1 / 2, 2 / 3, or 3 / 4. The total length of the PPDU can be indicated by combining the information in the L_RATE field and the L_LENGTH field. In the 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 so that a maximum of 4095 can be signaled. The length of the corresponding PPDU can be indicated in combination with the L_RATE field. In this case, legacy and non-legacy terminals can interpret the L_LENGTH field in different ways.

[0062] First, a method in which a legacy or non-legacy terminal analyzes the length of the PPDU using the L_LENGTH field is 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 one symbol duration of 64 FFT. Therefore, the number of 64 FFT reference symbols after the L-SIG is obtained by adding 3 bytes corresponding to the SVC field and the Tail field to the L_LENGTH field value and dividing it by 3 bytes, which is the transmission amount of one symbol. The length of the PPDU, i.e., the reception time (RXTIME), is obtained by multiplying the obtained number of symbols by 4 us, which is one symbol duration, and adding 20 us for the transmission of the L-STF, L-LTF, and L-SIG. This can be expressed as the following Equation 1.

[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 FIG. 7(e), the U-SIG (Universal SIG) field remains in the EHT PPDU and the PPDU of the succeeding generation of WLAN, and plays a role in identifying which generation of PPDU it is, including 11be. The U-SIG is two symbols of 64FFT-based OFDM and can transmit a total of 52 bits of information. Of these, 43 bits excluding the CRC / tail 9 bits are roughly divided into a VI (Version Independent) field and a VD (Version Dependent) field.

[0070] The VI bit will maintain the current bit configuration, and even if a subsequent generation PPDU is defined, a current 11be terminal can obtain information about the PPDU from the VI field of the PPDU. To this end, the VI field is composed of PHY version, UL / DL, BSS color, TXOP, and Reserved fields. The PHY version field is 3 bits, and serves to sequentially distinguish 11be and subsequent generation WLAN standards by version. 11be has a value of 000b. The UL / DL field distinguishes whether the corresponding PPDU is an uplink / downlink PPDU. The BSS color means a BSS-specific identifier defined in 11ax, and has a value of 6 bits or more. The TXOP means a transmit opportunity duration that was transmitted in the MAC header, but by adding it to the PHY header, the length of the TXOP containing the corresponding PPDU can be inferred without decoding the MPDU, and has a value of 7 bits or more.

[0071] The VD field may be composed of fields commonly used in any PPDU format, such as PPDU format and BW, which are signaling information useful only for PPDUs of the 11be version, and fields defined differently for each PPDU format. The PPDU format is a division factor that distinguishes EHT SU (Single User), EHT MU (Multiple User), EHT TB (Trigger-based), EHT ER (Extended Range) PPDU, etc. The BW field mainly signals five basic PPDU BW options of 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), and various remaining PPDU BWs formed by preamble puncturing. After being signaled at 320 MHz, some 80 MHz may be signaled in a punctured form. Also, the punctured and modified channel shape may be directly signaled in the BW field, or may be signaled using both the BW field and a field that appears after the BW field (e.g., 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. The MU PPDU and the SU PPDU may be signaled in the same PPDU format, and a field for distinguishing the MU PPDU from the SU PPDU may be located before the EHT-SIG field, and additional signaling may be performed for this purpose. Both the SU PPDU and the MU PPDU include an EHT-SIG field, but some fields that are not necessary 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, in the case of the SU PPDU, the common field of the EHT-SIG may be omitted or replaced, or the user-specific field may be replaced or reduced to one, and may have a different configuration.

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

[0074] When a part 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, etc.). In the case of the 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 transmitted to itself. 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 of the EHT-SIG field and / or MCS, which is a modulation method. The EHT-SIG field may include the size and location information of the RU assigned to each user.

[0075] In the case of a 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 if it recognizes 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, etc.). That is, in the case of a 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 may signal the type of discontinuous channels that appear within the bandwidth.

[0076] The form of the 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, in the case of a SU PPDU, since it is a PPDU transmitted only to a single UE, the STA can recognize the bandwidth allocated to itself from the BW field included in the PPDU, and can recognize the punctured resources of 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 unit. In this case, the 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 SU PPDU. Since puncturing may be performed for each 20 MHz subchannel, if puncturing is performed for 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 as discontinuous) must be signaled by expressing whether or not the remaining 15 20 MHz subchannels other than the primary channel are used. In this way, using 15 bits to signal discontinuous channel types for single user transmission may result in excessive signaling overhead when considering the low transmission speed of the signaling part.

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

[0079] In addition, in one embodiment of the present invention, a method is proposed in which the configuration of the PPDU indicated by the preamble puncturing BW value is different depending on the PPDU format signaled in the PPDU format field. Assuming that the BW field is 4 bits, in the case of EHT SU PPDU or TB PPDU, one symbol of EHT-SIG-A is further signaled after U-SIG, or EHT-SIG-A does not need to be signaled from the beginning, so that up to 11 puncturing modes must be completely signaled using only the BW field of U-SIG in consideration of this. However, in the case of EHT MU PPDU, EHT-SIG-B is further signaled after U-SIG, so up to 11 puncturing modes can be signaled in a different manner from SU PPDU. In the case of EHT ER PPDU, the BW field is set to 1 bit, and it is possible to signal whether the PPDU uses a 20 MHz or 10 MHz band. Detailed puncturing patterns for each PPDU type will be described in detail below with reference to FIG. 11 and FIG. 12.

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

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

[0082] 8, a PPDU may be composed of a preamble and a data portion, and the format of an EHT PPDU, which is one type, may be distinguished by a U-SIG field included in the preamble. Specifically, whether the format of the PPDU is an 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] Fig. 8(d) shows an example of an EHT ER SU PPDU format used for single-user transmission with an STA in an extended range. The EHT ER SU PPDU may be used for single-user transmission with a STA in a wider range than the EHT SU PPDU described in Fig. 8(a), and the U-SIG field may be repeatedly positioned on the time axis.

[0087] The EHT MU PPDU described in FIG. 8(c) 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 PPDU transmitted through a user specific field of the EHT-SIG-B to the STA. 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 on the configuration of resource units (e.g., the division form of resource units) in a specific bandwidth (e.g., 20 MHz, etc.) 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 receives the PPDU. Information on the STA allocated (or designated) to each divided resource unit may be included in the 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, a user field corresponding to at least one of the divided resource units used for data transmission may include the AID of a receiver or sender, and a 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 one wireless communication device communicates using multiple links, the communication efficiency of the wireless communication device can be improved. In this case, the link is a physical path, and may be configured as one wireless medium that can be used to transmit MSDU (MAC service data unit). For example, when the frequency band of any one link is being used by another wireless communication device, the wireless communication device can continue to communicate using another link. In this way, the wireless communication device can effectively use multiple channels. Also, when the wireless communication device simultaneously communicates using multiple links, the overall throughput can be increased. However, the existing wireless LAN is specified on the premise that one wireless communication device uses one link. Therefore, a wireless LAN operation method for using multiple links is required. A wireless communication method of a wireless communication device using multiple links will be described with reference to Figs. 9 to 26. First, a specific form 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] For the wireless communication method using the above-mentioned multiple links, a multi-link device (MLD) may be defined. The multi-link device may represent a device having one or more affiliated stations. According to a specific embodiment, the multi-link device may represent a device having two or more affiliated stations. Also, the multi-link device may exchange a multi-link element. The multi-link element includes information on 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 called a multi-link logical entity (MLLE) or a multi-link entity (MLE). The multi-link device may have one MAC service access point (SAP) up to a logical link control (LLC). Also, the MLD may have one MAC data service.

[0094] The stations included in the multilink device can operate on multiple links. Also, the stations included in the multilink device can operate on multiple channels. Specifically, the stations included in the multilink device can operate on different links or different channels. For example, the stations included in the multilink device can operate on different channels of 2.4 GHz, 5 GHz, and 6 GHz.

[0095] The operation of the multilink device may be referred to as multilink operation, MLD operation, or multi-band operation. If a station associated with the multilink device is an AP, the multilink device may be referred to as AP MLD. If a station associated with the multilink device is a non-AP station, the multilink device may 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 through a first link (Link1). Also, the second AP (AP2) and the second non-AP STA (non-AP STA2) communicate through a second link (Link2). Also, the third AP (AP3) and the third non-AP STA (non-AP STA3) communicate through a third link (Link3).

[0097] The multi-link operation may include a multi-link setup operation. The multi-link setup corresponds to the association operation of the single-link operation described above, and must be performed prior to frame exchange in the multi-link. The multi-link device may obtain information required for the multi-link setup from the multi-link setup element. Specifically, the multi-link setup element may include capability information related to the multi-link. In this case, the capability information may include information indicating whether one of the multiple devices included in the multi-link device can transmit and the other devices can receive at the same time. In addition, the capability information may include information regarding links available to each station included in the MLD. In addition, the capability information may include information regarding channels available to each station included in the MLD.

[0098] The multilink setting may be set by negotiation between peer stations. Specifically, the multilink setting may be set by communication between stations without communication with the AP. The multilink setting may be set through any one of the links. For example, even if the first link to the third link are set through the multilink, the multilink setting may be set through the first link.

[0099] Also, a mapping between a traffic identifier (TID) and a link may be set. Specifically, a frame corresponding to a specific TID value may be exchanged only through a link designated in advance. The mapping between a TID and a link may be set on a directional-based basis. For example, when a plurality of links are set between a first multilink device and a second multilink device, the first multilink device may be set to transmit a frame of a first TID to a plurality of first links, and the second multilink device may be set to transmit a frame of a second TID to the first link. Also, a default setting may exist for the mapping between a TID and a link. Specifically, when there is no additional setting in the multilink setting, the multilink device may exchange frames corresponding to a TID in each link according to a default setting. In this case, the default setting may be that all TIDs are exchanged in any one link.

[0100] The TID will be specifically described. The TID is an ID for classifying traffic and data to support QoS (quality of service). 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). The TID may be classified into 16 types. For example, the TID may be designated as one of 0 to 15. The TID value to be used may be designated differently depending on an access policy, a channel access, or a medium access method. For example, when EDCA (enhanced distributed channel access) or HCAF (hybrid coordination function contention based channel access) is used, the TID value may be assigned in the range of 0 to 7. When EDCA is used, 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 channel contention in EDCA. QoS stations can guarantee QoS using AC. AC 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 ACs. For example, AC_VI may be subdivided into AC_VI primary and AC_VI alternate. AC_VO may be subdivided into AC_VO primary and AC_VO alternate. UP or TID may be mapped to 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 a higher priority in that order. That is, 1 may have a lower priority, and 7 may have a higher priority. Therefore, the priority may be higher in the order of AC_BK, AC_BE, AC_VI, and AC_VO. Also, AC_BK, AC_BE, AC_VI, and AC_VO may correspond to ACI (AC index) 0, 1, 2, and 3, respectively. Due to the characteristics of such a TID, the mapping between a TID and a link may represent the mapping between an AC and a link.Additionally, the mapping between links and ACs can represent the mapping between TIDs and links.

[0102] As described above, a TID may be mapped to each of a plurality of links. The mapping may be a designation of a link through which traffic corresponding to a particular TID or AC may be exchanged. Also, a TID or AC that may be transmitted for each transmission direction within a link may be designated. As described above, there may be a default setting for mapping between a TID and a link. Specifically, if there is no additional setting in the multilink setting, 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 the 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-mentioned 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 in operation or where channel conditions are good. The above-mentioned TID-to-link mapping may also allow stations to stay 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 Fig. 10, as described in Fig. 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 called TID-to-link mapping, TID to link mapping, TID mapping, link mapping, etc. The TID may be a traffic identifier. In addition, the TID may be an ID (identifier) ​​that classifies traffic, data, etc. to support QoS (quality of service).

[0107] Also, the TID may be an ID used or assigned in a layer higher than the MAC layer. The TID may indicate TC (traffic categories) and TS (traffic streams). The TID may have 16 values, and may be indicated as values ​​from 0 to 15, for example. The TID value used may differ depending on the access policy, channel connection, or medium access method. For example, when EDCA (HCF (hybrid coordination function) contention based channel connection, enhanced distributed channel connection) is used, the possible TID value 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. When HCCA (HCF controlled channel access) or SPCA is used, the possible TID value 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 a 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 the set of EDCA parameters may be used for a channel connection. An AC may be used by a QoS STA.

[0109] The value of AC 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. AC_BK, AC_BE, AC_VI, and AC_VO may be further subdivided. For example, AC_VI may be further subdivided into AC_VI primary and AC_VI alternate. AC_VO may be further subdivided into AC_VO primary and AC_VO alternate. UP values ​​or TID values ​​may be mapped to AC values. For example, UP values ​​or TID values ​​1, 2, 0, 3, 4, 5, 6, and 7 may be mapped to AC_BK, AC_BK, AC_BE, AC_BE, AC_VI, AC_VI, AC_VO, and AC_VO, respectively. Alternatively, UP 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. Also, UP or TID values ​​1, 2, 0, 3, 4, 5, 6, and 7 may have increasing priority in that order. That is, 1 may be a lower priority, and 7 may be a higher priority. Therefore, the priority may increase in the order of AC_BK, AC_BE, AC_VI, and AC_VO. Also, AC_BK, AC_BE, AC_VI, and AC_VO may correspond to AC indexes (ACI) 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, the fact that a TID is mapped may mean that an AC is mapped, and vice versa.

[0111] According to an embodiment of the present invention, there may be a TID mapped to each link of a multilink. For example, there may be a mapping of which link among multiple links a specific TID or a specific AC is allowed to transmit or receive on. Such mapping may be defined separately for each of the two directions of the link. As described above, there may be a default setting for the mapping between TIDs and links. For example, the mapping between TIDs and links may basically be such that all TIDs are mapped to a certain link. According to an embodiment, at a specific time, a certain TID or a certain AC may be mapped to at least one link. Also, a management frame or a control frame 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. Or, 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 a good channel condition or a small number of STAs, it may be possible to transmit data of the AC and TID quickly. Alternatively, by performing TID-to-link mapping, it may be possible to help STAs of a particular 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 with Link1, and AP2 and STA2 may be associated with Link2.

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

[0117] For example, all TIDs and all ACs may be mapped to the link for transmission from AP1 to STA1 via Link1, and to the link for transmission from STA1 to AP1 via Link1. Also, only AC_VO or TID corresponding to AC_VO may be mapped to the link for transmission from STA2 to AP2 via Link2. Also, only data of the mapped TID and / or AC can be transmitted on the link. Also, data of TID or AC not mapped to the 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 MLD simultaneous transmit and receive (STR) operation 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 for solving the problem of simultaneous transmission or reception being restricted, and redundant explanations may be omitted. This embodiment may 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 multiple link configuration. As an embodiment, the duration information may be TXOP duration information transmitted in a signaling field of a preamble. The signaling field may be the above-mentioned U-SIG field. Or, the signaling field may be the above-mentioned HE-SIG-A field. As yet another embodiment, the duration information may be duration information indicated by a Duration / ID field included in a MAC header. As yet another embodiment, the duration information may be duration information indicated by a Length field (L Length field) included in an L-SIG field. According to an embodiment, the duration information indicated by the U-SIG field, HE-SIG-A, or Duration / ID field may be a value indicating a TXOP duration. According to an embodiment, 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 an end of a PPDU including the L-SIG field.

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

[0123] According to one embodiment of the present invention, an inter-link NAV may exist. The inter-link NAV may be a NAV used by STAs of multiple links belonging to an MLD when operating with multiple links. For example, transmission may not be required on link 2 based on the inter-link NAV set based on period information received on link 1. Also, 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 sets 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) that is not determined to be intra-BSS or inter-BSS.

[0125] When the inter-link NAV is used separately, it may have an advantage in a situation where the NAV setting is updated compared to when the inter-link NAV is not used. For example, a situation may occur 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 the frame (or PPDU) is determined not to be for the same MLD, the set inter-link NAV may be reset. If there is an MLD operating 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 of 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, so this problem can be solved.

[0126] Although the embodiment of the present invention deals with setting the NAV, the embodiment of the present invention is not limited to this and may be applied to instructing the physical layer to suspend the channel connection or to instructing the channel state to be busy. Also, the embodiment of the present invention is not limited to resetting the NAV and may be applied to instructing the physical layer to continue the channel connection or to instructing the channel state to be idle. At this time, a primitive exchanged between the physical layer and the MAC layer may be used. Or, a primitive exchanged between one STA of the MLD and another STA may be used. Or, a primitive exchanged between one MAC layer of 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 stop channel connection. As described above, the channel connection can be stopped based on the received period information, but there may be a time from the time when the PPDU reception starts to the time when the period information is obtained depending on the position of the field including the period information or the time required for decoding. Therefore, if the channel is accessed and transmission is started during this time, the above-mentioned problem may occur. Therefore, according to an embodiment of the present invention, the STA of the MLD can suspend the channel connection from the time when the other STA of the MLD starts receiving. Also, if it is confirmed that the received frame is not intended for the other STA after the other STA of the MLD starts receiving, the channel connection can be resumed.

[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 regarding 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 an MLD, other STAs belonging to the same MLD can suspend or resume channel connection or transmission. In the present invention, suspending channel connection or transmission may include operations such as setting (updating) NAV, determining a channel as busy, and suspending CCA. Resuming channel connection or transmission may include operations such as resetting NAV, canceling NAV setting, determining a channel as idle, and performing CCA. Hereinafter, these operations may be instructed as suspending and resuming channel connection. Hereinafter, it may be explained that STA1 and STA2 belong to the MLD and that STA1 and STA2 operate on link 1 and link 2, respectively. In addition, a frame and a PPDU may be mixed for instruction. In addition, the NAV at this time may be intra-BSS NAV or 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 obtains duration information from the L-SIG, STA2 can maintain the suspended state of the channel connection. At this time, STA2 can determine that the suspended state of the channel connection will last until the end of the frame received by STA1. Also, when STA1 cannot correctly decode the L-SIG (if it is an invalid L-SIG), STA2 can resume the channel connection.

[0132] Also, STA1 may receive the TXOP duration and BSS color from the U-SIG of the frame received. If the received BSS color indicates intra-BSS or the BSS color is the BSS color corresponding to STA1, the channel connection may 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 started 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 may 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] Or, STA1 may receive 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. Or, STA1 may not be able to successfully decode the U-SIG. In such a case, STA2 may resume the 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 not received by STA1. 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 the state in which the channel connection is interrupted.

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

[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] Also, STA2 may 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 STA-ID indicates broadcast, STA2 can maintain the state in which the channel connection is suspended. At this time, 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 receive the MAC header of the frame it receives. If the RA or DA included in the received MAC header is an indicator that does not apply to STA1, for example, if 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 the channel connection. Or, STA1 may not be able to receive all the MAC headers. For example, STA1 may fail to receive all the MPDUs included in the A-MPDU. In this case, STA2 can resume the channel connection.

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

[0142] According to an embodiment of the present invention, the above-mentioned 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 or an HE-SIG-B field, etc. 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 showing an example of BSS classification and an operation based thereon according to an embodiment of the present invention.

[0144] According to an 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 or not a received frame or a received PPDU corresponds to a BSS to which a classified STA belongs. Or, classifying a BSS may mean an operation of classifying whether or not a received frame or a received PPDU is transmitted from a BSS to which a classified STA belongs. Also, classifying a BSS may include an operation of classifying whether or not a received frame or a received PPDU corresponds to a BSS to which a classified STA does not belong. Or, classifying a BSS may mean an operation of classifying whether or not a received frame or a received PPDU is transmitted from a BSS to which a classified STA does not belong. Also, classifying a BSS may include an operation of classifying to which BSS a received frame or a received PPDU belongs. Or, classifying a BSS may mean an operation of classifying to which BSS a received frame or a received PPDU is transmitted. According to an embodiment of the present invention, a BSS to which a classification STA belongs may be called an intra-BSS. Or, a BSS including a BSS to which a classification STA belongs may be called an intra-BSS. Also, a BSS that is not an intra-BSS may be called an inter-BSS. Or, a BSS that is not an intra-BSS may be an inter-BSS or an unclassified BSS. Or, an inter-BSS may include an unclassified BSS. Also, a BSS to which a classification STA does not belong may be called an inter-BSS.

[0145] According to an embodiment, if it is determined that a received frame or a received PPDU corresponds to an intra-BSS or is transmitted from an intra-BSS, the received frame or the received PPDU may be called an intra-BSS frame or an intra-BSS PPDU, respectively. Also, if it is determined that a received frame or a received PPDU corresponds to an inter-BSS or is transmitted from an inter-BSS, the received frame or the received PPDU may be called an inter-BSS frame or an inter-BSS PPDU, respectively. Also, a PPDU including an intra-BSS frame may be an intra-BSS PPDU. Also, a PPDU including an inter-BSS frame may be an inter-BSS PPDU.

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

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

[0148] The BSS classification condition may include a condition based on a MAC address. The MAC address may be included in a MAC header of a frame. The MAC address may include a receiver address (RA), a transmitter address (TA), a BSSID, a source address (SA), a destination address (DA), and the like. According to an embodiment, a BSS may be classified based on a MAC address included in a received frame. If a MAC address included in a received frame is different from a BSSID of a BSS corresponding to an STA, the received frame may be classified as an inter-BSS frame. More specifically, if all of the MAC addresses included in a received frame are different from the BSSID of a BSS corresponding to an STA, the received frame may be classified as an inter-BSS frame. Also, if a MAC address included in a received frame is the same as the BSSID of a BSS corresponding to an STA, the received frame may be classified as an intra-BSS frame. More specifically, if at least one of the MAC addresses included in a received frame is the same as the BSSID of a BSS corresponding to an 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. Also, the corresponding BSS may include a BSS included in the same multiple BSSID set as the BSS to which the STA is associated. Also, the corresponding BSS may include a BSS included in the same co-hosted BSSID set as the BSS to which the STA is associated. Also, information on one or more BSSs included in the same multiple BSSID set or the same co-hosted BSSID set may be transmitted by one frame.

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

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

[0152] The BSS classification condition may include a condition for the AP to receive 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 an uplink or downlink is set to a pre-set value. The signaling indicating whether it is an uplink or downlink may be included in the signaling field of the HE PPDU. Alternatively, the signaling indicating whether it is an uplink or downlink may be included in the U-SIG. The U-SIG may be included in the preamble of the EHT PPDU or the PPDU after the EHT standard.

[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 satisfied, a PPDU cannot be classified as an intra-BSS PPDU or an inter-BSS PPDU.

[0154] In addition, when classifying a BSS, if the classification results based on multiple conditions do not match, it is possible to determine the final result based on the previously set conditions. For example, if the result based on the condition based on the BSS color does not match the result based on the condition based on the MAC address, the result based on the condition based on the MAC address can be prioritized or determined as the final result. Or, 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, the STA may perform an operation based on the 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. When a pre-set condition is satisfied, the intra-PPDU power save operation may be performed. The pre-set condition may include a condition for classifying a received PPDU as an intra-BSS PPDU. Also, the pre-set condition may include a condition that an intended receiver of a received PPDU is not the STA that received the PPDU. For example, if an ID or address included in a 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 a preamble of the PPDU. For example, the ID may be a STA_ID included in a preamble of the PPDU. Also, the STA_ID may be included in a HE MU PPDU or an EHT PPDU. Also, the addresser may be the MAC address described above. Also, when 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. Also, when the configuration of the received PPDU is set to be not supported by the STA that received the PPDU, 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, the number of spatial streams, the channel width, etc. of the PPDU. Also, when 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. Also, when the received PPDU is in a format that has already been set, the intended recipient of the PPDU may not be the STA that received the PPDU. The already set 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 as a response to the 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 the information included in the trigger frame may include a length of the responding PPDU, an RU to be used when responding, a PHY configuration to be used when responding, a MAC configuration, etc. The intra-PPDU power save operation may be an operation that can enter a doze state until the end of a received PPDU. As yet another embodiment, when it is determined that the intended recipient of a PPDU or frame received by a STA is not the STA, reception or decoding of the PPDU or frame may be suspended.

[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. Also, when a STA receives a PPDU or a frame, the STA may set a NAV corresponding to a classified BSS based on the received PPDU or the received frame. For example, an intra-BSS NAV may be a NAV corresponding to an intra-BSS PPDU. Also, a basic NAV may be a NAV corresponding to a PPDU that is not an intra-BSS PPDU. Or, a basic NAV may be a NAV corresponding to an inter-BSS PPDU. Also, when setting a NAV based on a received PPDU or a received frame, duration information included in a received PPDU or a received frame may be used. The duration information may include a TXOP. TXOP may mean a value included in a TXOP field. The TXOP field may be included in a preamble of a PPDU. For example, the TXOP field may be included in an HE-SIG-A field of a HE PPDU. Alternatively, the TXOP field may be included in the U-SIG field of the EHT PPDU or the post-EHT standard PPDU. Also, the duration information may be included in the MAC header. For example, the duration information may 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. Also, the operation based on the classified BSS may include a channel access operation. The spatial reuse operation may be a channel access operation. When the STA receives a PPDU or a frame, if a pre-set condition is satisfied, the spatial reuse operation can be performed. The pre-set condition may include a condition that the received PPDU or the received frame corresponds to an inter-BSS. Also, the pre-set condition may include a condition that the signal strength of the received PPDU or the received frame is smaller than a threshold. For example, the threshold may be variable. Also, the threshold may be a threshold for an OBSS PD-based spatial reuse operation. Also, the threshold may be a value equal to or greater than the CCA threshold. Also, the threshold may be a value based on the power to be transmitted. The spatial reuse operation may include an operation of transmitting a PPDU. Also, the spatial reuse operation may 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. Spatial reuse operations may also 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, there may be BSS A and BSS B, which may be different BSSs. Furthermore, BSS A and BSS B may correspond to inter-BSS. That is, a PPDU or frame transmitted by a STA coupled to BSS A in BSS B may be classified as an inter-BSS PPDU or an inter-BSS frame. Furthermore, there may be STA1 and STA2 belonging to BSS A (or coupled to an AP operating BSS A). There may be STA3 and STA4 belonging to BSS B (or coupled to an AP operating BSS B). Referring to FIG. 13, STA1 may transmit a PPDU. Furthermore, the PPDU transmitted by STA1 may include information on the BSS. For example, the information on the BSS may be information for classifying the above-mentioned BSS. Furthermore, 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. Also, since STA2 and STA1 belong to BSS A, the PPDU received by STA2 may be classified as an intra-BSS PPDU. Also, 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-mentioned embodiment, STA2 can perform intra-PPDU power save. Referring to FIG. 13, STA2 may enter a doze state until the end time of the received PPDU. Also, 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. In addition, since STA3 and STA1 belong to BSS B and BSS A, respectively, the PPDU received by STA3 may be classified as an inter-BSS PPDU. In addition, STA3 can set the NAV based on the Duration information included in the received PPDU. Since STA3 has classified the received PPDU as an inter-BSS PPDU, it can set the basic NAV.

[0161] STA4 receives the PPDU transmitted by STA1 and can classify the BSS for this PPDU. In addition, 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. In addition, the signal strength of the PPDU received by STA4 may be smaller 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 smaller than a threshold, STA4 can perform spatial reuse operation. Therefore, STA4 can perform channel connection, backoff procedure, and start transmission. For example, STA4 may be able to start transmission at a time when the PPDU transmitted by STA1 has not ended.

[0162] FIG. 14 shows the functions of a 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 functions of a previous WLAN standard. This is for backward compatibility. For example, a STA supporting a specific WLAN standard may support the functions of a previous generation WLAN standard and further support new functions. For example, an HT STA may support the basic functions of an OFDM PHY STA. Therefore, an HT STA may be classified as an OFDM PHY STA. An HT STA may also support additional functions that an OFDM PHY STA does not support, in addition to the functions of an OFDM PHY STA. A VHT STA may support the basic functions of an HT STA while supporting the functions that an HT STA does not support. A VHT STA may be classified as an HT STA. An HE STA may also support the functions that an VHT STA does not support while supporting the basic functions of a VHT STA. 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 functions of an HE STA while supporting the functions that an HE STA does not support. Also, the EHT STA may be classified as a HE STA. Also, a new WLAN standard may be defined after the EHT standard. In the present invention, the standard after the EHT standard is called the NEXT standard, and the STA following the NEXT standard is called the NEXT STA. The NEXT STA supports basic functions of the EHT STA and can also support functions that the EHT STA does not support. The 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, if it is an EHT STA, it may be an HE STA, a VHT STA, a HT STA, or an OFDM PHY STA. Also, if it is a NEXT STA, it may be an EHT STA, a HE STA, a VHT STA, a 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 that solicits 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 including 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 indicates that the interval between the previously received PPDU and the PPDU including the response is SIFS. Specifically, it may be that the response is transmitted after SIFS from 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. Also, the triggering frame may be a frame including the trigger information in a MAC header. In this case, the trigger information may be TRS (triggered response scheduling) included in the HT Control field, Control subfield, or A-Control subfield of the MAC header. Also, the trigger information may be information that triggers the transmission of a TB PPDU.

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

[0169] The triggering frame may include information required 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 PPDU. Also, when the preambles of the PPDUs transmitted by the multiple STAs are different from each other, it may be difficult for the access point to receive the TB PPDU. In particular, when RUs in which TB PPDUs in different formats are transmitted overlap, it may be difficult for the access point to receive the TB PPDU. Therefore, multiple STAs transmitting responses to one triggering frame can use TB PPDUs in the same format. Also, the preamble information of the TB PPDUs transmitted by multiple STAs transmitting responses to one triggering frame may be the same.

[0171] As described in Fig. 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 FIG. 15, an AP transmits a trigger frame that schedules the transmission of an HE STA (HE STA) and an EHT STA (EHT STA). At this time, if the trigger frame does not instruct 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) can transmit TB PPDUs of different formats. This may cause the transmission of the TB PPDU to fail, resulting in the waste of a transmission opportunity. For convenience of explanation, the trigger frames defined in the HE, EHT, and NEXT standards are called HE trigger frame, EHT trigger frame, and NEXT trigger frame, respectively. In addition, the TRS defined in the HE, EHT, and NEXT standards are called HE TRS, EHTTRS, and NEXT TRS. The format of the trigger frame is described in FIG. 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, FIG. 16(a) shows the format of a trigger frame, FIG. 16(b) shows the Common Info field of the trigger frame, and FIG. 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. At this time, 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 play a role in extending the frame length to secure the time required for the receiving STA to prepare a response, and may be optionally present.

[0175] The Common Info field may include a Trigger Type subfield. The Trigger Type subfield identifies a trigger frame variant. The trigger frame may indicate the type of the trigger frame by the value of the Trigger Type subtype. In addition, the Trigger Dependent Common Info subfield may determine the information included in the Trigger Dependent User Info subfield and the lengths of the Trigger Dependent Common Info subfield and the Trigger Dependent User Info subfield, depending on the Trigger Type subfield. For example, the Trigger Type subfield may be indicated by bits B0 to B3 of the Common Info field.

[0176] Also, the Common Info field may include a UL Length subfield. The UL Length subfield may include information on the length of the TB PPDU responding to the Trigger frame. Or, the UL Length subfield may include information on the length of the frame responding to the Trigger frame. Also, the UL Length subfield may indicate a value included in the Length subfield of the L-SIG of the TB PPDU responding to the Trigger frame. Therefore, the STA responding with the TB PPDU may 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, the STA responding with the TB PPDU may set the Length subfield of the L-SIG of the TB PPDU with 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 an HE-SIG-A field or a U-SIG field, of a TB PPDU responding to a trigger frame, and may indicate a maximum bandwidth of a TB PPDU responding to a trigger frame.

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

[0179] The User Info field may include an AID12 subfield. The AID12 subfield may serve to indicate the intended recipient of the User Info field including the AID12 subfield or the function of the User Info field. Thus, the AID12 subfield may serve to indicate the intended recipient of the trigger frame including the AID12 subfield or the function of the trigger frame. For example, if the value of the AID12 subfield is a previously set value, the User Info field may indicate a RA-RU (random access resource unit). More specifically, if the value of the AID12 subfield is 0, the User Info field may indicate a RA-RU for associated STAs. Also, if the value of the AID12 subfield is 2045, the User Info field may indicate a RA-RU for unassociated STAs. Also, the value of the AID12 subfield may indicate that the STA ID indicated by the value of the AID12 subfield, for example, the STA corresponding to the AID (association ID), the User Info field including the AID12 subfield or the trigger frame including the AID12 subfield triggers a response. For example, the AID12 subfield may indicate the AID or 12 LSB of the AID. The STA corresponding to the value of the AID12 subfield may respond to the trigger frame with a TB PPDU. Also, the value of the AID12 subfield may range from 1 to 2007 (inclusive). Also, if the AID12 subfield is a previously set value, for example, 2046, it may indicate that the corresponding RU is not assigned to any STA. Also, if the AID12 subfield is a previously set value, for example, 4095, it may indicate that padding of the trigger frame begins.

[0180] Also, 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 the RU. In this case, the value of the RU Allocation subfield of the User Info field including the AID12 subfield may be information corresponding to the STA indicated by the AID12 subfield. Also, 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 described above, problems may occur depending on the PPDU format in which the TB PPDU, which is transmitted simultaneously in response to the trigger frame, is transmitted. A method of transmitting a triggering frame related to this will be described with reference to FIG.

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

[0183] An EHT STA according to an embodiment of the present invention can selectively transmit an HE TB PPDU or an EHT TB PPDU. Also, 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. This increases the efficiency of the use of the transmission medium. 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] In addition, information for selecting the TB PPDU format may be included in the trigger frame or the TRS or the PPDU including the trigger frame or the PPDU including the TRS.

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

[0186] Also, the distinction between the HE trigger frame, the EHT trigger frame, and the NEXT trigger frame may mean the same as the distinction between the TB PPDU format in response to the trigger frame, which is HE TB PPDU, EHT TB PPDU, and NEXT TB PPDU. That is, the format of the TB PPDU corresponding to the trigger frame 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 at the same time. However, the HE trigger frame cannot instruct the transmission of the EHT TB PPDU.

[0187] In a specific embodiment, it may be determined whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame according to a Frame Control field of a MAC header included in the trigger frame. For example, it may be determined whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame according to at least one of a Type subfield, a Subtype subfield, or a Control Frame Extension subfield of a Frame Control field of a MAC header included in the trigger frame. For example, when a Type subfield, a Subtype subfield, or a Control Frame Extension subfield of a Frame Control field of a MAC header included in the trigger frame is a first value, the trigger frame may be classified as an HE trigger frame. Also, when a Type subfield, a Subtype subfield, or a Control Frame Extension subfield of a Frame Control field of a MAC header included in the trigger frame is a second value, the trigger frame may be classified as an EHT trigger frame. Also, when a Type subfield, a Subtype subfield, or a Control Frame Extension subfield of a Frame Control field of a MAC header included in the trigger frame is 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, the Subtype subfield, and the 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 according to a Common Info field included in the trigger frame. For example, if the value of the Trigger Type subfield of 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 of 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 of 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 of the Common Info field of the trigger frame is 0 to 7, the trigger frame may be classified as an HE trigger frame. Also, if the value of the Trigger Type subfield of the Common Info field of the trigger frame is not 0 to 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 the trigger types that can be used in the future using the limited bit field values.

[0189] In yet another specific embodiment, the trigger frame may be determined as an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame according to a UL Length field included in the trigger frame. For example, if the remainder of the UL Length field of the trigger frame divided by 3 is a first value, the trigger frame may be classified as an HE trigger frame. If the remainder of the UL Length field of the trigger frame divided by 3 is a second value, the trigger frame may be classified as an EHT trigger frame. If the remainder of the UL Length field of the trigger frame divided by 3 is a third value, the trigger frame may be classified as a NEXT trigger frame. If the remainder of the UL Length field of the trigger frame divided by 3 is not 0, the trigger frame may be classified as an HE trigger frame. If the remainder of the UL Length field of the trigger frame divided by 3 is 1, the trigger frame may be classified as an HE trigger frame. If the remainder of the UL Length field of the trigger frame divided by 3 is 0, the trigger frame may be classified as an EHT trigger frame or a NEXT trigger frame. In addition to the value of the UL Length field of the trigger frame, it may also be determined whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame 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, the trigger frame may be determined to be an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame according to a User Info field included in the trigger frame. Specifically, the trigger frame may be determined to be an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame according to a value of the AID12 subfield of the User Info field of the trigger frame. For example, the trigger frame may be determined to be an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame according to whether the value of the AID12 subfield of the User Info field of the trigger frame is a pre-specified 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 determine the type of the trigger frame early. In yet another specific embodiment, the User Info field including the AID12 subfield indicating the type of trigger frame may be located after the User Info field for HE STA in the User Info field list. This can prevent problems caused by the legacy STA, i.e., the HE STA, being unable to determine the meaning of the value of the AID12 subfield. Also, the User Info field including the AID12 subfield indicating the type of trigger frame may not include subfields other than the AID12 subfield. This is because the User Info field is for indicating the trigger frame type, and information other than the trigger frame type may not be necessary.In such an 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 such an 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 the 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 the 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 as a response to the trigger frame according to 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 as a response to the trigger frame based on whether the User Info field that triggers the STA is located after the User Info field including the AID12 field having a pre-specified value. In this case, the STA may determine the format of the TB PPDU to be transmitted as a response to the trigger frame based on whether the User Info field that triggers the STA is located after the User Info field including the AID12 field having a first value and after the User Info field including the AID12 field having a second value. In the embodiment of FIG. 17, when the User Info field that triggers the STA is located after the User Info field including the AID12 field having 2047, the STA may transmit the EHT TB PPDU as a 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 HE 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] Depending on the Padding field of the trigger frame, it may be determined whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame. For example, depending on whether the Padding field of the trigger frame includes a pre-specified value, it may be determined whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame.

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

[0195] Additionally, the above-described embodiments may be used to determine the format of a TB PPDU to be sent in response to a 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 HT Control field may include a TRS. Also, the TRS may be included in the TRS Control field. The Control List field may be located contiguous with the A-Control field. In this case, the Control List field may include a TRS.

[0198] The STA that is the intended recipient of the MAC frame including the TRS can transmit a PPDU based on the field including the TRS. In this case, the TRS may include information (UL Data Symbols) on the length of the PPDU or frame that the STA transmits as a response to the MAC frame including the TRS. It may also include information on the power of the response transmission to the MAC frame including the TRS (AP Tx Power, UL Target RSSI), the location and size of the RU used when transmitting the response to the MAC frame including the TRS (RU Allocation), and information on the modulation method of the response transmission to the MAC frame including 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 the TB PPDU to be transmitted as a response to the TRS depending on the format of the TRS, i.e., which WLAN standard the TRS is defined in. 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 which WLAN standard the TRS is defined in 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 including the TRS is an HE variant, an EHT variant, or a NEXT variant. When the HT Control field including the TRS is an EHT variant, the TRS may be an EHT TRS. When the HT Control field including the TRS is a NEXT variant, the TRS may be a NEXT TRS. In addition, the format of the TRS may be determined depending on the value of a pre-specified bit among the bits of the HT Control field including the TRS, whether the HT Control field is an HE variant, an EHT variant, or a NEXT variant. For example, when 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. In addition, based on the first and second bits (B0, B1) of the HT Control field and an additional bit, for example, the 32nd bit (B31), whether the HT Control field is an HE variant, an EHT variant, or a NEXT variant may be determined.

[0201] In the embodiment of Fig. 18, when TRS is included in the HE PPDU, the STA receiving the HE PPDU transmits the HE TB PPDU as a response to the TRS. When TRS is included in the EHT PPDU, the STA receiving the EHT PPDU transmits the EHT TB PPDU as a response to the TRS. When TRS is included in the NEXT PPDU, the STA receiving the EHT PPDU transmits the NEXT TB PPDU as a response to the TRS.

[0202] Also, the information indicated by the subfield included in the TRS may change depending on the PPDU format in which the TRS is included. When the TRS is included in the HE PPDU, the subfield related to the MCS included in the TRS, for example, the UL HE-MCS subfield, can indicate a value corresponding to the HE MCS table. When the TRS is included in the EHT PPDU, the subfield related to the MCS included in the TRS, for example, the UL HE-MCS subfield, can indicate a value corresponding to the EHT MCS table. When the TRS is included in the NEXT PPDU, the subfield related to the MCS included in the TRS, for example, the UL HE-MCS subfield, can indicate a value corresponding to the NEXT MCS table. Also, the information indicated by the RU Allocation subfield may change 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 FIG. 19, a part or whole of a TXOP set by an AP is shared with a non-AP STA, and the non-AP STA can transmit a PPDU (PLCP Protocol Data Unit) to another non-AP STA (third STA) and / or the AP using the shared TXOP. Hereinafter, in the present invention, sharing a TXOP with another STA can be called TXOP sharing. Also, a STA may be an AP or AP-STA that transmits a trigger frame, or a non-AP STA that receives a trigger frame. Also, a STA can share a TXOP or receive a TXOP shared.

[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 on 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 the 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 within a TXOP configured by a STA to other STAs.

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

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

[0210] Such TXOP sharing may be set by a specific frame. That is, a part or all of the TXOP set by the specific frame may be instructed to be shared, and the STA may receive the frame and use the shared TXOP. In this case, the specific frame may be transmitted by the STA sharing the TXOP. For example, the TXOP sharing may be performed by a trigger frame transmitted by the AP. In this case, the trigger frame for TXOP sharing may be a specific type of trigger frame (e.g., MU-RTS frame, 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, when the value of the trigger type subfield is set to a previously set value (e.g., "3"), the STA receiving the trigger frame can recognize that the TXOP is shared and can transmit a PPDU with 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, the CTS frame may be transmitted as an immediate response to the 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 called a modified MU-RTS frame or an MU-RTS TXS trigger frame. However, the present invention is not limited thereto, and the frame for sharing a TXOP may be called by various names.

[0212] The sharing of a part or the whole 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 sharing a TXOP using a frame, one or more STAs for TXOP sharing may be indicated by the frame. In this case, the sharing of a TXOP 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 sharing the TXOP (e.g., a modified MU-RTS frame). For example, the modified MU-RTS frame may include a UL length subfield, which may 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 the 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 previously set value, the MU-RTS frame may be a modified MU-RTS frame for TXOP sharing. In this case, the specific field may be a GI and HE-LTF type subfield. For example, if a type field included in a trigger frame indicates an MU-RTS frame, it may be identified whether the MU-RTS frame is a trigger frame for TXOP sharing depending on the value of the GI and HE-LTF type subfield. That is, if the GI and HE-LTF type subfield are set to previously set values, the trigger frame may be a trigger frame for TXOP sharing.

[0215] Alternatively, whether the 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 a User Info field or a User Info List field described in FIG. 16. Specifically, whether the 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 the 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 the MU-RTS frame is not a frame for TXOP sharing, the MU-RTS frame may be an MU-RTS frame that instructs 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. Or, the STA that received the TXOP sharing in response to the 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 the STA that received the TXOP sharing in the shared TXOP described above, and a PPDU including a frame transmitted by the STA that received the TXOP sharing in the shared TXOP, respectively. 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 an embodiment of the present invention, a CTS frame may be transmitted in response to the modified MU-RTS frame. The CTS frame may be transmitted by a STA that receives a TXOP share. In this case, the STA that receives a TXOP share may transmit the frame immediately after transmitting the CTS frame. The STA that receives a TXOP share may transmit the frame immediately after transmitting a PPDU including the CTS frame. The frame transmitted immediately after transmitting the CTS frame may be included in a PPDU transmitted by a STA that receives a TXOP share in the above-mentioned shared TXOP. Alternatively, the frame transmitted immediately after transmitting the CTS frame may be included in the above-mentioned non-TB PPDU and transmitted. In addition, in the present invention, transmitting immediately may mean transmitting at a time point after a SIFS or PIFS time from the end of a PPDU including a CTS frame. The CTS frame may serve to inform a STA that receives a TXOP share that it has received the TXOP share.

[0219] According to another embodiment, a CTS frame may not be transmitted in response to the modified MU-RTS frame. Also, a STA receiving a TXOP share may transmit a frame immediately after the modified MU-RTS frame. Or, a STA receiving a TXOP share may transmit a PPDU immediately after a PPDU including a modified MU-RTS frame. In this case, the frame to be transmitted may be included in a PPDU transmitted by a STA receiving a TXOP share in the shared TXOP described above. Or, the frame to be transmitted may be included in a non-TB PPDU and transmitted. Also, in the present invention, transmitting immediately after may mean transmitting at a time SIFS or PIFS later from the end of a PPDU including a modified MU-RTS frame.

[0220] According to an embodiment, the modified MU-RTS frame may include signaling as to whether the STA receiving the TXOP sharing should transmit a CTS frame. According to an embodiment, when the STA receiving the TXOP sharing transmits a frame to be sent to the AP, it may use the shared TXOP without a CTS frame. Also, when the STA receiving the TXOP sharing transmits a P2P frame, it may use the shared TXOP by transmitting a CTS frame. Also, 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 know whether the STA receiving the TXOP sharing has 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 a MU-RTS frame. The MU-RTS frame may be an existing MU-RTS frame. The MU-RTS frame may include duration information regarding a 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 a TXOP holder. The TXOP holder may be a STA that has obtained a TXOP. The TXOP holder may transmit a frame that it wishes to transmit in the TXOP. In this case, STA2 may be a TXOP responder. The TXOP responder may be a STA that has transmitted a response to a 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 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 TA (transmitter address) of the modified MU-RTS frame can be set to the MAC address of STA1 or a value based on the MAC address of STA1. The RA (receiver address) of the modified MU-RTS frame can be set to the MAC address of STA2 or a value based on the MAC address of STA2. In addition, the User Info field included in the modified MU-RTS frame can indicate STA2 with an AID12 subfield value. That is, the User Info field included in the modified MU-RTS frame can indicate 12LSB of the AID of STA2 with an AID12 subfield value. The modified MU-RTS frame can include information regarding the duration of the shared TXOP.

[0223] According to one embodiment, STA2 may transmit a CTS frame in response to the modified MU-RTS frame. Also, STA2 may transmit a frame after transmitting the CTS frame. The frame that STA2 transmits after transmitting the CTS frame may not be a CTS frame. According to yet another embodiment, STA2 may not transmit a CTS frame in response to the modified MU-RTS frame. In this case, STA2 may transmit a frame that is not a CTS frame after transmitting the modified MU-RTS frame. Also, the frame that is not a CTS frame that STA2 transmits after receiving the modified MU-RTS frame may be a frame that STA2 transmits to STA1 according to one embodiment. According to another embodiment, the frame that is not a CTS frame that STA2 transmits after receiving the modified MU-RTS frame may be a frame that STA2 transmits 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 STA). In this case, when the AP intends to share a part 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., GI and HE-LTF type subfield) of the trigger frame to a previously set value. In this case, the specific field can be called a GI and HE-LTF type / triggered TXOP sharing mode subfield. Specifically, when 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, when 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 a value of "1" or "2" and interpreted as the triggered TXOP sharing mode subfield. If the value of the GI and HE-LTF type / triggered TXOP sharing mode subfield is "1" or "2", the trigger frame can be called a modified MU-RTS frame or a MU-RTS TXS trigger frame. When an AP shares a part or all of a TXOP set by an AP, the GI and HE-LTF type / triggered TXOP sharing mode subfield of the trigger frame for TXOP sharing indicates the sharing mode of the TXOP. For example, the GI and HE-LTF type / triggered TXOP sharing mode subfield indicates whether the TXOP is shared only in transmission and reception with the AP that set the TXOP, or in transmission and reception with a third STA (and other STAs) in addition to the AP. That is, when the value of the GI and HE-LTF type / triggered TXOP sharing mode subfield is "1", a STA with a shared TXOP can transmit a PPDU only to the AP.However, when 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 in the shared TXOP. That is, when the value of the GI and HE-LTF type / triggered TXOP sharing mode subfield is "2", the STA can also perform P2P communication in the shared TXOP.

[0225] Table 1 below shows an example of the presence or absence 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 in accordance with one embodiment of the present invention.

[0228] The embodiment of Fig. 20 may be an embodiment for explaining the problem of difficulty in performing the operation explained in Fig. 19 and a method for solving the problem. The contents explained in Fig. 19 may be omitted.

[0229] According to an embodiment of the present invention, the 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 a 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. There may also be cases where the STA includes multiple NAVs. For example, the STA may include an intra-BSS NAV and a basic NAV. The intra-BSS NAV may be a NAV set by an intra-BSS frame or an intra-BSS PPDU. Regular NAV may be a NAV set by an inter-BSS frame or inter-BSS PPDU or intra-BSS, or a frame or PPDU that cannot be determined to be inter-BSS. Also, when at least one of intra-BSS NAV and basic NAV is a value greater than 0, virtual CS may be busy. Or, when at least one of intra-BSS NAV and basic NAV is a value greater than 0, it can be said that NAV is a value greater than 0. When intra-BSS NAV and basic NAV are both 0, virtual CS may be idle. Or, when intra-BSS NAV and basic NAV are both 0, it can be said that NAV is 0.

[0230] For a certain STA, an intra-BSS frame or an intra-BSS PPDU may be a frame or a PPDU that is determined to be transmitted from the same BSS as the STA. For a certain STA, an inter-BSS frame or an inter-BSS PPDU may be a frame or a PPDU that is determined to be transmitted from a BSS different from that of the STA. In addition, the determination as to whether it is transmitted from the same BSS or a different BSS may be determined based on a BSS color field included in the preamble of the PPDU, an address field included in the MAC header, etc. For example, if the BSS color field or the address field is a value corresponding to the same BSS, it can be determined to be an intra-BSS frame or an intra-BSS PPDU. In addition, if the BSS color field or the address field does not include a value corresponding to the same BSS, it 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 is not 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 a received frame or a 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 be able to transmit a 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, a STA may be able to transmit a frame regardless of NAV if the received frame is addressed to the STA and requires an immediate response, even if NAV is set to a value greater than 0. In addition, when a frame is addressed to a STA, the RA field of the frame may be set to the address of the STA. Or, when a frame is addressed to a STA, the frame may include 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 the received frame is sent from the TXOP holder, the STA may be able to send a response to it regardless of the NAV. In this case, the NAV may be the NAV set by the frame or PPDU sent by the TXOP holder. Or, the NAV may be an intra-BSS NAV. Also, the received frame may be an RTS frame. It can be determined that the frame was sent from the TXOP holder based on the TA field included in the frame. The STA can store the TXOP holder address. If the STA receives an RTS frame sent by the TXOP holder and the RTS frame is addressed to the STA, it can respond to the RTS frame without considering the NAV. In this case, a CTS frame can be sent as a response to the RTS frame.

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

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

[0238] The contents 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. At this time, STA2 may transmit a CTS frame because the physical CS result of STA2 is idle and basic NAV is not set. Or, STA2 may transmit a CTS frame because STA2 has received a frame addressed to itself and requesting an immediate response. At this time, even if other frame exchanges occur in addition to the exchange of MU-RTS and CTS frames, STA2 can transmit a response frame based on the frame received from STA1 because the frame is addressed to STA2 and requests an immediate response. Furthermore, STA2 may 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] Also, STA1 can perform TXOP sharing 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 1) transmit a CTS frame and then transmit another frame, or 2) transmit another frame without transmitting a CTS frame. However, at this time, STA2 may have difficulty transmitting a frame because its NAV is set. For example, STA2 may have its NAV set by a frame transmitted by STA1 to obtain a TXOP before allocating a shared TXOP. That is, STA2 may have its NAV set by receiving a frame transmitted by STA1 before transmitting a modified MU-RTS frame. Alternatively, STA2 may have its NAV set by receiving a frame transmitted from another STA with the same TXOP before receiving a modified MU-RTS frame addressed to itself. Alternatively, STA2 may have its NAV set based on a modified MU-RTS frame addressed to itself. That is, since STA2 is expected to receive at least the modified MU-RTS frame when using the shared TXOP, the NAV may be set, which may make it difficult for STA2 to transmit a frame using the shared TXOP.

[0240] Therefore, according to one embodiment of the present invention, a STA that has received a TXOP shared can transmit a frame regardless of the NAV. For example, a STA that has received a TXOP shared can transmit a frame regardless of the NAV in the shared TXOP. For example, a STA that has received a TXOP shared can transmit a frame 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 shared can transmit a frame regardless of the intra-BSS NAV. Also, a STA that has received a TXOP shared may not be able to transmit a frame when the basic NAV is set. Or, a STA that has received a TXOP shared can transmit a frame 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 shared is set by a frame sent by a STA that is not the associated AP, it may not be able to transmit a frame in 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 NAV may be set in the shared TXOP by the AP. In this case, the STA that receives the shared TXOP may be unable to transmit a PPDU due to the NAV set in the shared TXOP. Therefore, the STA that receives 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 thereto.

[0243] In addition, at this time, the frame transmitted by the STA that has received the shared TXOP, 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 shared TXOP transmits a frame, it may take the NAV into consideration if the frame is transmitted PIFS after the previous PPDU.

[0245] Referring to FIG. 20, the NAV of STA2 may be set based on the MU-RTS frame or the modified MU-RTS frame. For example, the intra-BSS NAV may be set. Alternatively, the NAV of STA2 may be set based on the intra-BSS frame. Alternatively, the NAV of STA2 may be set based on the frame transmitted by the associated AP. In this embodiment, the NAV may collectively refer to such NAVs. STA1 may perform TXOP sharing with STA2. STA2 may receive TXOP sharing by the modified MU-RTS frame. When transmitting a frame with a shared TXOP, STA2 may transmit a frame regardless of the NAV. In this case, according to one embodiment, the frame to be transmitted may be a frame transmitted immediately after the CTS frame transmitted immediately after the received modified MU-RTS frame. In yet another embodiment, the frame to be transmitted may be 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 including 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 description can be omitted.

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

[0249] According to an embodiment of the present invention, the STA that has received the TXOP sharing may transmit a CTS-to-self frame in response to the 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, the STA that shares the TXOP may determine that the shared TXOP allocation has been successful when it receives a frame including the MAC address of the STA that receives the TXOP sharing after transmitting the modified MU-RTS frame.

[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 the MAC address of STA2 in the RA field of the CTS frame and transmit the CTS frame. In this case, the CTS-to-self frame sent by STA2 can be regarded as a frame addressed to itself and requesting an immediate response. Alternatively, STA2 can regard the transmission of the CTS-to-self frame as receiving a frame addressed to itself and requesting an immediate response. 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 FIG 21, a further method of setting the RA field of a CTS frame may be defined to transmit a CTS-to-self frame. For example, the MAC address of the STA transmitting the CTS frame may be set in the RA field of a CTS frame transmitted in response to a modified MU-RTS frame.

[0252] According to an embodiment of the present invention, a STA that has received a TXOP sharing may be able to perform recovery within the shared TXOP. That is, a STA that has received a TXOP sharing may perform recovery when a frame that the STA has transmitted within the shared TXOP fails. For example, a STA that has received a TXOP sharing may transmit a frame at a time point that is PIFS later when a frame that the STA has transmitted within the shared TXOP fails. According to an embodiment of the present invention, a TXOP holder may perform recovery. In addition, when a TXOP holder performs a TXOP sharing, a STA that has received the TXOP sharing may perform recovery. That is, recovery may be performed when a STA that is neither a TXOP holder nor a TXOP responder becomes a STA that has received the TXOP sharing. In addition, a STA that has received a TXOP sharing may perform a recovery operation when it transmits a first non-CTS frame after receiving a modified MU-RTS frame, if the non-CTS frame fails. For example, the TXOP holder may not be able to perform a recovery operation if the first frame it transmits in the sequence fails, and in this case, the TXOP may not have been obtained. However, the STA that received the TXOP can perform a recovery operation even if the first frame, other than the CTS frame, it transmits 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 it 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 be possible to check whether the channel is idle during recovery. In addition, the recovery operation performed by the STA that has received the TXOP sharing may take into account only the physical CS without taking into account the virtual CS.

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

[0255] As described in FIG. 19, whether or not 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 be designed without considering the extension of functions in subsequent standards. Therefore, for example, the common information field shown in FIG. 16(b) may have insufficient signaling space to include an extended function. Therefore, according to an embodiment of the present invention, the user information field including the pre-set AID12 subfield value may have a format different from that shown in FIG. 16(c). In addition, the user information field including the 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 the pre-set AID12 subfield value may include at least one of information of a PHY version ID, a bandwidth extension, a bandwidth, spatial reuse, and U-SIG reserved bits. Also, the previously set AID12 subfield value may be based on a value that is not assigned as an actual AID. The previously set AID12 subfield value may be 12 LSBs of a value that is not assigned as an actual AID. For example, the previously set AID12 subfield value may be 2007.

[0256] The extended capabilities may include, for example, an extended bandwidth, for example, from a maximum of 160 MHz to a maximum of 320 MHz, and may include 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 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, the modified MU-RTS frame may not include any user information field or may only include a user information field including the previously set AID12 subfield value as described above. That is, if the received trigger frame does not include any user information field or may only include a user information field including the previously set AID12 subfield value as described above as a user information field, the trigger frame can be determined as a modified MU-RTS frame. Alternatively, if the received MU-RTS frame does not include any user information field or may only include a user information field including the previously set AID12 subfield value as described above as a user information field, 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 have one user information field, and the AID12 subfield included in the user information field may be set to a previously set value. In this case, the previously set value may be a value that is not assigned as an AID. The previously set value may be a value different from the 12 LSBs of the AID of the STA having the RA field value of the modified MU-RTS frame as its MAC address. For example, the previously set value may be 2007. Alternatively, the modified MU-RTS frame may not include any user information field. That is, when the Type of the trigger frame is set as the MU-RTS frame, the STA that receives the trigger frame may determine that the trigger frame is a modified MU-RTS frame if the trigger frame does not include any user information field or includes only a user information field including an AID12 subfield with a previously set value.

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

[0261] According to an embodiment of the present invention, a STA may be able to reset a set NAV. For example, when a NAV is set based on an RTS frame or an MU-RTS frame, the NAV may be reset. More specifically, when a NAV is set based on an RTS frame or an MU-RTS frame, the NAV may be reset if PPDU reception cannot be successfully started within a previously set time. Such an operation may be called a NAV timeout. The previously set time may be called 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, when the NAV is set based on the RTS frame or the MU-RTS frame, it may mean that the most recent NAV update was based on the RTS frame or the MU-RTS frame. If the duration information received by the STA from the RTS frame or the MU-RTS frame is greater than the current NAV value of the STA, the NAV may be set or updated based on the RTS frame or the MU-RTS frame. The duration information may be obtained based on the Duration / ID field included in the MAC header, or based on the TXOP duration or the TXOP field included in the preamble of the PPDU.

[0263] In addition, in an embodiment of the present invention, when PPDU reception is successfully started, a PHY-RXSTART.indication primitive may be received. Alternatively, when PPDU reception is successfully started, a PHY-RXSTART.indication primitive may be issued. The PHY-RXSTART.indication primitive may be transmitted from the PHY to the MAC. For example, when the PHY receives a valid start of the PPDU, the PHY-RXSTART.indication primitive may be generated. Furthermore, receiving a valid start of the PPDU may mean receiving a valid PHY header. Furthermore, the PHY-RXSTART.indication primitive may be generated after determining the PPDU format. When the PHY-RXSTART.indication primitive is generated, the PHY may keep the physical medium in a busy state for the length of the PPDU or for a length indicated by the preamble of the PPDU. 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 preamble of the PPDU even if the PPDU reception fails midway. Also, a PHY-RXEND.indication may be generated when the PPDU reception is terminated.

[0264] According to an embodiment of the present invention, the above-mentioned 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 a 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 an embodiment, the CTS_Time may be calculated based on a previously set rate. That is, the CTS_Time may be the length of the CTS frame calculated based on the previously set rate. Or, that is, the CTS_Time may be the length of the PPDU including the CTS frame calculated based on the previously set rate. For example, the previously set rate may be 6 Mbps. For example, the CTS_Time may be calculated based on a data rate of 6 Mbps. Or, the previously set rate may be the rate of the RTS frame or MU-RTS frame for setting the NAV. Or, the previously set rate may be the rate indicated by the RTS frame or MU-RTS frame for setting 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 the 6 GHz band.

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

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

[0270] According to an embodiment of the present invention, the RTS frame may be a frame indicating a CTS frame. Or, 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 a NAV. The RA field may include an address of an intended immediate recipient. For example, when an STA receives an RTS frame and includes an RA field that is an address of the STA, the STA can respond to the RTS frame with a CTS frame. The fact that a frame is an RTS frame may be determined based on a frame Control field included in the frame. For example, the fact that a frame is an RTS frame may be determined based on a Type subfield and a Subtype subfield included in a 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 can indicate 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 a NAV. For example, if the Type subfield is 01 (B3 B2) and the Subtype subfield is 1100 (B7 B6 B5 B4), it can be indicated that 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 an MU-RTS frame to STA2. For example, if the RA field of the RTS frame or the MU-RTS frame is set to the address of STA2, the RTS frame or the MU-RTS frame may be transmitted to STA2. Or, 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. At this time, STA2 may respond based on a CS (carrier sense) result. Also, when STA3 receives the RTS frame or the MU-RTS frame, STA3 may set NAV based on duration information included in the RTS frame or the MU-RTS frame or 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 for STA3 to cancel the NAV it set.

[0273] Referring to the second sequence of FIG. 23, there may be STA1, STA2, and STA3. Also, 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 not be able to respond with a CTS frame. Or, STA2 may successfully receive the RTS frame or the MU-RTS frame, but may not be able to respond with a CTS frame based on the CS result. In such a case, the frame sequence sent by STA1 to STA2 may not continue.

[0274] Also, when STA3 receives the RTS frame or the MU-RTS frame, STA3 can set the 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, STA3 may be unable to receive the CTS frame transmitted by STA2 or the frame transmitted by STA1 to STA2 after STA3 sets the NAV. In such a case, STA3 may not be able to receive the PHY-RXSTART.indication primitive within the NAVTimeout period. Therefore, the NAV set by STA3 can be cancelled. This solves the problem that STA3 maintains the NAV and cannot access the channel even though the sequence is not continuing.

[0275] FIG. 24 illustrates TXOP sharing and NAV timeout in one embodiment of the present invention.

[0276] Referring to FIG. 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 FIG. 24, the first frame of the sequence that STA1 transmits to STA2 may be an MU-RTS frame. Also, a CTS frame that is a response to the MU-RTS frame may be transmitted.

[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 perform TXOP sharing with STA2. STA3 may successfully receive the modified MU-RTS frame. Therefore, STA3 may set a NAV based on the modified MU-RTS frame. In this case, STA3 may set a NAV based on the MU-RTS frame. According to the above-mentioned TXOP sharing sequence, STA2 may 1) transmit a CTS frame for the modified MU-RTS frame, and transmit a frame immediately after transmitting the CTS frame. Or, STA2 may 2) transmit a frame without transmitting a CTS frame for the modified MU-RTS frame. STA3 may not receive a frame or PPDU from STA2. For example, STA3 may be in a position hidden from STA2. For example, the power transmitted by STA2 may not be sufficient to be received by STA3. In such a case, STA3 may not be able to receive the PPDU in 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 of STA3 should end while the frame is transmitted. Or, 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 of STA3 should end while the frame is transmitted. Therefore, STA3 may be able to release the NAV. If STA3 releases the 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 in yet another embodiment of the present invention.

[0279] Referring to Fig. 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 the STA with which the TXOP is shared does not transmit a CTS frame or other frames for a certain period of time. The embodiment of Fig. 25 may be for solving 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 a trigger frame (e.g., MU-RTS frame) transmitted from an AP is a modified MU-RTS frame for sharing a TXOP or an MU-RTS TXS trigger frame. That is, depending on whether a TXOP is a commonly set TXOP or whether all or part of a TXOP set by an AP is a shared TXOP, it may be determined whether a NAV timeout for releasing a TXOP set by other STAs other than the STA to which the TXOP was set is allowed or not.

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

[0282] However, if the NAV is set by a modified MU-RTS frame or MU-RTS TXS trigger frame, which is a frame for sharing a part or all of the set TXOP, the NAV timeout may not be allowed. In other words, if a STA sets the NAV based on a MU-RTS frame, and the MU-RTS frame is a modified MU-RTS frame or 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 a 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 or not the received MU-RTS frame is a modified MU-RTS frame may be determined according to the above-mentioned embodiment. For example, whether or not the MU-RTS frame is a modified MU-RTS frame may 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 FIG. 24, where a STA disrupts the sequence of shared TXOPs by performing a NAV timeout operation after setting a NAV based on a modified MU-RTS frame.

[0286] Also, such an embodiment may be performed by terminals following the 802.11be standard (terminals following standards including the EHT standard) and may not be performed by terminals following the 802.11ax standard (HE STAs). Even if the HE STAs are unable to perform this, they can reduce the probability of the problems described in the above embodiment occurring.

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

[0288] Also, STA1 may transmit a modified MU-RTS frame. In FIG. 25, the frame before the modified MU-RTS frame may be omitted. STA2, which is the intended recipient of the modified MU-RTS frame, may respond to the modified MU-RTS frame. Also, STA3 may set 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 the response sent by STA2 to STA3 is not heard with sufficient power. For example, this may be because STA3 and STA2 are far away from each other. In such a case, STA3 may not be able to successfully start PPDU reception in the NAVTimeout period. This may be because STA2 transmits a frame after transmitting a CTS frame after the modified MU-RTS frame. Or, this may be because STA2 transmits a frame longer than the CTS frame after the modified MU-RTS frame. Or, 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 take action to clear the NAV based on the NAV timeout action. This may be because the frame that caused STA3 to set the NAV is the MU-RTS frame, which is a modified MU-RTS frame.

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

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

[0291] According to an embodiment of the present invention, the NAV timeout period may be determined to be different depending on whether the MU-RTS frame is a modified MU-RTS frame. For example, the CTS_Time may be determined to be different 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 called the extended NAVTimeout period. The NAVTimeout period and the extended NAVTimeout 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 NAVTimeout 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 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 the STA fails to successfully receive a PPDU within the extended NAVTimeout period, the STA may be able to cancel the NAV. When a STA sets a NAV based on a modified MU-RTS frame, if the STA fails to successfully start receiving a PPDU within the NAVTimeout period described in FIG. 23, the STA may not be able to cancel the NAV.

[0293] In addition, when a STA sets a NAV based on a 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 FIG. 23.

[0294] According to an embodiment of the present invention, the extended NAVTimeout period may be determined based on the length information included in the modified MU-RTS frame. For example, the 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 the rate corresponding to the modified MU-RTS frame. For example, the CTS_Time may be determined based on the length information included in the modified MU-RTS frame and the 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. As 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 indicating the STA that receives the TXOP sharing, among the User Info fields shown in FIG. 16.

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

[0296] Referring to FIG. 26, there may be STA1, STA2, and STA3. STA1 may transmit a MU-RTS frame to STA2. For example, STA1 may transmit a MU-RTS frame that is not a modified MU-RTS frame. However, STA2, which is the intended recipient of the MU-RTS frame, may not be able to respond to the MU-RTS frame. Therefore, STA2 may not be able 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 be able to successfully start PPDU reception in the NAVTimeout period. In this case, based on a NAV timeout operation, STA3 may cancel the set NAV. This may be an operation based on the determined NAVTimeout period because the frame for which STA3 set the NAV is a 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, which is the intended recipient of the modified MU-RTS frame, may respond to the modified MU-RTS frame. Also, STA3 may set a 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 the response sent by STA2 to STA3 is not heard with a sufficiently large power. For example, this may be because STA3 and STA2 are far apart. In such a case, STA3 may not be able to successfully start PPDU reception in the NAVTimeout period described in FIG. 23. However, in such a case, STA3 may be able to successfully start PPDU reception in the extended NAVTimeout period. Therefore, STA3 does not need to perform a NAV timeout operation. The reason why STA3 is able to wait for the extended NAVTimeout period without performing NAV cancellation operation when the NAVTimeout period described in FIG. 23 has elapsed may be because the frame in which STA3 sets the NAV is 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, and thus successfully start receiving PPDUs before STA3 performs a NAV timeout operation.

[0299] Or, if STA2 that received the modified MU-RTS frame cannot respond, the shared TXOP sequence may be terminated. In this case, STA3 can solve the problem of not being able to connect to the channel because it unnecessarily sets NAV when no actual frame exchange occurs by performing a NAV timeout operation.

[0300] In TXOP sharing, a scheduled STA that receives a part or all of a TXOP set by an AP has difficulty in transmitting according to a set NAV and a solution to the problem has been described with reference to Fig. 20. A solution according to another embodiment will be described with reference to Fig. 27. Hereinafter, a scheduled STA and a STA with a shared 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, the scheduled STA may not set the NAV. Specifically, in TXOP sharing, the scheduled STA may not set the NAV based on the modified MU-RTS frame or the MU-RTS TXS trigger frame, which is the MU-RTS frame for TXOP sharing setting. The STA that receives the MU-RTS frame for TXOP sharing setting may not set the NAV based on the MU-RTS frame for TXOP sharing setting. The STA scheduled by the MU-RTS frame for TXOP sharing setting may not set the NAV based on the MU-RTS frame for TXOP sharing setting. Therefore, when the STA receives a trigger frame and the trigger frame schedules the STA for TXOP sharing, the STA may not set the NAV based on the trigger frame. That is, depending on whether the trigger frame is a trigger frame for sharing TXOP, the STA may set the NAV based on the received trigger frame. For example, when the received MU-RTS frame is a modified MU-RTS frame or an MU-RTS TXS trigger frame for sharing TXOP, the STA does not set the 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 in the shared TXOP.

[0304] In this case, the term "within the shared TXOP" may refer to the time when the shared TXOP is terminated even if the duration of the shared TXOP is not fully utilized. When the scheduled STA of the shared TXOP transmits a PPDU, and the PPDU includes only frames that do not request an immediate response, the STA transmits the PPDU, and the TXOP is terminated. Therefore, the term "within the shared TXOP" may be the time when the scheduled STA of the TXOP sharing transmits a PPDU including only frames that do not request an immediate response from the time when the TXOP sharing is set. When the scheduled STA of the TXOP sharing signals the end of the shared TXOP, the shared TXOP may be terminated. Therefore, the term "within the shared TXOP" may be the time when the scheduled STA of the TXOP sharing signals the end of the shared TXOP from the time when the TXOP sharing is set to the time when the scheduled STA of the TXOP sharing signals the end of the shared TXOP. Also, the term "within the TXOP" may be the time when the shared TXOP duration has elapsed from the time when the TXOP sharing is set. Alternatively, the shared TXOP may be terminated when the STA that received the TXOP sharing (or the STA that shared the TXOP) transmits or receives signaling that the shared TXOP is terminated. In this case, the duration of the shared TXOP and the TXOP used by the AP for sharing (the TXOP acquired by the first AP frame) are the same, or the duration of the shared TXOP is shorter than the duration 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 and the duration of the TXOP are the same, the TXOP is also terminated when the shared TXOP is terminated, but if the duration of the shared TXOP is shorter than the duration of the TXOP, the TXOP may be maintained even if the shared TXOP is terminated.

[0305] In yet another specific embodiment, within the shared TXOP period may be from when the TXOP sharing is set 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 a frame regardless of the NAV. That is, when a NAV is set in a TXOP set by an AP (for example, a NAV set by an intra-BSS PPDU), a scheduled STA can transmit a PPDU in a shared TXOP regardless of the set NAV. In other words, a STA that has received a shared TXOP can transmit a frame in the shared TXOP ignoring the NAV set by a frame transmitted by a STA that shared the TXOP. In this case, the shared TXOP may be terminated before the interval set by the MU-RTS frame. That is, a STA that has received a shared TXOP before the interval set by the MU-RTS in the shared TXOP can suspend the sharing of the TXOP by transmitting signaling to request suspension of the sharing of the TXOP. For example, when a non-AP STA receives a shared TXOP in whole or in part from an AP, if there is no PPDU to transmit (or pending), the non-AP STA can suspend the sharing of the TXOP by transmitting signaling to the AP to terminate the TXOP sharing in order to terminate the shared TXOP. The time when TXOP sharing is stopped may be one of the time when the non-AP STA transmits a signaling requesting the stop of TXOP sharing or the time 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, the non-AP STA can ignore the NAV set only until the time when TXOP sharing ends, since TXOP sharing is stopped earlier than the period in which the TXOP is shared set by the MU-RTS frame.

[0307] At this time, the STA that has set up TXOP sharing can also transmit frames regardless of NAV. In the embodiment of FIG. 27, the first STA (STA1) transmits an MU-RTS frame for TXOP sharing setting to the second STA (STA2). At this time, the first STA (STA1) may be an AP. The second STA (STA2) receives the MU-RTS frame for TXOP sharing setting and transmits a CTS frame as a response to the MU-RTS frame for TXOP sharing setting. The second STA (STA2) performs frame exchange within the shared TXOP. The first STA (STA1) can set the NAV based on a frame transmitted by the second STA (STA2) or transmitted to the second STA (STA2). For example, the second STA (STA2) can perform frame exchange with the third STA (STA3) within the shared TXOP. At this time, the first STA (STA1) can set the NAV based on a frame transmitted by the third STA (STA3) to the second STA (STA2). Also, the first STA (STA1) may set the NAV based on a frame transmitted by the second STA (STA2) to the third STA (STA3). When the first STA (STA1) sets the NAV in this manner, it may be difficult for the shared TXOP to transmit a frame in 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 according to the NAV set in the shared TXOP. Specifically, if the frame included in the PPDU transmitted in the shared TXOP is not a frame that induces an immediate response from the first STA (STA1), the first STA (STA1) may be unable to transmit the frame according to the set NAV.

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

[0309] At this time, 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 has received the TXOP sharing may transmit signaling to request the suspension of the TXOP sharing, thereby suspending 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 be transmitted (or pending), the non-AP STA may transmit signaling to the AP to terminate the TXOP sharing in order to terminate the shared TXOP, and suspend the TXOP sharing. The time at which the TXOP sharing is suspended may be one of the time at which the non-AP STA transmits signaling to request the suspension of the TXOP sharing or the time at which the non-AP STA receives a response frame to the signaling. At this time, the signaling for the TXOP sharing may or may not request an immediate response. In this case, since TXOP sharing is interrupted earlier than the period during 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 transmitted and received by the non-AP STA.

[0310] In the above embodiment, the STA that has set the TXOP sharing transmits a frame regardless of the NAV based on a frame exchanged by a scheduled STA in the TXOP sharing. When the STA that has set the TXOP sharing transmits a frame regardless of the NAV based on a frame that is not exchanged by a scheduled STA in the TXOP sharing, it may interfere with frame exchange by other STAs. In addition, the STA can determine whether a frame is exchanged by a scheduled STA in the TXOP sharing based on the MAC header of the frame. Specifically, the STA can determine whether a frame is exchanged by a scheduled STA in 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 can determine whether a frame is exchanged by a scheduled STA in the TXOP sharing. In addition, the STA can determine whether a frame is exchanged by a scheduled STA in the TXOP sharing based on the preamble of the PPDU including the frame. In addition, the STA can determine whether the frame is exchanged by a scheduled STA in the TXOP sharing based on at least one of the BSS color and the STA ID included in the preamble of the PPDU including the frame. If the preamble of the PPDU includes the BSS color of the BSS to which the scheduled STA of the TXOP sharing belongs and the preamble of the PPDU includes the STA ID corresponding to the scheduled STA of the TXOP sharing, the STA can determine that the frame included in the PPDU is a frame exchanged by the 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 that has configured TXOP sharing to transmit regardless of NAV can only use physical CS (carrier sensing), e.g., CCA, as CS (carrier sensing) when transmitting a frame, and therefore does not need to perform virtual CS.

[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 and the Basic NAV. In addition, unless otherwise specified regarding the type of NAV, the NAV may refer to the Intra-BSS NAV. In this specification, setting the NAV by the STA based on a certain frame may include setting the NAV based on a PPDU including the frame. Therefore, in this specification, not setting the NAV by the STA based on a certain frame may include not setting the NAV based on a PPDU including the frame.

[0313] The MU-RTS frame for setting TXOP sharing can indicate the scheduled STA of the TXOP using a MAC address, e.g., 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 in the 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 in the shared TXOP or the TXOP of a PPDU including the frame may not be allowed to be set beyond the shared TXOP. This can prevent a problem in which a STA that has set a shared TXOP cannot transmit a frame even after the shared TXOP ends.

[0315] That is, when the TXOP set by the AP is shared to the STA by the trigger frame, the duration information (e.g., Duration / ID field) included in the frame (e.g., PPDU) transmitted in the shared TXOP may be set based on the shared TXOP. Specifically, the TXOP of the frame transmitted in the shared TXOP is not allowed to be set beyond the shared TXOP. Therefore, the TXOP of the PPDU transmitted to the AP that set the TXOP in the shared TXOP or the third STA for P2P communication must be the same as or end 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 to a specific STA, the TXOP of the 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 set the shared TXOP in the shared TXOP may not transmit a trigger frame. This is because, when the STA that set the shared TXOP in the shared TXOP transmits a trigger frame, a frame triggered by the trigger frame may overlap with a frame exchange of the scheduled STA. Also, when the STA that set the shared TXOP in the shared TXOP transmits a trigger frame to the scheduled STA, the scheduled STA may need to transmit a response to the trigger frame. Therefore, this may not meet the purpose of setting the shared TXOP. In such an embodiment, the trigger frame may include a MU-RTS frame for setting TXOP sharing. In such an embodiment, after the shared TXOP is terminated, the STA that set the shared TXOP may transmit a trigger frame.

[0318] In the above embodiment, the trigger frame that the STA that set the shared TXOP cannot transmit may be the remaining trigger frame excluding the trigger frame for only the scheduled STA of the TXOP sharing. Therefore, the STA that set the shared TXOP can transmit the trigger frame only to the scheduled STA of the TXOP sharing in the shared TXOP. For example, the STA that set the shared TXOP can transmit the MU-RTS frame for setting the TXOP sharing to extend the shared TXOP. At this time, the STA that receives the MU-RTS frame for setting the TXOP sharing can start the frame exchange without transmitting the CTS frame. Specifically, when only the frame exchange with the STA that set the TXOP sharing is allowed in the TXOP sharing, the STA that receives the MU-RTS frame for setting the TXOP sharing can start the frame exchange without transmitting the CTS frame.

[0319] In this specification, an action performed on a shared TXOP may be an action that utilizes the shared TXOP by a TXOP sharing scheduled STA. The action performed on a shared TXOP may be a frame sent by the TXOP sharing scheduled STA in response to a MU-RTS frame for establishing TXOP sharing, or a frame sent by the TXOP sharing scheduled STA 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 operation will be described. A STA can signal whether it can operate as a scheduled STA for TXOP sharing. In this case, a STA can signal whether it can operate as a scheduled STA for TXOP sharing using an EHT Capabilities element. Also, a STA can 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 that wishes to set up TXOP sharing can transmit an MU-RTS frame for setting up TXOP sharing only to a STA that has signaled that it can operate as a scheduled STA for TXOP sharing. Also, a STA that wishes to set up TXOP sharing may not be able to transmit an MU-RTS frame for setting up TXOP sharing to a STA that has signaled that it cannot operate as a scheduled STA for TXOP sharing.

[0321] Also, the MU-RTS frame may include information indicating whether the MU-RTS frame is an MU-RTS frame for setting TXOP sharing. Also, when the MU-RTS frame is an MU-RTS frame for setting TXOP sharing, the MU-RTS frame may also indicate a mode of TXOP sharing. The mode of TXOP sharing may indicate to which STA the TXOP sharing scheduled STA may transmit frames. For example, in the first mode, the TXOP sharing scheduled STA may transmit frames only to the STA that set the TXOP sharing. Also, in the second mode, the TXOP sharing scheduled STA may transmit frames or P2P frames to the STA that set the TXOP sharing. The first mode may be indicated when the value of the information indicating whether the MU-RTS frame is an MU-RTS frame for setting TXOP sharing is 1. Also, the second mode may be indicated when the value of the information indicating whether the MU-RTS frame is an MU-RTS frame for setting TXOP sharing is 2. In addition, when 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 mode of TXOP sharing as described above. In this case, the GI and HE-LTF Type subfield may be called a 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 of a TXOP share may signal the end of TXOP sharing. When the STA that set up the TXOP share receives the end signaling of TXOP sharing, the STA that set up the TXOP share may become a TXOP holder. Also, when the STA that set up the TXOP share receives the end signaling of TXOP sharing, the STA that set up the TXOP share may transmit a frame or a PPDU. Specifically, when the STA that set up the TXOP share receives the end signaling of TXOP sharing, the STA that set up the TXOP share may transmit a frame or a PPDU even in the shared TXOP. Also, when the scheduled STA of a TXOP share signals the end of TXOP sharing, the scheduled STA of a TXOP share may not be able to transmit any frame or any PPDU in the remaining shared TXOP.

[0326] A scheduled STA of TXOP sharing may use the A-Control subfield to signal the end of TXOP sharing. Specifically, the SRS (single response scheduling) Control subfield of the A-Control subfield may signal the end of TXOP sharing. A STA receiving the SRS Control subfield may respond to a frame including the SRS Control subfield with a PPDU that is not a TB PPDU. Also, the length of a response PPDU to a frame including the SRS Control subfield may be determined based on the SRS Control subfield. Specifically, a STA receiving the SRS Control subfield may set the length of a response PPDU to a frame including the SRS Control subfield to the length indicated by the SRS Control subfield.

[0327] FIG. 28(a) shows the format of the SRS Control subfield. As described 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 units of 4us. The length of the PPDU indicated by the PPDU Response Duration field may be the value of the PPDU Response Duration field x 4us. Also, the PPDU Response Duration field may be an 8-bit field.

[0328] Also, a STA may signal its capability for the SRS Control subfield. Specifically, a STA may signal whether it can receive the SRS Control subfield. Also, a STA may 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 may 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 signaling termination of TXOP sharing. The field signaling 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 Shared TXOP Termination field has a value of 1, the Shared TXOP Termination field may indicate that TXOP sharing is terminated. If the Shared TXOP Termination field has a value of 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 may 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 the pre-specified setting may be a QoS Null frame. Specifically, the frame having the pre-specified setting may be a QoS Null frame that does not include an A-Control subfield. Also, the frame having the pre-specified setting may be a QoS Null frame that does not include an SRS Control subfield. A scheduled STA of TXOP sharing may transmit a frame having a pre-specified setting to signal the end of TXOP sharing. Also, when a STA that has set up TXOP sharing receives a frame having a pre-specified setting, the STA that has set up TXOP sharing may determine that TXOP sharing is to be ended.

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

[0332] In a specific embodiment, when a TXOP sharing scheduled STA that has signaled the end of TXOP sharing receives a response to the signaling, the TXOP sharing scheduled STA may determine that TXOP sharing has ended. In this case, the TXOP sharing scheduled STA may determine that TXOP sharing has ended and may not transmit a frame. The response to the TXOP sharing end signaling may be an immediate response. Also, the response to the TXOP sharing end signaling may be an ACK. However, such an embodiment may be applied only when the ACK policy of the TXOP sharing end signaling is set to request an immediate response. Specifically, when the ACK policy of the TXOP sharing end signaling requests an immediate response, when a TXOP sharing scheduled STA that has signaled the end of TXOP sharing receives a response to the signaling, the TXOP sharing scheduled STA may determine that TXOP sharing has ended. When the Ack Policy of 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 the TXOP sharing has ended. In this case, the TXOP sharing scheduled STA can determine that the TXOP sharing has ended when it transmits the TXOP sharing termination signaling. Also, when 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. Also, the STA that set 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). At this time, the first STA (STA1) may be an AP. The second STA (STA2) receives the MU-RTS frame for TXOP sharing setup and transmits a CTS frame as a response to the MU-RTS frame for TXOP sharing setup. In the shared TXOP, the second STA (STA2) transmits a 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). At this time, the first STA (STA1) determines that the TXOP sharing has not been terminated. As described above, the first STA (STA1) or the second STA (STA1) can perform an error recovery operation. After the error recovery operation, the second STA (STA2) transmits TXOP sharing termination signaling (Frame to STA1 indicating termination) to the first STA (STA1). The first STA (STA1) transmits ACK (Ack to STA2) to the second STA (STA2) as a response to the TXOP sharing termination signaling (Frame to STA1 indicating termination). The second STA (STA2) that receives ACK (Ack to STA2) determines that TXOP sharing has terminated.

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

[0335] As described above, it may be impossible to transmit the SRS Control subfield to a STA that has signaled that it does not support the operation on the SRS Control subfield. When the termination of TXOP sharing is signaled by the SRS Control subfield, the STA that has signaled that it does not support the operation on the SRS Control subfield may not receive the termination signaling of TXOP sharing. Thus, the scheduled STA of TXOP sharing may transmit the SRS Control subfield signaling the termination of TXOP sharing to the STA that has signaled that it does not support the operation on the SRS Control subfield. The SRS Control subfield signaling the termination of TXOP sharing may be the SRS Control subfield with a TXOP Termination subfield value of 1. The scheduled STA of TXOP sharing may not transmit the SRS Control subfield with a TXOP Termination subfield value of 0 to the STA that has signaled that it does not support the operation on the SRS Control subfield. In addition, the restriction of not transmitting the SRS Control subfield to the STA that has signaled that it does not support the operation on the SRS Control subfield may only be applied when the SRS Control subfield is transmitted outside the shared TXOP.

[0336] If the SRS Control subfield signals the end of TXOP sharing, then 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, then the PPDU Response Duration subfield may indicate the length of the PPDU that contains the frame that is the response to the frame that contains the SRS Control subfield.

[0337] When the SRS Control subfield signals the end of TXOP sharing, the STA receiving the SRS Control subfield does not need to transmit a response to the frame including the SRS Control subfield. In yet another specific embodiment, when the SRS Control subfield signals the end of TXOP sharing, the STA receiving the SRS Control subfield can 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 receiving the SRS Control subfield can transmit a response PPDU regardless of the length of the response PPDU to the frame including the SRS Control subfield signaled by 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 an 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 an SRS Control subfield regardless of 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 to a frame including an 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 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 duration information (PPDU Response Duration subfield value) included in the SRS Control subfield.

[0340] According to an embodiment of the present invention, the modified MU-RTS frame does not have to be the first frame in the TXOP. For example, the TXOP holder may not transmit the modified MU-RTS frame to obtain the TXOP, but may transmit another frame. This allows the STA to set the NAV before setting the NAV based on the modified MU-RTS frame. That is, the STA can set the NAV based on a frame transmitted before the modified MU-RTS frame in the TXOP. The above-mentioned NAV timeout operation can be performed when the NAV setting is performed based on the RTS frame or the MU-RTS frame, but by making a frame transmission exist before the modified MU-RTS frame in the TXOP, it is possible to reduce the setting of the NAV based on the RTS frame or the MU-RTS frame. Also, the duration information included 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 a Common Info field and a 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 a format of a TB PPDU based on a User Info field included in the trigger frame. Specifically, a specific User Info field included in the trigger frame can indicate a format of a TB PPDU to be transmitted in response to the trigger frame. For convenience of explanation, the specific 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. Also, it may be a value that the AP does not assign as an AID (association ID). Also, the format of the Special User Info field may be different from the format of the 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 the User Info field that is 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 the User Info field that is 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 the trigger frame including the Special User Info field without error.

[0344] Also, the trigger frame may 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, when the value of the Special User Info Field Present subfield is 1, the trigger frame may not include a Special User Info field. Also, when 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 the 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 include 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 includes 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 unassociated 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. The station may determine a format of a TB PPDU that is a response to the 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 may 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 may transmit an HE 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 may determine a format of a TB PPDU that is a response to the trigger frame based on a 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 may transmit an EHT TB PPDU as a response to the trigger frame. If the value of the Special User Info Field Present field of the trigger frame received by the station is 1, the station can transmit an HE TB PPDU in response to the trigger frame.

[0346] If the trigger frame includes a User Info field that is an EHT variant, the trigger frame may always include a Special User Info field. If the 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 method in which the User Info field of the EHT variant indicates an RU may be different from the method in which the User Info field of the HE variant indicates an RU. Specifically, the method in which the RU Allocation subfield of the User Info field of the EHT variant indicates an RU may be different from the method in which the RU Allocation subfield of the User Info field of the HE variant indicates an RU. For example, the RU Allocation subfield of the User Info field of the EHT variant can indicate an RU index for the User Info field of the EHT variant. Also, the RU Allocation subfield of the User Info field of the HE variant can indicate an RU index for the User Info field of the HE variant. The User Info field of the EHT variant can indicate an RU to be allocated to a station corresponding to the User Info field using the RU Allocation subfield and the PS160 subfield.

[0348] The RU Allocation subfield may be located immediately after the AID12 subfield as described in FIG. 16. 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 including the PS160 subfield is located in. 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 including the PS160 subfield is located in 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 FIG. 29, the station receiving the trigger frame can determine the subfield indicating the format of the TB PPDU transmitted as a response to the trigger frame on a pre-specified channel and the format of the subfield indicating the format of the TB PPDU transmitted as a response to the trigger frame based on the Special User Info field of the trigger frame. In this case, the pre-specified channel may be the primary 160 MHz channel. For convenience of explanation, the subfield indicating the format of the TB PPDU transmitted as a response to the trigger frame is referred to as the HE / EHT P160 subfield. When the HE / EHT P160 subfield indicates the format of the TB PPDU transmitted as a response to the trigger frame on the primary 160 MHz channel as EHT TB PPDU, the station receiving the trigger frame can transmit the EHT TB PPDU as a response to the trigger frame regardless of the location of the RU assigned to the station. In this case, the value of the HE / EHT P160 subfield may be 0. Additionally, 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 as a response to the trigger frame on the primary 160 MHz channel as HE TB PPDU, the station receiving the trigger frame can determine the format of the TB PPDU transmitted as a response to the trigger frame according to 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 as a 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 as a response to the trigger frame. In addition, 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 that received the trigger frame is included in the primary 160 MHz, 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 the trigger frame includes the Special User Info field, the trigger frame may include the HE / EHT P160 subfield and the PS160 field. Figure 29 shows the Common Info field and the Special User Info field to which such an embodiment is applied.

[0353] The above-mentioned EHT TB PPDU may be replaced with NEXT TB PPDU. Therefore, in the above-mentioned embodiment, when EHT TB PPDU is indicated as the format of TB PPDU, NEXT TB PPDU or EHT TB PPDU may be transmitted as TB PPDU. In this case, a station receiving a trigger frame may determine which PPDU to transmit as a response to the trigger frame, EHT TB PPDU or NEXT TB PPDU, based on the Format Identifier subfield. Specifically, a station may transmit a TB PPDU according to the format of TB PPDU 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 a signaling field of the PPDU of the EHT TB PPDU transmitted in response to the trigger frame. At this time, 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 Reuse1 subfield, a Spatial Reuse 2 subfield, a U-SIG Disregard And Validate subfield, a Reserved subfield, and a Trigger Dependent User Info field subfield. At this time, the AID12 subfield may be a 12-bit field. Also, the PHY Version ID subfield may be a 2-bit field. The UL Bandwidth Extension subfield may be a 2-bit field. Also, the Spatial Reuse1 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 above-mentioned 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 the EHT physical layer. The station receiving the trigger frame may set the U-SIG field of the TB PPDU to be transmitted as a response to the trigger frame based on the Special User Info field. Specifically, the station receiving the trigger frame may set the value of the subfield included in the Special User Info field to the value of the subfield of the U-SIG field of the TB PPDU. In this case, the subfield 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 the trigger frame can set the bandwidth (BW) subfield of the U-SIG field of the TB PPDU based on the UL Bandwidth Extension subfield of the Special User Info field and the UL BW subfield of the Common Info field.

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

[0357] The UL Bandwidth Extension subfield may be used when the frequency bandwidth indicated by the trigger frame exceeds 160 MHz. The UL Bandwidth Extension subfield may indicate 320 MHz. The UL BW subfield of the Common Info field may 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 may indicate 20 MHz, 40 MHz, 80 MHz, and 160 MHz, respectively.

[0358] Also, the trigger frame can 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 20MHz, 40MHz, 80MHz, 160MHz, and 320MHz. At this time, the UL BW subfield and the UL Bandwidth Extension subfield can indicate the 320MHz frequency band by distinguishing it into 320-1MHz and 320-2MHz depending on the channel center frequency or starting frequency. When only the UL Bandwidth field is used without the UL Bandwidth Extension subfield, the value of the UL Bandwidth Extension subfield indicating 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 the 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 the 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, a MU-BAR frame, a 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, the HE station that transmits the TB PPDU based on the RA-RU of the trigger frame can transmit the HE TB PPDU based on the RA-RU even if 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 according to the variant of the User Info field corresponding to the station. Specifically, when the User Info field corresponding to the station in the trigger frame is an HE variant, the station can transmit an HE TB PPDU as a response to the trigger frame. Also, when the User Info field corresponding to the station in the trigger frame is an ETH variant, the station can transmit an EHT TB PPDU as a response to the trigger frame. Also, when the User Info field corresponding to the station in the trigger frame is a NEXT variant, the station can transmit a NEXT TB PPDU as a response to the trigger frame.

[0364] 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 EHT TB PPDU, the User Info field corresponding to the station may be the EHT variant. Also, 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 that received 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, 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 that received 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, the 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. Also, 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. When a frequency bandwidth of more than 160 MHz is used in the shared TXOP, the modified MU-RTS frame may indicate the frequency bandwidth of more than 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 of more than 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 sending a frame in response to a modified MU-RTS frame.

[0367] The method of setting the TXVECTOR parameter when the station responds to a modified MU-RTS frame may be different from the method of setting the TXVECTOR parameter when the 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 the 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 the 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 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 related 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 of the TXVECTOR parameter based on whether it will send a PPDU in response to the MU-RTS frame. For example, if the station will send a PPDU in response to the MU-RTS frame, the station can set the TRIGGER_RESPONDING of the TXVECTOR parameter to true. If the station will not send a PPDU in response to the MU-RTS frame, the station can set the TRIGGER_RESPONDING of the TXVECTOR parameter to false.

[0370] Also, the transmission conditions of the station may change depending on the value of TRIGGER_RESPONDING of the TXVECTOR parameter. For example, when TRIGGER_RESPONDING of the TXVECTOR parameter is set to true, the station can transmit according to a pre-specified transmission condition. When TRIGGER_RESPONDING of the TXVECTOR parameter is set to false, the station can transmit regardless of the pre-specified transmission condition or according to a transmission condition that is less stringent than the pre-specified transmission condition. Therefore, the transmission conditions that the station should follow may change depending on whether the station transmits a TB PPDU. Specifically, when the station transmits a TB PPDU, the station can transmit according to a pre-specified condition. Also, when the station transmits a PPDU that is not a TB PPDU, the station can transmit regardless of the pre-specified condition or according to a transmission condition that is less stringent than the pre-specified condition. When a station transmits a non-HT (duplicate) PPDU or a TB PPDU as a response to a MU-RTS frame, multiple stations can transmit PPDUs simultaneously. Therefore, a station receiving a PPDU may have difficulty receiving the PPDU depending on the transmission parameter settings of the stations, the transmission of the PPDUs may not be synchronized, interference may occur between the transmission of the PPDUs, and the transmission power difference of the 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 a transmission sampling symbol clock, and a pre-corrected transmission power. In this case, 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 condition. The pre-specified transmission conditions may also include an error vector magnitude (EVM) condition and a spectral mask condition. 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) error and symbol clock error when transmitting a PPDU as follows using a triggering PPDU, i.e., a PPDU including trigger information, where 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 complementary cumulative distribution function (CCDF) 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: - 350Hz 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 remaining carrier frequency offset error measurement of a non-HT PPDU or a non-HT duplicate PPDU should be performed after the L-STF field. The symbol clock error needs to be compensated 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.4us+16us 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, and therefore the transmission of a response to a modified MU-RTS frame does not require the above-mentioned pre-specified transmission conditions or may be subject to relaxed pre-specified transmission conditions.

[0378] A station may set the TRIGGER_RESPONDING 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 may set the TRIGGER_RESPONDING of the TXVECTOR parameter to false. Also, when a station transmits a response to a non-modified MU-RTS frame, the station may set the TRIGGER_RESPONDING of the TXVECTOR parameter to true. Such an embodiment may be applied when a station transmits a non-HT PPDU or a non-HT duplicate PPDU, as described above.

[0379] In the embodiment of FIG. 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 embodiment, 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 a plurality of 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). In addition, the EDCA parameter sets for each AC included in one EDCA parameter set may have different parameter values. In addition, when the plurality of EDCA parameter sets are classified into a first EDCA parameter set and a second parameter set, the value of an EDCA parameter in the first EDCA parameter set for one AC may be different from the value of an EDCA parameter in the second EDCA parameter set. In addition, the AC may include AC_BE (best effort), AC_BK (background), AC_VI (video), and AC_VO (voice).

[0383] EDCA provides CSMA / CA access according to the priority of each traffic, specifically, AC. The EDCA parameter sets may include a legacy EDCA parameter set and an MU EDCA parameter set. Specifically, the 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 a dot11EDCATable, and the MU EDCA parameter set may be stored in a 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 an embodiment, a contention window (CW) may be determined based on CWmin or CWmax. Also, it may be based on CW 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. Also, when initializing CW, it may be initialized to CWmin. Also, CWmin may be the minimum value that CW can have. CWmax may be the maximum value that CW can have.

[0385] Based on the AIFSN (arbitration interframe space number), the AIFS described in FIG. 6 may be determined. For example, the AIFS may be AIFSN*(slot time(aSlotTime))+SIFS(aSIFSTime). Specifically, the AIFS may be the time that a station waits before accessing a channel again after sensing that the channel is busy. In addition, the AIFS can determine the slot boundary used when accessing a channel again after sensing that the channel is busy.

[0386] A station that has acquired a TXOP (transmit opportunity) can determine the end time of a transmission sequence based on the TXOP limit. Specifically, a station can end a transmission sequence within the TXOP limit in principle, and in some exceptional circumstances, can be allowed to perform a transmission sequence with a duration that exceeds the TXOP limit.

[0387] The station can receive an element indicating a value of a parameter in an EDCA parameter set from an associated AP and set an EDCA parameter set according to the value of the parameter in the EDCA parameter set indicated by the received element. Also, if the station fails to receive an element indicating a value of a parameter in the EDCA parameter set from an 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. In this case, 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 a plurality of elements indicating each parameter set of a plurality of EDCA parameter sets. The element indicating the parameter value of the legacy EDCA parameter set may be an EDCA Parameter Set. 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 the Element ID Extension field that it contains. The Element ID field and the 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 the 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. Also, the MU EDCA Parameter Set element may include an MU parameter record field for each AC. The parameter record field may include an ACI field (AC Index) that indicates which AC each parameter record field corresponds to.

[0392] Furthermore, the parameter record field may 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] The non-AP station performs channel access using a first EDCA parameter set, and if the non-AP station is successful in AP-triggered transmission, the non-AP station may 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 an 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 a remaining duration for which the second parameter set is applied when using the second EDCA parameter set. The timer value is decreased at a constant rate over time, and the non-AP station may use the second EDCA parameter set until the timer value becomes 0. When the timer value becomes 0, the non-AP station may perform channel access using the first EDCA parameter set. Also, when a non-AP station receives an element instructing to reset the EDCA parameter set, the non-AP station may set the timer value to 0. In this case, the timer may be an MU EDCA timer. For convenience of explanation, in this specification, setting a timer value to a non-zero value is described as setting a timer, and an EDCA timer indicating a remaining duration for which the second parameter set is applied is referred to as a timer for application of the second parameter set. In this case, the non-zero value may be a default value included in the EDCA parameter set.

[0395] Also, the parameter value of the first EDCA parameter set may be smaller than the parameter value of the second EDCA parameter set. In this case, the success probability of channel access using the second EDCA parameter set may be smaller than the success probability of channel access using the first EDCA parameter set. This makes it possible to adjust the fairness of channel access between stations.

[0396] A case where a non-AP station succeeds in transmission triggered by an AP may represent a case where a non-AP station succeeds in transmission solicited by a basic trigger frame. Also, a case where a non-AP station succeeds in transmission solicited by a basic trigger frame may be limited to a case where a non-AP station succeeds in transmission of a QoS data frame solicited by a basic trigger frame. A case where a non-AP station successfully transmits a QoS data frame may be defined as follows. If the QoS data frame requests an immediate response, the non-AP station may be deemed to have successfully transmitted a QoS data frame when the non-AP station receives an immediate response to the QoS data frame. Also, if the QoS data frame does not request an immediate response, the non-AP station may be deemed to have successfully transmitted a QoS data frame when the non-AP station transmits a QoS data frame. Thus, 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 may update the EDCA parameters with the second EDCA parameter set. Also, when a non-AP station transmits a QoS data frame that does not request an immediate response, the non-AP station may update the EDCA parameters with the second EDCA parameter set. At this time, the non-AP station may update the EDCA parameters corresponding to the AC of the QoS data frame with the second EDCA parameter set. Also, 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 may set a timer for applying the second EDCA parameter set. At this time, the EDCA timer may be started at the end of the PPDU including the immediate response.In addition, 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, where the timer may be started 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 a 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 having a lower priority than the legacy EDCA parameter set described above. This embodiment allows adjustment of channel access fairness between a station to which a shared TXOP is assigned and a station 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 has received the 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. Thus, 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 has received the MU-RTS TXS trigger frame transmits a response to the MU-RTS TXS trigger frame, the station can perform channel access using the second EDCA parameter set in the shared TXOP. Such an embodiment may be applied only when the MU-RTS TXS trigger frame allows the shared TXOP holder to transmit only to one station, for example, the AP. In other words, such an embodiment may not be applied when the MU-RTS TXS trigger frame allows the shared TXOP holder to transmit to multiple stations, for example, the 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 the first EDCA parameter set to the second EDCA parameter set.

[0402] Also, a station to which a shared TXOP is allocated may set a timer for application of 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 application of the second EDCA parameter set at the time of receiving a response corresponding to a signaling for terminating the shared TXOP. In yet another specific embodiment, a station to which a shared TXOP is allocated may set a timer for application of the second EDCA parameter set at the earlier of the end of the shared TXOP or the time of receiving a response corresponding to a signaling for terminating the shared TXOP. In this case, setting the timer for application of the second EDCA parameter set may be, as described above, setting a value of the timer for application of 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 a CTS frame to the first station (STA1), the second station (STA2) switches 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 application of the second EDCA parameters at the end of the shared TXOP. This is to prevent the timer value from being continuously decreased even though the shared TXOP holder does not perform channel access when setting a timer for application of the second EDCA parameters when the shared TXOP holder switches to the second EDCA parameter set. This can ensure fairness with other stations.

[0404] In FIG. 32 and the like, an embodiment has been described in which after the shared TXOP holder transmits a frame in 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 be transmitting a QoS data frame and receiving an ACK for the transmitted QoS data frame. Additionally, successfully transmitting the QoS data frame may refer to transmitting the QoS data frame when the QoS data frame does not require an immediate response. When the shared TXOP holder successfully transmits the QoS data frame to the shared TXOP allocator in the shared TXOP, the shared TXOP holder sets an EDCA timer for application of the second parameter set, e.g., a value of the MU EDCA timer, to a non-zero value.

[0405] Thus, if the QoS data frame requires an immediate response, the shared TXOP holder can send a 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 a PPDU that includes an 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 a PPDU that includes a QoS data frame to send to the shared TXOP allocator within the shared TXOP.

[0406] In the above embodiment, the embodiment in which the shared TXOP holder switches the EDCA parameters used for channel access from the first EDCA parameter set to the second EDCA parameter set after the shared TXOP holder transmits a frame in the shared TXOP is described as being applicable only to the first shared TXOP mode. This is because it may be difficult for the shared TXOP allocator to monitor frame exchange 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 gain compared to other stations in frame exchange with the shared TXOP allocator.

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

[0408] In a shared TXOP, the shared TXOP allocator can transmit only when 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 transmission of the shared TXOP holder in 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 in the shared TXOP. When no transmission or reception is performed in the shared TXOP for a certain period of time or more, the station can determine that a frame is not exchanged. In addition, when a transmission failure occurs in the shared TXOP, the station can determine that a frame is not exchanged. In this case, when no immediate response is performed to the transmitted frame, the station can determine that the transmission has failed.

[0409] Also, when a station receives a frame that does not request an immediate response, the station can determine that the frame is not 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 is not exchanged. If a station does not successfully receive all MPDUs of an A-MPDU, the station cannot determine whether an A-MPDU includes only MPDUs that do not request an immediate response. Therefore, if a station does not successfully receive all MPDUs of an A-MPDU, the station cannot perform TXOP recovery.

[0410] As described above, when no transmission or reception is performed within a shared TXOP for a certain period of time or more, the station can determine that no frames are exchanged. Specifically, when a channel where TXOP sharing has been performed within a shared TXOP for a certain period of time or more is idle, the station can determine that no frames are exchanged. In this case, the certain period of time may be PIFS. In addition, a channel being idle may be a carrier sense (CS) result of the channel being idle. In this case, CS may be energy detection (ED). When a station senses the energy of a certain signal in the ED that is equal to or greater than an ED threshold, the station can determine that the medium is not idle (busy). In addition, when a station senses the energy of a certain signal in the ED that is smaller than an ED threshold, the station can determine that the medium is idle.

[0411] In this specification, the channel being idle at a TxPIFS slot boundary may be considered as the CS result being idle at PIFS or the channel being idle at PIFS. Also, in this specification, the start of transmission at a particular time, particularly PIFS after the end of a PPDU, may be described on the assumption that the channel is idle at PIFS. Also, in this specification, the inability to start transmission at a particular time, particularly PIFS after the end of a PPDU, may be described on the assumption that the channel is busy at PIFS.

[0412] Also, PIFS may be the sum of SIFS (aSIFSTime) and slot time (aSlotTime). Also, TxPIFS slot boundary may be the time before aRxTxTurnaroundTime from the time point that is PIFS later than the time point when the channel switches to the idle state. Therefore, TxPIFS slot boundary may be TxSIFS slot boundary + aSlotIme. TxSIFS may be the time before aRxTxTurnaroundTime from the time point that is SIFS later than the time point when 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 receiving state to a transmitting state. Specifically, aRxTxTurnaroundTime may be the time it takes for a station to switch from a receiving state to a transmitting state. In yet another specific embodiment, aRxTxTurnaroundTime may be the maximum time it takes for a station to switch from a receiving state to a transmitting 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 the 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] In addition, 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 in the shared TXOP.

[0414] In addition, the above-mentioned TXOP recovery may be applied only when 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 embodiment of FIG. 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). In 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 Fig. 33, we have described a method of recovering a TXOP in a shared TXOP. When the shared TXOP is terminated, the TXOP acquired by the shared TXOP allocator may not be terminated. In this case, a method of recovering the TXOP by the shared TXOP allocator may be required. This is described in Fig. 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 a 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 if and only if:

[0421] A shared TXOP allocator may start transmitting in a shared TXOP if it receives a PPDU in the shared TXOP from the shared TXOP holder requesting an immediate response, or if the channel is idle on a TxPIFS slot boundary from the end of the last immediate response transmission sent to the 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 if and only if:

[0423] If the shared TXOP allocator receives a PPDU in the shared TXOP from the shared TXOP holder 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 finished, if the shared TXOP has not finished, the shared TXOP allocator can start transmitting when it meets any one of the pre-specified conditions.

[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 at a point PIFS later than the end of the shared TXOP.

[0427] Second condition: The shared TXOP allocator's PPDU transmission may end after a point that is SIFS earlier than the end of the shared TXOP. In this case, the shared TXOP allocator can transmit a PPDU after a point that is SIFS later than the end of the PPDU transmitted by the shared TXOP allocator. Specifically, the shared TXOP allocator can transmit a PPDU after SIFS from 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 obtain the TXOP by performing a backoff procedure to obtain the TXOP. At this time, the shared TXOP allocator can transmit a 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) sends a CTS frame to the first station (STA1).

[0431] In the embodiment of FIG. 34(a), when the first station (STA1) transmits the first frame (DL frame 1) in the shared TXOP, a time smaller than PIFS and larger than SIFS remains until the end of the shared TXOP. 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 the second frame (DL frame 2) at a time point that is PIFS later from the end of the shared TXOP. However, the interval between the first frame (DL frame 1) and the second frame (DL frame 2) is larger than 25 us. Therefore, this may be a violation of the existing regulations. Specifically, this may be a violation of the regulation that the interval between frames is not allowed to be larger than 25 us when a station that has acquired a TXOP performs frame exchange in the wireless LAN standard.

[0432] In the embodiment of FIG. 34(b), when the second station (STA1) transmits a frame (UL frame or P2P frame) in the shared TXOP, a time smaller than PIFS and larger than SIFS remains until the end of the shared TXOP. 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 time point that is PIFS later than the end of the shared TXOP. At this time, the interval between the 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 regulation regarding the transmission interval in the TXOP described above.

[0433] In addition, when the first station (STA1) cannot detect all frame exchanges in the shared TXOP and performs CS at the end of the shared TXOP or frame exchange ends at the end of the shared TXOP, the interval between PPDUs is greater than 25 us. This is also the case when PPDU transmission is performed according to the above-mentioned condition 3. That is, the interval between the last PPDU transmitted in 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 regulation on the transmission interval in the TXOP.

[0434] In the embodiment of Fig. 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 including the first frame (DL frame 1).

[0435] TXOP recovery after termination 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 the 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 transmitted PPDU in the shared TXOP, the shared TXOP allocator may transmit a PPDU at a time PIFS later than the end of the last transmitted PPDU in the shared TXOP. This embodiment may be applied only when the shared TXOP holder is not allowed to transmit to a station 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 transmitted PPDU in the shared TXOP is referred to as the last PPDU of the shared TXOP. In addition, the case where the shared TXOP holder is not allowed to transmit to a station other than the shared TXOP allocator in the shared TXOP is referred to as the first TXOP sharing mode. In addition, when the shared TXOP holder is allowed to transmit within the shared TXOP to a station other than the shared TXOP allocator, this 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, and only if the PPDU does not include a frame requesting an immediate response, the shared TXOP allocator may perform TXOP recovery according to the above-mentioned 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) sends a CTS frame to the first station (STA1).

[0440] In the embodiment 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 until the end of the shared TXOP that is less than PIFS and greater than SIFS. At this time, the first station (STA1) performs CS at the end of the first frame (DL frame 1) and determines that the channel is idle at PIFS. Therefore, the first station (STA1) can transmit the second frame (DL frame 2) at a 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 us.

[0441] In the embodiment of FIG. 35(b), when the second station (STA1) transmits a frame (UL frame) in the shared TXOP, a time less than PIFS and greater than SIFS remains until the end of the shared TXOP. At this time, the first station (STA1) performs CS at the end of the PPDU including the frame (UL frame) and determines that the channel is idle at PIFS. Therefore, the first station (STA1) can transmit a frame (DL frame) at a time point that is PIFS later than the end of the PPDU including 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 smaller than PIFS, the shared TXOP holder may not be allowed to start transmission. If the duration of the residual shared TXOP is smaller than PIFS, the shared TXOP allocator may transmit a PPDU at a time point 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 at a time point SIFS later than the end of the PPDU transmitted as the last PPDU of the shared TXOP without performing CS. This is because the duration of the residual shared TXOP is smaller than PIFS, so the shared TXOP allocator can be sure that the shared TXOP holder will not transmit. In such an 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 smaller 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 start transmitting. Specifically, if the duration of the remaining shared TXOP is less than PIFS and greater than SIFS, the shared TXOP holder and the station that allocated the TXOP may not be allowed to start transmitting.

[0444] In addition, the following condition may be added as a condition for the shared TXOP allocator to start transmission after the shared TXOP has ended and if the shared TXOP has not 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 including the frame requesting an immediate response. In this case, the interval between the end of the PPDU including the frame requesting an immediate response and the end of the shared TXOP by the station that has been allocated the TXOP may be less than or equal to a pre-specified value. The pre-specified value may be SIFS. The pre-specified value may 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 termination of a shared TXOP 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 for PIFS 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 that requests 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 at a time SIFS later than the end of the last PPDU of the shared TXOP. In this case, the shared TXOP allocator may transmit a PPDU at a time 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 start transmitting. Specifically, if the duration of the remaining shared TXOP is less than PIFS and greater than SIFS, the shared TXOP holder and the station that allocated the TXOP may not be allowed to start 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 embodiment 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 embodiment of FIG. 36(a), when the second station (STA2) transmits a UL frame in the shared TXOP, a time less than PIFS and greater than SIFS remains until the end of the shared TXOP. At this time, the first station (STA1) performs 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 time point that is 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 us.

[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 FIG. 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 in the shared TXOP. When the channel is idle during the PIFS from the PPDU including the immediate response to the frame requesting the immediate response described above, the station that allocated the TXOP can start transmission at a time PIFS later from the PPDU including the immediate response. In yet another embodiment, the station that allocated the TXOP may begin transmitting a SIFS later than the PPDU containing the immediate response.

[0456] In FIG. 36(b), when the second station (STA2) transmits a 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 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 transmit a DL frame at a point that is PIFS later than the end of the P2P frame. Therefore, the interval between the P2P frame and the DL frame (DL frame 2) is less than 25 us.

[0457] In FIG. 36(C), when a P2P frame is sent to the second station (STA2) within the shared TXOP, there remains a time less than PIFS but greater than SIFS until the end of the shared TXOP. The first station (STA1) performs CS at the end of the P2P frame and determines that the channel is idle at PIFS. Therefore, the first station (STA1) can send a DL frame at a point that is 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 us.

[0458] In the above embodiment, the station that has allocated the TXOP can determine the intended recipient of the received frame based on the recipient address of the received frame, for example, the RA field. Specifically, the station that has allocated the TXOP can determine the station indicated by the recipient address of the receiving station as the intended recipient. The station that has allocated the TXOP can also determine the sender of the received frame based on the sender address of the received frame, for example, the TA field. Specifically, the station that has allocated the TXOP can determine the station indicated by the sender address of the receiving station as the sender. The station that has allocated the TXOP can also determine the intended recipient of the frame included in the received PPDU based on the STA-ID field of the signaling field of the received PPDU. The station that has allocated the TXOP can also determine the intended recipient of the frame included in the received PPDU based on the STA-ID field and the BSS color field of 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, BSS color and UL / DL fields 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 the shared TXOP, the shared TXOP allocator may not be allowed to start frame exchange without performing a backoff procedure to acquire the TXOP, even in a TXOP acquired by the shared TXOP allocator that includes the shared TXOP. A situation may occur in which a station that is allowed to transmit in the shared TXOP cannot transmit. In this case, even if the shared TXOP allocator starts transmitting immediately after the shared TXOP ends, the interval between the PPDU transmitted by the shared TXOP allocator and the PPDU transmitted in 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 frame exchange without performing a backoff procedure to acquire the TXOP. 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 receiver 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 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 25us.

[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 initiate a frame exchange without a backoff procedure to acquire the TXOP, even if the shared TXOP is included in a 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 that occupies the channel at the end of the TXOP may be a frame exchange of 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 the TxPIFS slot boundary.

[0464] The transmission that occupies the channel at the end of the TXOP may not be a frame exchange of the shared TXOP holder. In this case, even if the shared TXOP is included in the TXOP acquired by the shared TXOP allocator after the end of the TXOP, the shared TXOP allocator may not be allowed to start a frame exchange without a back-off procedure to acquire the TXOP. This is because, when the channel is occupied by a transmission that is not a frame exchange of the shared TXOP holder and the shared TXOP allocator transmits according to the existing condition 3, the interval between the last PPDU of the shared TXOP and the PPDU transmitted by the shared TXOP allocator after the shared TXOP may be larger than 25 us. The embodiment that modifies the application condition of the third condition in this way may be applied to the second shared TXOP mode and may not be applied to the first shared TXOP mode.

[0465] In the embodiment described above in relation to TXOP recovery, in relation to the condition for performing the TXOP recovery operation, the time period indicated by "after a time earlier than PIFS from the end of the shared TXOP" may include a time PIFS earlier than the end of the shared TXOP. Also, if the end of the remaining shared TXOP is less than PIFS, it may include the case where the end of the remaining shared TXOP is PIFS. Also, the time period indicated by "before a time earlier than SIFS from the end of the shared TXOP" may include a time SIFS ahead of the end of the shared TXOP. Also, if the end of the remaining shared TXOP is greater than SIFS, it may include the case where the end 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 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 type and subtype of the frame by the Type subfield and the Subtype subfield, respectively. The Frame Control field may indicate whether the frame includes an HT Control field by the +HTC subfield. The Duration / ID field may indicate the duration of the frame. If the frame including the Duration / ID field is not a PS-Poll frame, the Duration / ID field may indicate the duration of the frame. The station may set a network allocation vector (NAV) based on the duration of the frame 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, for example, an AID. The MAC address field may include one or more address fields. The Address field can indicate a MAC address. The Address field can 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.Also, the QoS Control field may 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. Also, the QoS Control field may include the above-mentioned RDG / More PPDU subfield and AC Constraint subfield. For example, the QoS Control field included in the 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 the AC Constraint subfield described above. As described above, the RDG / More PPDU subfield may signal whether the frame includes an RDG or whether there is a PPDU following the frame. Also, the AC Constraint subfield may indicate whether the TID or AC of the response to the RDG (RD data frame) is restricted. The HT Control field may consist of 4 octets, i.e., 32 bits.

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

[0470] The Frame Body field contains the 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 a station receiving a 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 a standard after EHT. In this specification, the embodiment described as being applied to an HE variant may also be applied to a variant defined in a standard after HE. In addition, the HT Contr...

Claims

1. A station of a wireless communication system, comprising: A transceiver unit; and a processor for controlling the transceiver; The processor, Receive a trigger frame from an AP (Access Point), the trigger frame assigning 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; Transmitting a non-trigger based (TB) physical layer protocol data unit (PPDU) within the shared TXOP; The station switches a first enhanced distributed channel access (EDCA) parameter set used for channel access to a second EDCA parameter set based on a transmission of a quality of service (QoS) data frame included in the non-TB PPDU.

2. The processor, 2. The station of claim 1, wherein the station switches from the first EDCA parameter set to the second EDCA parameter set when the quality of service (QoS) data frame is successfully transmitted to the AP within the shared TXOP.

3. The processor, 3. The station of claim 2, wherein the station transmits a QoS data frame requesting an immediate response to the AP via the non-TB PPDU within the shared TXOP, and switches 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.

4. The processor, 3. The station of claim 2, wherein the station switches 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. The station of claim 1 , wherein the second EDCA parameter set is substituted for the first EDCA parameter set based on whether a UL multiuser (MU) transmission is successful.

6. The station of claim 2, further comprising: a station configured to set a timer value for a residual duration applied to the second EDCA parameter set to a value greater than 0 when a QoS data frame is successfully transmitted to the AP.

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

8. The processor, The station of claim 6 , further comprising: setting the timer to a value of 0 when the station successfully transmits signaling to the AP to deactivate the shared TXOP operation.

9. 1. A method of operating a station in a wireless communication system, comprising: receiving a trigger frame for triggering an uplink transmission from an access point (AP), 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; transmitting a non-trigger based (TB) physical layer protocol data unit (PPDU) within the shared TXOP; and A method of operation comprising: switching a first enhanced distributed channel access (EDCA) parameter set used for channel access to a second EDCA parameter set based on a transmission of a quality of service (QoS) data frame included in the non-TB PPDU.

10. The step of switching from a first EDCA parameter set used for channel access to a second EDCA parameter set includes:

10. The method of claim 9, further comprising: switching the first EDCA parameter set to the second EDCA parameter set when the station successfully transmits the quality of service (QoS) data frame to the AP within the shared TXOP.

11. 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, 11. The method of claim 10, further comprising: transmitting a QoS data frame requesting an immediate response to the AP via the non-TB PPDU within the shared TXOP; and switching 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.

12. 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, 11. The method of claim 10, further comprising: switching 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.

13. 10. The method of claim 9, wherein the second EDCA parameter set is substituted for the first EDCA parameter set based on whether a UL multiuser (MU) transmission is successful.

14. The step of switching from a first EDCA parameter set used for channel access to a second EDCA parameter set includes:

11. The method of claim 10, further comprising: setting a value of a timer for a residual duration applied to the second EDCA parameter set to a value greater than 0 if a QoS data frame is successfully transmitted to the AP.

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

16. The method of operation may further include: The method of claim 15, further comprising setting the timer to a value of 0 if the station successfully transmits signaling to the AP to deactivate the shared TXOP operation.

17. The station of claim 1, wherein if a 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 allowed except for one or more predefined transmissions, the one or more predefined transmissions being performed by the AP a short inter-frame space (SIFS) after end of transmission of a last PPDU transmitted by the station within the shared TXOP, and the last PPDU does not require an immediate response.

18. The method of claim 9, wherein if a 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 allowed except for one or more predefined transmissions, the one or more predefined transmissions being performed by the AP a short inter-frame space (SIFS) after end of transmission of a last PPDU transmitted by the station within the shared TXOP, and the last PPDU does not require an immediate response.

Images