Wireless communication apparatus using shared TXOP and operation method for wireless communication apparatus

Abstract

To provide a non-AP station for communicating with an access point (AP).SOLUTION: The non-AP station comprises a transceiving unit and a processor. The processor: receives, from the AP by using the transceiving unit, a first PPDU including a multi user-request to send (MU-RTS) TXOP sharing (TXS) trigger frame; for the MU-RTS TXS trigger frame, allocates, to the non-AP station, a shared TXOP that is a portion of a TXOP acquired by the AP; transmits, to the AP by using the transceiving unit, a second PPDU including a CTS frame in response to the MU-RTS TXS frame; and transmits a third PPDU within the shared TXOP by using the transceiving unit.SELECTED DRAWING: Figure 18

Description

[Technical Field]

[0001] The present invention relates to a wireless communication device and a method of operating a wireless communication device that uses a shared TXOP. [Background technology]

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

[0003] Since IEEE (Institute of Electronics Engineers) 802.11 supported early wireless LAN technology using the 2.4 GHz frequency band, various technology standards have been put into practical use or are currently under development. First, IEEE 802.11b uses the 2.4 GHz band and supports communication speeds of up to 11 Mbps. IEEE 802.11a, which was commercialized after IEEE 802.11b, uses the 5 GHz band instead of the 2.4 GHz band, reducing the impact of interference compared to the significantly more congested 2.4 GHz band, and uses OFDM technology to improve communication speeds to up to 54 Mbps. However, IEEE 802.11a has the disadvantage of a shorter communication distance than IEEE 802.11b. IEEE 802.11g, like IEEE 802.11b, uses the 2.4GHz band and achieves a maximum transmission speed of 54Mbps, and has attracted considerable attention for its backward compatibility, but it also has an advantage over IEEE 802.11a in terms of communication distance.

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

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

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

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

[0008] One embodiment of the present invention aims to provide a wireless communication device and a method of operating the wireless communication device that uses a shared TXOP. [Means for solving the problem]

[0009] According to an embodiment of the present invention, a non-AP station for communicating with an access point (AP) includes a transceiver unit and a processor, wherein the processor receives, via the transceiver unit, a first PPDU including a multi-user-request-to-send (MU-RTS) TXS (TXOP sharing) trigger frame from the AP, the MU-RTS TXS trigger frame assigns a shared TXOP, which is a portion of a TXOP acquired by the AP, to the non-AP station, transmits, via the transceiver unit, a second PPDU including a CTS frame to the AP in response to the MU-RTS TXS frame, and transmits, via the transceiver unit, a third PPDU within the shared TXOP.

[0010] The processor may transmit a third PPDU in a bandwidth that is the same as or narrower than the bandwidth of the second PPDU.

[0011] The CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU may be set to a value equal to or smaller than the CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the second PPDU.

[0012] The processor may transmit the third PPDU based on the subchannel last designated as disabled by the AP.

[0013] The processor may set to 1 a bit of INACTIVE_SUBCHANNELS in TXVECTOR of the third PPDU that corresponds to a subchannel that the AP last designated as disabled.

[0014] The processor can set a parameter related to a frequency band of the third PPDU based on whether a non-HT PPDU exchange has occurred before transmitting the third PPDU in the shared TXOP.

[0015] The frequency band-related parameters may include CH_BANDWIDTH of TXVECTOR. In this case, if non-HT PPDU exchange is performed in the shared TXOP before the transmission of the third PPDU, the processor may set the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU to a bandwidth equal to or narrower than CH_BANDWIDTH_IN_NON_HT of the RXVECTOR of the non-HT PPDU received before the transmission of the third PPDU. In addition, if non-HT PPDU exchange is not performed in the shared TXOP before the transmission of the third PPDU, the processor may set the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU to a bandwidth equal to or narrower than CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the second PPDU.

[0016] In the shared TXOP, the non-HT PPDU exchange before the transmission of the third PPDU may be an exchange of a non-HT PPDU including an RTS frame and a non-HT PPDU including a CTS frame.

[0017] The third PPDU may be a P2P PPDU transmitted to a P2P peer station of the non-AP station.

[0018] The value of the Duration field of the MU-RTS TXS frame may be set based on the transmission time of the second PPDU.

[0019] The third PPDU may be a P2P PPDU transmitted to a P2P peer station of the non-AP station.

[0020] Before transmitting the third PPDU, the processor may send an RTS frame to the P2P peer station, the RTS frame having the MAC address of the AP as a sender address.

[0021] According to an embodiment of the present invention, a method for operating a non-AP station to communicate with an AP (access point) includes the steps of receiving a first PPDU including a MU-RTS (multi user-request to send) TXS (TXOP sharing) trigger frame from the AP, and the MU-RTS TXS trigger frame assigns a shared TXOP, which is a portion of the TXOPs acquired by the AP, to the non-AP station; transmitting a second PPDU including a CTS frame to the AP in response to the MU-RTS TXS frame; and transmitting a third PPDU within the shared TXOP.

[0022] Transmitting the third PPDU within the shared TXOP may include transmitting the third PPDU in a bandwidth that is the same as or narrower than the bandwidth of the second PPDU.

[0023] The step of transmitting the third PPDU at a bandwidth equal to or narrower than the bandwidth of the second PPDU may include the step of setting the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU to a value equal to or narrower than the CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the second PPDU.

[0024] Transmitting a third PPDU within the shared TXOP may include transmitting the third PPDU based on a subchannel last designated as disabled by the AP.

[0025] The step of transmitting the third PPDU based on the subchannel last designated as disabled by the AP may include the step of setting to 1 a bit of INACTIVE_SUBCHANNELS of TXVECTOR of the third PPDU corresponding to the subchannel last designated as disabled by the AP.

[0026] The step of transmitting a third PPDU within the shared TXOP may include setting parameters related to the frequency band of the third PPDU based on whether a non-HT PPDU exchange has occurred in the shared TXOP prior to the transmission of the third PPDU.

[0027] The frequency band related parameters may include CH_BANDWIDTH of TXVECTOR. In this case, the step of setting parameters related to the frequency band of the third PPDU based on whether non-HT PPDU exchange has occurred in the shared TXOP before the transmission of the third PPDU may include the steps of: setting the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU to a bandwidth equal to or narrower than the CH_BANDWIDTH_IN_NON_HT of the RXVECTOR of the non-HT PPDU received before the transmission of the third PPDU, if non-HT PPDU exchange has occurred in the shared TXOP before the transmission of the third PPDU; and setting the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU to a bandwidth equal to or narrower than the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the second PPDU, if non-HT PPDU exchange has not occurred in the shared TXOP before the transmission of the third PPDU.

[0028] In the shared TXOP, the non-HT PPDU exchange before the transmission of the third PPDU may be an exchange of a non-HT PPDU including an RTS frame and a non-HT PPDU including a CTS frame.

[0029] The third PPDU may be a P2P PPDU transmitted to a P2P peer station of the non-AP station. [Effects of the Invention]

[0030] One embodiment of the present invention provides a wireless communication device and a method of operating a wireless communication device that uses a shared TXOP. [Brief explanation of the drawings]

[0031] [Figure 1] 1 is a diagram showing a wireless LAN system according to an embodiment of the present invention. [Figure 2]FIG. 10 is a diagram showing a wireless LAN system according to another embodiment of the present invention. [Figure 3] FIG. 2 is a diagram showing the configuration of a station according to an embodiment of the present invention. [Figure 4] FIG. 2 is a diagram illustrating a configuration of an access point according to an embodiment of the present invention. [Figure 5] 1 is a diagram illustrating a process in which a STA establishes a link with an AP. [Figure 6] FIG. 1 is a diagram illustrating a CSMA (Carrier Sense Multiple Access) / CA (Collision Avoidance) method used in wireless LAN communication. [Figure 7] 1 shows examples of various standard generation PPDU (PLCP Protocol Data Unit) formats. [Figure 8] 1 illustrates 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] This shows a TXOP protection method using RTS and CTS frame exchange. [Figure 10] This shows a TXOP protection method using MU-RTS and CTS frames. [Figure 11] 1 shows a format of a trigger frame according to an embodiment of the present invention. [Figure 12] 10 shows the format of a Common Info field of a trigger frame according to an embodiment of the present invention. [Figure 13] 10 shows the format of a User Info field of a trigger frame according to an embodiment of the present invention. [Figure 14] 10 illustrates a method for determining a subchannel for transmitting a CTS frame by a station according to an embodiment of the present invention. [Figure 15] 1 shows the format of an MU-RTS TXS frame according to an embodiment of the present invention. [Figure 16]1 illustrates an embodiment of the present invention in which an AP transmits an MU-RTS TXS frame to allocate a shared TXOP to a non-AP station. [Figure 17] 1 illustrates an embodiment of the present invention in which an AP transmits an MU-RTS TXS frame to allocate a shared TXOP to a non-AP station. [Figure 18] 10 illustrates how an AP, which is a TXOP holder, sets the parameters of the TXVECTOR of the PPDU that the AP will transmit after the shared TXOP is terminated, according to an embodiment of the present invention. [Figure 19] 10 illustrates how an AP, which is a TXOP holder, sets the parameters of the TXVECTOR of the PPDU that the AP will transmit after the shared TXOP is terminated, according to an embodiment of the present invention. [Figure 20] 10 illustrates a method for setting the TXVECTOR of a PPDU when the intended recipient of the PPDU in which a shared TXOP is transmitted is changed, according to an embodiment of the present invention. [Figure 21] 10 illustrates an embodiment of the present invention in which an AP sets the value of the Duration field of an MU-RTS TXS frame until it receives a CTS frame for the MU-RTS TXS frame. [Figure 22] 10 illustrates an embodiment of the present invention in which an AP sets the value of the Duration field of an MU-RTS TXS frame based on the start frame. [Figure 23] 10 illustrates that, according to one embodiment of the present invention, a station to which a shared TXOP has been allocated sends an RTS frame with the sender address set as the AP that established the shared TXOP. DETAILED DESCRIPTION OF THE INVENTION

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

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

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

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

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

[0037] As shown in FIG. 1, infrastructure BSSs BSS1 and BSS2 include one or more stations STA1, STA2, STA3, STA4, and STA5, access points AP-1 and AP-2 that are stations providing distribution services, and a distribution system DS that connects multiple access points AP-1 and AP-2.

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

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

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

[0041] 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.

[0042] BSS3 shown in Figure 2 is an independent BSS and does not include an AP, so none of the stations (STA6, STA7) are connected to an AP. An independent BSS is not allowed to connect to a distribution system and forms a self-contained network. In an independent BSS, each station (STA6, STA7) is directly connected to each other.

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

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

[0045] Next, the user interface 140 includes various types of input / output means provided in the station 100. That is, the user interface unit 140 receives user input using various input means, and the processor 110 controls the station 100 based on the received user input. Also, the user interface unit 140 performs output based on instructions from the processor 110 using various output means.

[0046] Next, 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 processed by the processor 110 or the control commands of the processor 110. The memory 160 also stores control programs and various data used by the station 100. The control programs include a connection program required for the station 100 to connect to an AP or an external station.

[0047] The processor 110 of the present invention executes various commands or programs to process data within the station 100. The processor 110 also controls each unit of the station 100 and controls the transmission and reception of data between the units. According to an embodiment of the present invention, the processor 110 executes a program for connection with an AP stored in the memory 160 and receives a communication setup message transmitted by the AP. The processor 110 also reads information about the station 100's preferences contained in the communication setup message and requests connection to the AP based on the information about the station 100's preferences. The processor 110 of the present invention may refer to a main control unit of the station 100, or, depending on the embodiment, may refer to a control unit for individually controlling some components of the station 100, such as the communication unit 120. That is, the processor 110 may be a modem that modulates and demodulates wireless signals transmitted and received by the communication unit 120, or a modulator and / or demodulator. The processor 110 controls various operations for transmitting and receiving wireless signals in the station 100 according to an embodiment of the present invention. A detailed embodiment of this will be described later.

[0048] The station 100 shown in FIG. 3 is a block diagram according to an embodiment of the present invention, and the separate blocks indicate the logically separated elements of the device. Therefore, the above-described device elements may be mounted on a single chip or multiple chips depending on the device design. For example, the processor 110 and the communication unit 120 may be integrated into a single chip or may be mounted on separate chips. Furthermore, in embodiments of the present invention, some components of the station 100, such as the user interface unit 140 and the display unit 150, may be selectively provided in the station 100.

[0049] 4 is a block diagram showing the configuration of an AP 200 according to an embodiment of the present invention. As shown, the AP 200 according to the embodiment of the present invention includes a processor 210, a communication unit 220, and a memory 260. In FIG. 4, duplicated descriptions of parts of the configuration of the AP 200 that are the same as or correspond to the configuration of the station 100 in FIG. 3 will be omitted.

[0050] Referring to FIG. 4, the AP 200 according to the present invention includes a communication unit 220 for operating a BSS in at least one frequency band. As described above in the embodiment of FIG. 3, the communication unit 220 of the AP 200 may also include multiple communication modules using different frequency bands. That is, the AP 200 according to the embodiment of the present invention may include two or more communication modules using different frequency bands, for example, 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz. Preferably, the AP 200 may include a communication module using a frequency band above 7.125 GHz and a communication module using a frequency band below 7.125 GHz. Each communication module 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 multiple communication modules simultaneously, depending on the performance and requirements of the AP 200. In the embodiment of the present invention, the communication unit 220 may represent an RF (Radio Frequency) communication module that processes RF signals.

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

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

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

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

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

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

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

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

[0059] If a specific terminal successfully accesses the channel, it transmits data over the channel. However, if the terminal attempting access collides with another terminal, the colliding terminals are assigned new random numbers and perform a backoff procedure again. According to one embodiment, the new random numbers assigned to each terminal are determined within a range (2*CW) twice the range of the random numbers previously assigned to the terminal (contention window, CW). Meanwhile, each terminal attempts access by performing a backoff procedure again in the next contention window period. At this time, each terminal performs the backoff procedure from the slot time remaining in the previous contention window period. In this way, terminals communicating over a wireless LAN can avoid collisions with each other on a specific channel.

[0060] <Examples of various PPDU formats>

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

[0062] 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.

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

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

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

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

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

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

[0069]

number

[0070] At this time,

number

[0071]

number

[0072] 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.

[0073]

number

[0074] 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.

[0075] Referring to Figure 7(e), the U-SIG (Universal SIG) field remains in the EHT PPDU and subsequent generation WLAN PPDUs, and serves to distinguish which generation of PPDU it is, including 11be. The U-SIG is two 64FFT-based OFDM symbols and can transmit a total of 52 bits of information. Of these, 43 bits excluding 9 bits of CRC / tail are roughly divided into a VI (Version Independent) field and a VD (Version Dependent) field.

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

[0077] The VD field, which is signaling information useful only for 11be version PPDUs, may consist of fields commonly used in any PPDU format, such as the PPDU format and BW, as well as fields defined differently for each PPDU format. The PPDU format is a separator that distinguishes between EHT SU (Single User), EHT MU (Multiple User), EHT TB (Trigger-based), and EHT ER (Extended Range) PPDUs. The BW field broadly signals five basic PPDU BW options: 20, 40, 80, 160 (80 + 80), and 320 (160 + 160) MHz (BWs that can be expressed in the form of a power of 20 * 2 can be called basic BWs), as well as various remaining PPDU BWs formed by preamble puncturing. After signaling at 320 MHz, a portion of 80 MHz may be punctured. In addition, the punctured and modified channel shape may be signaled directly in the BW field, or may be signaled using both the BW field and a field that appears after the BW field (for example, a field in the EHT-SIG field). If the BW field is 3 bits, a total of 8 BW signalings are possible, so a maximum of 3 puncturing modes can be signaled. If the BW field is 4 bits, a total of 16 BW signalings are possible, so a maximum of 11 puncturing modes can be signaled.

[0078] The fields located after the BW field vary depending on the type and format of the PPDU. MU PPDUs and SU PPDUs may be signaled using the same PPDU format, and a field for distinguishing between MU PPDUs and SU PPDUs may be located before the EHT-SIG field, requiring additional signaling. Both SU PPDUs and MU PPDUs include an EHT-SIG field, but some fields not required for the SU PPDU may be compressed. In this case, the information of the compressed fields may be omitted or may have a reduced size compared to the size of the original fields included in the MU PPDU. For example, the SU PPDU may have a different configuration, such as the common fields of the EHT-SIG being omitted or replaced, or the user-specific fields being replaced or reduced to one.

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

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

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

[0082] The type of signaled discontinuous channel is limited, and indicates the BW and discontinuous channel information of the SU PPDU in combination with the value of the BW field. For example, since the SU PPDU is a PPDU transmitted only to a single UE, the STA can recognize its allocated bandwidth from the BW field included in the PPDU and can recognize punctured resources within the allocated bandwidth from the puncturing mode field of the U-SIG field or EHT-SIG field included in the PPDU. In this case, the UE can receive the PPDU in the remaining resource units other than the specific channel of the punctured resource units. In this case, multiple RUs allocated to the STA may be configured with different frequency bands or tones.

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

[0084] This 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 primary 160 MHz and secondary 160 MHz puncturing types in the 320 MHz BW configuration of the SU PPDU.

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

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

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

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

[0089] 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.

[0090] 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.

[0091] 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.

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

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

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

[0095] For example, among a plurality of divided resource units, a user field corresponding to at least one resource unit used for data transmission may include the AID of the recipient or the sender, and a user field corresponding to the remaining resource units not used for data transmission may include a previously set Null STA ID.

[0096] For the sake of convenience of explanation, in this specification, a frame or a MAC frame may be used in the same sense as an MPDU.

[0097] <Wi-Fi Terminal Channel Access Method>

[0098] Wi-Fi terminals (AP and non-AP stations) perform channel sensing to determine whether the channel is idle before transmitting a frame. Wi-Fi terminals communicate in an unlicensed band that is shared with other devices. Such channel access operations were described in FIG. 6. Such channel access operations are applicable to DCF (distributed coordination) and EDCAF (enhanced distributed channel access) defined in the IEEE 802.11 standard.

[0099] In DCF and EDCAF channel access, a station performs virtual carrier sensing in addition to physical carrier sensing (CS) to determine the channel state. If either physical carrier sensing or virtual carrier sensing detects that the channel is busy, the station determines that the channel is busy. In virtual channel sensing, a station determines that the channel is busy if the value of the channel's network allocation vector (NAV) is not 0. The NAV may be a value maintained for future traffic that is expected to occupy the wireless medium. Specifically, the NAV is maintained by each station, and the NAV may be a time interval during which each station does not start transmission on the wireless medium, regardless of whether the wireless medium is idle or not. The NAV value decreases over time. If the NAV value is 0, the station determines that the channel is idle in virtual channel sensing. The NAV may be set by an RTS frame / CTS frame exchange. Specifically, the duration may be set based on the value of the Duration field of the RTS frame and the value of the Duration field of the CTS frame in the RTS / CTS frame exchange. Also, the duration may be set based on the value of the Duration field of other MAC frames other than the RTS / CTS frame exchange.

[0100] <EDCAとTXOP>

[0101] EDCA manages traffic by classifying it into four types of access categories (ACs) according to traffic characteristics. The four types of ACs are AC_VO (AC Voice), AC_VI (AC Video), AC_BE (AC Best Effort), and AC_BK (AC Background). Channel access parameters may be set for each AC. Specifically, the four ACs may have different channel access parameters. The channel access parameters may include any one of parameters related to CW, TXOP, and AIFSN used in backoff operation. This may manage traffic channel access priority for each AC. In EDCA, traffic (MSDU) may be mapped to one of four ACs according to the traffic category (TC) or traffic stream (TS) of the traffic. In EDCA, each of the four ACs is mapped to four queues, and the traffic is managed in the queue corresponding to the AC of the traffic. In this case, the four queues may be physically separated or logically separated even if not physically separated.

[0102] The AC_VO may be an AC for traffic that is not large in absolute volume but is sensitive to transmission delays, such as voice traffic. The AC_VO may have relatively small CW-related parameters and AIFSN parameter values ​​to increase the probability of being served preferentially over traffic of other ACs. However, the TXOP parameter of the AC_VO is limited to a relatively small value compared to the TXOP parameter of the AC, and the AC_VO may be guaranteed a shorter transmission time than other ACs.

[0103] AC_VI may be an AC for traffic such as video traffic that is more tolerant of transmission delays than voice traffic but requires low-delay transmission and must handle a large amount of traffic. AC_VI may have larger CW-related parameters and AIFSN parameter values ​​than AC_VO but smaller than other ACs. The TXOP parameter of AC_VI is approximately twice as long as AC_VI.

[0104] AC_BE is an AC for traffic robust to transmission delays, and most general traffic other than voice data and streaming video data may be classified as AC_BE. The CW-related parameters and AIFSN parameters of AC_BE may be greater than the values ​​of the AC_VO and AC_VICW-related parameters and AIFSN parameters. In addition, AC_BE does not have a separate TXOP parameter, and therefore cannot perform a TXOP transmission sequence in which a station transmits a PPDU including traffic corresponding to AC_BE, receives an ACK, and then transmits another PPDU including traffic corresponding to AC_BE after SIFS.

[0105] AC_BK is an AC for traffic that is robust to transmission delays similar to AC_BE, but has a lower priority than traffic corresponding to AC_BE. AC_BK uses the same CW parameter value as AC_BE, but uses a larger AIFSN parameter value than AC_BE. In addition, a station cannot perform a TXOP transmission sequence in which it receives an ACK after transmitting a PPDU containing traffic corresponding to AC_BK, and then transmits another PPDU containing traffic corresponding to AC_BK after SIFS.

[0106] The four types of EDCA ACs are mapped to 802.1D UP (user priority), and the EDCA AC is determined by the UP value of the traffic received via wire or the TID of the MSDU indicated by the upper layer. In this case, if the TID of the MSDU indicates a value from 0 to 7, the value indicated by the TID can correspond one-to-one with the UP.

[0107] In addition, the four types of EDCA ACs have their respective default CW-related parameters (CWmin, CWmax), AIFSN, and TXOP parameters defined in IEEE 802.11ax, and the parameter values ​​of each AC may be changed by the AP. Therefore, the default CW-related parameters (CWmin, CWmax), AIFSN, and TXOP parameters of different BSSs may be different from each other.

[0108] Using the EDCA mechanism, Wi-Fi traffic is stored in one of four queues corresponding to four ACs, and may be transmitted to a target device if the AC of the traffic wins channel access contention with other ACs. In this case, in channel access contention between ACs, each AC competes for channel access based on its channel access parameters (CW[AC], AIFSN[AC]). The channel access contention operation performed by each AC is the same as that of DCF. In this case, an AC whose traffic is not stored in Q does not participate in channel access contention. Since each AC has different CW-related parameter and AIFSN parameter values, AC_VO, which has the smallest CW-related parameter and AIFSN parameter, is more likely to win channel access contention with other ACs. Therefore, traffic of AC_VO is more likely to be served preferentially than traffic of other ACs.

[0109] As described above, EDCA sets channel access priority for traffic (frames, packets, etc.) according to the AC to enhance QoS, and provides the EDCA TXOP (EDCA Transmission Opportunity) function. The EDCA TXOP is a time period during which the EDCA Function (EDCAF) of an AC can adjust the wireless medium without being disturbed by other devices when it becomes a TXOP holder after acquiring a channel access opportunity. The EDCA TXOP may be limited by a TXOP limit advertised by the AP, and the TXOP holder must transmit so that the TXOP holder's transmission and the transmission of the response frame transmitted by the TXOP holder's transmission can be completed within the TXOP limit.

[0110] A TXOP holder can transmit multiple frames (multiple PPDUs) during an EDCA TXOP period. Within the TXOP period, the TXOP holder can transmit multiple frames consecutively without performing a separate channel access procedure (e.g., a backoff procedure) between each frame transmission. If the multiple frames are MPDUs or A-MPDUs (Aggregated MAC protocol data units) that do not require immediate ACK, the transmission of the multiple frames may be performed at short interframe space (SIFS) or reduced interframe space (RIFS) intervals. If the multiple frames include an MPDU or A-MPDU that requires immediate ACK, the TXOP holder can receive an ACK after transmitting the frame that requires immediate ACK and transmit the next frame after an SIFS.

[0111] In this case, if the pre-specified conditions are met, the TXOP holder can transmit traffic of other ACs in addition to the AC used to acquire the TXOP. Specifically, TXOP sharing allows the TXOP holder to transmit traffic of other ACs in addition to the AC used to acquire the TXOP.

[0112] As described above, a TXOP holder can transmit frames continuously within a TXOP without performing a separate channel access procedure. To do this, it is necessary to prevent other terminals from accessing the channel within the TXOP. Therefore, the TXOP holder can publicly announce the acquired TXOP period.

[0113] A station that is a TXOP holder or that starts transmission after completing the channel access procedure can send an RTS frame to inform other stations of the TXOP period. In this case, the RTS frame has the Type subfield of the Frame Control field of the MAC frame header (the third (B2) and fourth (B3) bits of the Frame Control field) set to 01. 2b and the Subtype subfield of the Frame Control field (the fifth to eighth bits (B4 to B7) of the Frame Control field) is set to 1011. 2bA UE that receives an RTS frame from a TXOP holder can set its NAV based on duration-related information included in the RTS frame, such as the value of the Duration field. The set NAV may be maintained at a non-zero value for the time corresponding to the TXOP of the TXOP holder. A station designated as the destination device of an RTS frame must respond with a CTS frame to the RTS frame instead of setting its NAV based on the duration information of the RTS frame. In this case, the destination device of the RTS frame sent to initiate a TXOP is the TXOP responder and must send a CTS frame in response to the RTS frame. In this case, the interval between the RTS frame and the CTS frame is SIFS. In this case, the Duration field of the CTS frame is set to a value calculated by subtracting the value indicated in the Duration field of the received RTS frame from the CTS frame's transmission time. A UE that receives a CTS frame can set its NAV based on duration-related information included in the CTS frame. The NAV of the terminal that received the RTS frame from the TXOP holder and the terminal that received the CTS frame from the TXOP responder is set to 0 after the TXOP acquired by the TXOP holder is terminated. This allows the Wi-Fi MAC mechanism to allow the TXOP holder and the TXOP responder to exchange multiple frames without interference in the TXOP.

[0114] However, if a TXOP holder transmits an RTS frame using a non-HT duplicate PPDU in the primary 80 MHz band, but the CTS frame (non-HT duplicate PPDU) received from the TXOP responder is only received in the primary 40 MHz band, the TXOP holder can use only the primary 40 MHz or a bandwidth less than the primary 40 MHz (i.e., primary 20 MHz) for frame exchange in the acquired TXOP. That is, the TXOP holder must set the CH_BANDWIDTH (a type of TXVECTOR parameter) of the PPDU to be transmitted to a value equal to or smaller than the CH_BANDWIDTH or CH_BANDWIDTH_IN-NON_HT (a type of RXVECTOR parameter) of the PPDU containing the received CTS frame. In this case, the RTS frame may be an RTS frame that allows a CTS frame to be responded to in a BW smaller than the BW in which the RTS frame was transmitted. That is, the RTS frame may be an RTS frame transmitted with DYN_BANDWIDTH_IN_NON_HT of TXVECTOR set to Dynamic. If DYN_BANDWIDTH_IN_NON_HT is set to Static and the RTS frame is transmitted from the TXOP holder, the TXOP responder may have to transmit a CTS frame in the frequency band (BW) in which the RTS frame was received.

[0115] FIG. 9 shows a TXOP protection method using RTS and CTS frame exchange.

[0116] In FIG. 9, before transmitting a PPDU, the first station (STA1) transmits an RTS frame to the second station (STA2), which is the destination device of the PPDU. The second station (STA2) determines that the received RTS frame is an RTS frame addressed to itself as the destination device, and responds to the first station (STA1) with a CTS frame after a SIFS.

[0117] The first neighbor station (STA1_Neighbor), which is a neighbor station of the first station (STA1), sets the value of the Duration field of the RTS frame as NAV after receiving the RTS frame transmitted by the first station (STA1). The second neighbor station (STA2_Neighbor), which is a neighbor station of the second station (STA2), sets the NAV based on the value of the Duration field of the CTS frame after receiving the CTS frame transmitted by the second station (STA2). After receiving the RTS frame or the CTS frame, the first neighbor station (STA1_Neighbor) and the second neighbor station (STA2_Neighbor) determine that the channel is busy in virtual carrier sensing and perform operations such as not decreasing the backoff counter while the set NAV is maintained at a non-zero value. As a result, since the neighboring terminals that have received the RTS frame or the CTS frame do not attempt transmission during the period when the NAV is maintained at a non-zero value, the first station (STA1) and the second station (STA2) can communicate the PPDU and the ACK frame without being interfered by the neighboring terminals.

[0118] Even if the first station (STA1) and the second neighbor station (STA2_Neighbor) are hidden nodes, the second neighbor station (STA2_Neighbor) can perform operations considering that the channel is in use while the first station (STA1) transmits the PPDU.

[0119] <TXOP Protection Using MU-RTS Trigger Frame>

[0120] 11ax (6th generation Wi-Fi, Wi-Fi 6, HEW, High Efficiency WLAN) defines the MU-RTS trigger frame (hereinafter referred to as the MU-RTS frame) and CTS frame exchange procedure. The MU-RTS frame allows an AP to initiate a TXOP and protect the TXOP frame exchange procedure. The MU-RTS frame is a type of trigger frame. When a station receives an MU-RTS frame and the User field of the MU-RTS frame indicates the station's AID12 (the 12 least significant bits of the association ID), the station transmits a CTS frame in response to the MU-RTS frame. Multiple stations can simultaneously transmit CTS frames. When an AP uses the MU-RTS frame for TXOP protection, multiple stations can respond with CTS frames, thereby protecting the TXOP from neighboring stations of multiple stations that are the destination devices of a Downlink Multi-User PPDU (DL MU PPDU). The MU-RTS frame can also be used to protect an Uplink Multi-User PPDU (UL MU PPDU). Specifically, before using a trigger frame to request a TB (Trigger-based) PPDU from multiple stations, the AP transmits an MU-RTS frame and allows multiple stations that respond with a TB PPDU to transmit a CTS frame. At this time, the CTS frames responded by multiple stations set NAVs to neighboring stations of each station to protect the TB PPDU and ACK frames (e.g., Ack, Block Ack) transmitted after the TB PPDU. As a result, legacy stations that cannot decode the trigger frame and TB PPDU do not need to access the channel in the frame exchange sequence initiated by the trigger frame (or the TXOP in which the trigger frame is transmitted).

[0121] FIG. 10 shows a TXOP protection method using MU-RTS and CTS frames.

[0122] In Figure 10, before transmitting the MU PPDU, the AP transmits an MU-RTS frame to the first station (STA1) and the second station (STA2), which are the destination devices of the MU PPDU. The first station (STA1) and the second station (STA2) receive the MU-RTS frame and, after a SIFS, each transmit a CTS frame in response to the MU-RTS frame.

[0123] After receiving the CTS frame transmitted by the first station (STA1), the first neighbor station (STA1_Neighbor) sets its NAV based on the value of the Duration field in the CTS frame. After receiving the CTS frame transmitted by the second station (STA2), the second neighbor station (STA2_Neighbor) sets its NAV based on the value of the Duration field in the CTS frame. After receiving the CTS frame, the first neighbor station (STA1_Neighbor) and the second neighbor station (STA2_Neighbor) determine that the channel is in use through virtual carrier sensing and do not decrement the backoff counter while their set NAV remains non-zero. Therefore, because the stations that receive the CTS frame do not attempt transmission while their NAV remains non-zero, the AP transmits an MU PPDU and the first and second stations (STA1_Neighbor) respond with ACK frames without being interrupted by neighbor stations.

[0124] The trigger frame is a frame type defined in IEEE 802.11ax, and the Type subfield and Subtype subfield of the Frame Control field are set to 01. 2b and 0010 2b The value of the Type subfield of the Frame Control field is 01. 2bindicates that it is a Control Type, and the value of the Subtype subfield is 0010 2b indicates a trigger frame. IEEE 802.11ax defines a trigger frame for an AP to simultaneously request response frames from multiple stations. The MU-RTS frame is used by an AP to request a CTS frame from multiple STAs (non-AP STAs). Trigger types other than the MU-RTS frame include the Basic Tigger frame for requesting a UL MU PPDU, the Beamforming Report Poll Tigger frame for requesting a beamforming report, the MU-BAR trigger frame for requesting a BlockAck, the Buffer Status Report Poll Tigger frame for requesting a buffer status report, the GCR MU-BAR trigger frame, the Bandwidth Query Report Poll trigger frame, and the NDP Feedback Report Poll trigger frame. The trigger frame formats are described using Figures 11 to 13.

[0125] FIG. 11 shows a format of a trigger frame according to an embodiment of the present invention.

[0126] The trigger frame includes a MAC header including a Frame Control field, a Common Info field, a User Info List field, a Padding field, and an FCS field.

[0127] The Frame Control field includes Type and Subtype subfields, and the trigger frame has two subfields with 01 and 02. 2b and 0010 2b is set to

[0128] The Common Info field includes a Trigger Type subfield for indicating the type of the trigger frame, a UL Length subfield for indicating the length of the UL transmission to be responded to, and multiple other fields. The specific format of the Common Info field will be described with reference to FIG. 12.

[0129] The User Info List field may include zero or more User Info fields containing information for indicating the destination device of the trigger frame. In this case, the User Info field includes, in addition to the information for indicating the destination device, parameters to be used when the destination device transmits a response frame after receiving the trigger frame, such as UL DCM, UL MCS, etc., depending on the type of the trigger frame. The specific format of the User Info field will be described with reference to FIG. 13.

[0130] The Padding field is set to allow time for the destination device of the trigger frame to prepare a response frame after the station receives the trigger frame. The AP transmitting the trigger frame can adjust the length of the Padding field taking into account the performance of the destination device. In addition, in IEEE 802.11be (Wi-Fi 7, EHT), the end time of the PPDU containing the trigger frame may be adjusted to align with other PPDUs.

[0131] The FCS (Frame Check Sequence) field contains a 32-bit CRC (Cyclic Redundancy Code), which is a value obtained based on the MAC Header value and the Frame Body field value.

[0132] FIG. 12 shows the format of the Common Info field of the trigger frame according to an embodiment of the present invention.

[0133] The Trigger Type subfield is used to indicate the type of trigger frame, and if the value of the Trigger Type subfield is 0, it indicates a basic trigger frame. If the value of the Trigger Type subfield is 1, it indicates a BFRP frame. If the value of the Trigger Type subfield is 2, it indicates an MU-BAR frame. If the value of the Trigger Type subfield is 3, it indicates an MU-RTS frame. If the value of the Trigger Type subfield is 4, it indicates a BSRP frame. If the value of the Trigger Type subfield is 5, it indicates a GCR MU-BAR. If the value of the Trigger Type subfield is 6, it indicates a BQRP frame. If the value of the Trigger Type subfield is 7, it indicates an NFRP (NDP Feedback Report Poll).

[0134] The UL Length subfield indicates the value to be set in the L-SIG LENGTH field of the TB PPDU, which is a response to the trigger frame.

[0135] The More TF subfield indicates whether there are any trigger frames to be transmitted after the trigger frame.

[0136] The CS Required subfield indicates whether the destination device of the trigger frame should perform CS when transmitting a response frame (Physical & Virtual CS, ED & NAV). A station that transmits a response frame after receiving a trigger frame with the CS Required subfield set to 1 must perform CS.

[0137] The UL BW subfield indicates the BW value that a station responding with a TB PPDU after receiving a trigger frame should indicate in the preamble, for example, in the HE-SIG-A field or U-SIG field.

[0138] The GI and HE / EHT-LTF Type subfield indicates the GI (Guard interval) and HE (EHT)-LTF values ​​of the TB PPDU, which is a response to the trigger frame.

[0139] The MU-MIMO HE (EHT)-LTF Mode subfield indicates information related to the HE (EHT)-LTF mode to be applied to the TB PPDU, which is a response to the trigger frame.

[0140] The Number Of HE(EHT)-LTF Symbols And Midamble Periodicity subfield indicates the number of HE(EHT)-LTF symbols to be applied to the TB PPDU when the Doppler subfield is indicated as 0, and indicates information related to the number of HE(EHT)-LTF symbols and the midamble periodicity when the Doppler subfield is indicated as 1.

[0141] The UL STBC subfield indicates whether STBC encoding should be applied to the acknowledged TB PPDU, and is set to 1 if STBC encoding should be applied. However, the UL STBC subfield of the trigger frame that acknowledges the EHT TB PPDU is a reserved field.

[0142] The LDPC Extra Symbol Segment subfield indicates whether an LDPC extra symbol segment should be indicated in the TB PPDU, which is a response to the trigger frame. If the LDPC Extra Symbol Segment subfield indicates 1, the LDPC extra symbol segment must be included in the TB PPDU.

[0143] The AP Tx Power subfield indicates a value related to the AP transmit power used when the station transmits the trigger frame. When the station transmits a response frame, the station can adjust its transmit power based on the value indicated in the AP Tx Power subfield.

[0144] The Pre-FEC Padding Factor and PE Disambiguity subfields indicate whether the Pre-FEC Padding Factor is 1, 2, 3, or 4, and information for clarifying the length of the PE (Packet Extension).

[0145] The UL Spatial Reuse subfield includes four Spatial Reuse subfields and indicates the value set in the Spatial Reuse field of the HE-SIG-A of the HE TB PPDU, which is a response to the trigger frame.

[0146] The Doppler subfield indicates whether a midamble is included in the TB PPDU, which is a response to the trigger frame. The trigger frame that triggers the transmission of the EHT TB PPDU may have the Doppler subfield set as a reserved field. When the subfield is set as a reserved field, the station can operate without considering the value of the field.

[0147] The HE / EHT P160 subfield indicates whether the TB PPDU, which is a response to the trigger frame, will trigger the transmission of an HE TB PPDU or an EHT TB PPDU on a channel corresponding to P160 MHz.

[0148] The Special User Info Field Present subfield indicates whether or not the User Info field includes a User Info field whose AID12 subfield is set to 2007.

[0149] The Trigger Dependent Common Info subfield is included only if the type of trigger frame indicated in the Trigger Type field is a basic trigger frame or an NFRP trigger frame.

[0150] FIG. 13 shows the format of the User Info field of a trigger frame according to an embodiment of the present invention.

[0151] The AID12 subfield of the User Info field indicates the AID12 of the station corresponding to the User Info field. If the User Info field is for any one station, the AID12 subfield may be set to 1 to 2006. If the trigger frame is an HE trigger frame and the User Info field is for any one station, the AID12 subfield may be set to 1 to 2007. If the User Info field is for random access of a station associated with an AP, the value of the AID12 subfield may be set to 0. If the User Info field is for random access of a station unassociated with an AP, the value of the AID12 subfield may be set to 2045 or 2044. A value of 2045 in the AID12 subfield indicates that an HE TB PPDU should be transmitted by random access. A value of 2044 in the AID12 subfield indicates that an EHT TB PPDU should be transmitted by random access. When the AID12 subfield is set to a preset value, the AID12 subfield can indicate that a padding field begins immediately after the AID12 subfield. In this case, the preset value can be 4095 or 4094. When the AID12 subfield is set to a value of 2046, the AID12 subfield can indicate that the User Info field is for an RU (resource unit) that is not assigned to any station.

[0152] The RU Allocation subfield of trigger frames other than the MU-RTS frame indicates the size and location information of the RU / MRU (Multiple Resource Unit) allocated to the destination device of the User Info field, i.e., the station indicated by the AID12 subfield. However, the RU Allocation subfield of the MU-RTS frame indicates a channel only when the destination device of the User Info field transmits a CTS frame. The RU Allocation subfield of the MU-RTS frame indicates the channel on which the destination station's CTS frame will be transmitted. Specifically, the RU Allocation subfield of the MU-RTS frame indicates which channel the CTS frame will be transmitted on: the primary 20 MHz, primary 40 MHz, primary 80 MHz, primary 160 MHz, 80+80 MHz, or primary 320 MHz channel. In this case, MRU means an RU consisting of two or more RUs, and may be defined as one of the following sizes: 52+26-tone, 106+26-tone, 484+242-tone, 996+484-tone, 996+484+242-tone, 2x996+484-tone, 3x996, 3x996+484-tone, and 4x996-tone.

[0153] The UL FEC Coding Type subfield indicates the code type of the TB PPDU, which is a response to the trigger frame. If the value of the UL FEC Coding Type subfield is 0, the UL FEC Coding Type subfield indicates BCC (binary convolution coding). If the value of the UL FEC Coding Type subfield is 1, the UL FEC Coding Type subfield indicates LDPC (low density parity check).

[0154] The UL EHT-MCS subfield indicates the EHT-MCS to be applied to the TB PPDU transmitted in response to the trigger frame.

[0155] When the AID12 subfield indicates that the User Info field is for random access, the SS Allocation / RA-RU Information subfield indicates RA-RU information. When the AID12 subfield indicates that the User Info field is not for random access, the SS Allocation / RA-RU Information subfield indicates information regarding special stream (spatial stream) allocation. Specifically, the SS Allocation / RA-RU Information subfield includes the Starting Spatial Stream subfield, which is a 4-bit field, and the Number Of Spatial Streams subfield, which is a 2-bit field.

[0156] The UL Target Receive Power subfield indicates the power of the signal that the TB PPDU transmitted in response to the trigger frame can be received by the AP's antenna side. When transmitting the TB PPDU, the station can adjust the transmission power of the TB PPDU to the value of the UL Target Receive Power subfield so that the AP can receive it within the power size indicated by the UL Target Receive Power.

[0157] The PS-160 subfield indicates information related to the position and size of the RU / MRU (Multiple-RU) allocated by the User Info field.

[0158] <Rules for MU-RTS Frame Transmission and CTS Frame Response>

[0159] The format of the MU-RTS frame may be set as reserved in the basic trigger frame format with one or more fields. In the Common Info field of the MU-RTS frame, the UL Length field, MU-MIMO HE-LTF Mode field, Number Of HE-LTF Symbols And Midamble Periodicity field, UL STBC field, LDPC Extra Symbol Segment field, AP Tx Power field, Pre-FEC Padding Factor field, PE Disambiguity field, UL Spatial Reuse field, and Doppler and UL HE-SIG-A2 Reserved field may be set as reserved fields. In the User Info field of the MU-RTS frame, the UL EHT-MCS field, UL FEC Coding Type field, SS Allocation / RA-RU Information field, and UL Target Receive Power field may be set as reserved fields. This is because many of the transmission parameters used when transmitting a CTS frame in response to the MU-RTS frame are specified in advance. Specifically, a station that receives an MU-RTS frame can transmit at 6 Mbps using a non-HT duplicate PPDU that includes a CTS frame.

[0160] A station that receives an MU-RTS frame can determine the subchannel on which to transmit a CTS frame as follows: Specifically, the station can transmit a CTS frame using only idle subchannels within the RU / MRU allocated by the MU-RTS frame. The RU / MRU allocated by the MU-RTS frame is the RU / MRU indicated by the RU allocation subfield in the User Info field corresponding to the station in the MU-RTS frame. A station that receives an MU-RTS frame can transmit a CTS frame in an MRU that can be used for transmission.

[0161] For example, if an MU-RTS frame allocates a primary 320 MHz frequency band to a station and one of the 16 subchannels included in the 320 MHz frequency band is determined to be non-idle, the station transmits a CTS frame on 14 of the 16 subchannels included in the 320 MHz frequency band because there is no MRU consisting of 15 subchannels. In this case, the 14 subchannels may be configured with 3x996+484-tone.

[0162] A station can determine the subchannel on which to transmit a CTS frame in response to an MU-RTS frame based on whether the subchannel satisfies all of the following conditions:

[0163] 1. The subchannel is included in the frequency band assigned to the station by the MU-RTS, i.e., indicated by the RU Allocation subfield of the User Info field corresponding to the station.

[0164] 2. A subchannel is determined to be idle in a SIFS after the station receives a PPDU containing an MU-RTS frame, where the subchannel is determined to be idle based on virtual carrier sensing and ED (energy detection)-based CCA.

[0165] 3. The subchannel is the subchannel on which the MU-RTS frame was received.

[0166] 4. The subchannel includes the MRU subcarriers on which the station can transmit. In this case, the subchannel includes the primary channel.

[0167] When an MU-RTS frame triggers multiple stations to transmit CTS frames, the stations can transmit CTS frames on subchannels that satisfy all of conditions 1 to 3. In this case, when an MU-RTS frame triggers a single station to transmit a CTS frame, the station can transmit a CTS frame on a subchannel that satisfies all of conditions 1 to 4.

[0168] A station can determine the subchannel on which to transmit a CTS frame in response to an RTS frame based on whether the subchannel satisfies all of the following conditions:

[0169] 1. The subchannel is included in the frequency band corresponding to the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the RXVECTOR set when the RTS frame is received. For example, if the value of CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the RXVECTOR is 80 MHz, the subchannel must be included in the primary 80 MHz channel.

[0170] 2. The subchannel is determined to be idle in a PIFS before receiving a PPDU containing an RTS frame.

[0171] 3. The subchannel is the subchannel on which the RTS frame was received.

[0172] 4. The subchannel includes the MRU subcarriers on which the station can transmit. In this case, the subchannel includes the primary channel.

[0173] In the above embodiment, the CTS frame may be transmitted on a sub-channel having a bandwidth of 20 MHz. A specific example of transmitting the CTS frame will be described with reference to FIG.

[0174] The CH_BANDWIDTH of RXVECTOR was mentioned in the previous explanation. The CH_BANDWIDTH of RXVECTOR and the CH_BANDWIDTH of TXVECTOR will now be explained.

[0175] When a station transmits, the CH_BANDWIDTH of the TXVECTOR is one of the TXVECTOR parameters of the PHY-TXSTART.request primitive issued from the MAC layer to the physical layer. CH_BANDWIDTH indicates the bandwidth of the frequency band in which the PPDU is transmitted. When a station transmits a non-HT PPDU, CH_BANDWIDTH_IN_NON_HT also indicates the bandwidth of the frequency band in which the PPDU is transmitted. CH_BANDWIDTH_IN_NON_HT may have one of the following values: CBW20 / 40 / 80 / 160 / 80+80 / 320. CH_BANDWIDTH may have one of the following values: CBW20 / 40 / 80 / 160 / 80+80 / 320-1 / 320-2.

[0176] Also, when a station receives a signal, the CH_BANDWIDTH of the RXVECTOR is one of the RXVECTOR parameters of the PHY-RXSTART.indication primitive issued from the physical layer to the MAC layer. The PHY-RXSTART.indication is generated when a PPDU is received at the physical layer. CH_BANDWIDTH indicates the bandwidth of the frequency band in which the PPDU is received. When a station receives a non-HT PPDU, CH_BANDWIDTH_IN_NON_HT also indicates the bandwidth of the frequency band in which the PPDU is received. CH_BANDWIDTH_IN_NON_HT may have one of the following values: CBW 20 / 40 / 80 / 160 / 80+80 / 320. CH_BANDWIDTH may have one of the following values: CBW 20 / 40 / 80 / 160 / 80+80 / 320-1 / 320-2.

[0177] FIG. 14 illustrates a method for a station to determine a subchannel on which to transmit a CTS frame according to an embodiment of the present invention.

[0178] In FIG. 14(a), the MU-RTS frame is received on eight subchannels (SC#1 to SC#8). In this case, the MU-RTS frame may be transmitted in a 20 MHz non-HT PPDU. In another specific embodiment, it may be transmitted in a 160 MHz PPDU. The station indicated by the AID12 subfield of the User Info field of the MU-RTS frame determines whether it can transmit a CTS frame on the first subchannel (SC#1) to the eighth subchannel (SC#8), which are the subchannels indicated by the RU Allocation subfield of the MU-RTS frame. The eighth subchannel (SC#8) is not idle, and the first subchannel (SC#1) to the seventh subchannel (SC#7) are included in the 996+484+242-tone MRU. The station transmits a CTS frame using a duplicated non-HT PPDU on the first subchannel (SC#1) to the seventh subchannel (SC#7). If a station can transmit using 996+484-tone MRU but cannot transmit using 996+484+242-tone MRU, the station transmits a CTS frame using duplicated non-HT PPDUs on the first subchannel (SC#1) to the sixth subchannel (SC#6).

[0179] Referring to FIG. 14(b), the MU-RTS frame may be received on 8 sub-channels. The MU-RTS frame is received on 7 sub-channels (SC#1 to SC#3, SC#5 to SC#8). The station indicated by the AID12 sub-field of the User Info field of the MU-RTS frame determines whether it can transmit a CTS frame on the 7 sub-channels (SC#1 to SC#3, SC#5 to SC#8) which are the sub-channels indicated by the RU Allocation sub-field of the MU-RTS frame. The station determines that the 5th sub-channel (SC#5) is not idle. Among the MRUs in the MRU form in which the station can transmit on the 7 sub-channels (SC#1 to SC#3, SC#5 to SC#8), the MRU with the largest bandwidth is the 484 + 242-tone MRU. When the MU-RTS frame triggers the transmission of CTS frames of multiple stations, the station can transmit a CTS frame on the 7 sub-channels (SC#1 to SC#3, SC#5 to SC#8).

[0180] Although the above-described embodiments have been described using the MU-RTS frame, they may be equally applicable to the RTS frame.

[0181] <TXOP Sharing Using the MU-RTS Trigger Frame>

[0182] The format of the PPDU transmitted as a response to the trigger frame is determined by the type of IEEE 802.11ax (Wi-Fi 6) trigger frame. For example, a station that receives an MU-RTS trigger frame transmits a CTS frame as a response to the MU-RTS trigger frame. For convenience of explanation, the MU-RTS trigger frame is abbreviated as an MU-RTS frame. A station that receives a basic trigger frame transmits an HE TB PPDU as a response to the basic trigger frame. At this time, the station transmits the HE TB PPDU based on the transmission parameters specified in the User Info field of the trigger frame. In this manner, the AP instructs the transmission parameters to be applied when a non-AP station transmits a response to the trigger frame. The transmission parameters determined by the AP may not be optimal. Specifically, even if the AP determines a subchannel to be idle, the station may determine the subchannel as not idle. Therefore, an embodiment is needed that allows the station to determine the transmission parameters to be used when transmitting a response to the trigger frame.

[0183] To this end, the AP can allow a station to use a portion of the TXOP acquired by the AP. In this case, the station can generate a PPDU in the allocated portion without AP triggering and transmit the generated PPDU. For convenience of explanation, allowing a station to use a portion of the TXOP acquired by the AP is referred to as TXOP sharing, and the portion in which the TXOP is shared is referred to as the TXOP sharing portion. The AP can indicate TXOP sharing to a station using an MU-RTS frame. Specifically, the TXOP holder AP can transmit an MU-RTS frame to share the TXOP to a non-AP STA. In this case, a non-AP station that receives the MU-RTS frame can transmit a PPDU other than a TB PPDU in the TXOP sharing portion. For convenience of explanation, the MU-RTS frame indicating TXOP sharing is referred to as an MU-RTS TXS trigger frame. For convenience of explanation, the MU-RTS TXS trigger frame is abbreviated to the MU-RTS TXS frame.

[0184] The MU-RTS TXS frame may include one or more User Info fields. In this case, the AID12 subfield of the User Info field of the MU-RTS TXS frame indicates the non-AP station with which the TXOP is shared. If the AID12 subfield of the User Info field of the MU-RTS TXS frame indicates a station, the station receiving the MU-RTS TXS frame can determine that a shared TXOP has been allocated to the station. The station receiving the MU-RTS TXS frame can transmit a CTS frame in response to the MU-RTS TXS frame. In this case, the interval between the MU-RTS TXS frame and the CTS frame can be SIFS. In addition, the UL length subfield of the Common Info field of the MU-RTS TXS frame can indicate the duration of the shared TXOP. In yet another specific embodiment, the User Info field of the MU-RTS TXS frame can indicate the duration of the shared TXOP to the station corresponding to the User Info field.

[0185] Specifically, 12 bits of the UL length subfield of the Common Info field of the MU-RTS TXS frame may indicate the duration of the shared TXOP. In this case, the UL length subfield may indicate the duration of the shared TXOP in units of 4 us. In yet another specific embodiment, some bits of the UL length subfield of the Common Info field of the MU-RTS TXS frame may indicate the duration of the shared TXOP. For example, 7 bits of the 12 bits of the UL length subfield of the Common Info field of the MU-RTS TXS frame may indicate the duration of the shared TXOP. In this case, the UL length subfield may indicate the duration of the shared TXOP in units of 128 us. For example, 8 bits of the 12 bits of the UL length subfield of the Common Info field of the MU-RTS TXS frame may indicate the duration of the shared TXOP. In this case, the UL length subfield may indicate the duration of the shared TXOP in units of 64 us. In the above embodiment, the maximum duration that can be indicated by the UL length subfield may be 2^14 us. The UL length subfield may indicate a duration equal to the value of the UL length subfield + 1 multiplied by the time unit indicated by the UL length subfield. For example, in the above embodiment, if the UL length subfield indicates a duration in 4 us units and the value of the UL length subfield is 10, the duration of the shared TXOP may be 44 us. A station can determine that a TXOP is shared from the time it receives an MU-RTS TXS frame until the duration indicated by the UL length subfield. In this case, a station can determine that it has received an MU-RTS TXS frame when a PHY-RXEND.indication primitive is generated for a PPDU containing an MU-RTS TXS frame.A non-AP station to which a TXOP is shared must transmit such that the PPDU transmitted by the station and the PPDU which is a response to the PPDU transmitted by the station end within the shared TXOP.

[0186] A non-AP station can transmit a UL PPDU or a P2P PPDU within a shared TXOP. A P2P (peer to peer) PPDU is a PPDU exchanged between non-AP STAs. Therefore, both the station transmitting the P2P PPDU and the station receiving the P2P PPDU are non-AP stations. At this time, the station receiving the P2P PPDU may be an unassociated station that is not associated with the AP to which the non-AP station is associated. Thereby, a non-AP station can transmit a PPDU to a non-AP station that is not associated with the AP to which the non-AP station is associated.

[0187] A non-AP station to which a shared TXOP is assigned within a shared TXOP can transmit a PPDU by ignoring the NAV set by the frame transmitted by the AP that assigned the shared TXOP to the non-AP station.

[0188] <TXOP Sharing Mode>

[0189] The MU-RTS TXS frame can indicate whether P2P PPDU transmission is permitted within a shared TXOP. A non-AP station assigned a shared TXOP can determine whether to transmit a P2P PPDU within the shared TXOP based on whether the MU-RTS TXS frame indicates that P2P PPDU transmission is permitted within the shared TXOP. If the MU-RTS TXS frame indicates that P2P PPDU transmission is permitted within the shared TXOP, the non-AP station assigned a shared TXOP can transmit a P2P PPDU within the shared TXOP. If the MU-RTS TXS frame does not indicate that P2P PPDU transmission is permitted within the shared TXOP, the non-AP station assigned a shared TXOP cannot transmit a P2P PPDU within the shared TXOP. This is because P2P PPDU transmission may reduce the traffic processing efficiency of the entire BSS, and therefore P2P PPDU transmission must be restricted.

[0190] Specifically, the MU-RTS TXS frame can indicate the mode of the shared TXOP. The shared TXOP mode can indicate the type of PPDU that can be transmitted by a non-AP station to which the shared TXOP is assigned. In this case, the shared TXOP mode can include a mode that allows both P2P PPDU and UL PPDU transmission, and a mode that allows UL PPDU transmission but does not allow P2P PPDU transmission.

[0191] A specific subfield of the MU-RTS TXS frame can indicate the mode of the sharing TXOP, and can be called the TXOP Sharing Mode subfield.

[0192] FIG. 15 shows the format of an MU-RTS TXS frame according to an embodiment of the present invention.

[0193] In the embodiment of Figure 15, the Common Info field of the MU-RTS TXS frame includes a TXOP Sharing Mode subfield. A reserved field in the MU-RTS TXS frame may be used as the TXOP Sharing Mode subfield. Specifically, the 20th and 21st bits of the Common Info field may be used as the TXOP Sharing Mode subfield. This is because the 20th and 21st bits of the Common Info field correspond to the GI and HE / EHT-LTF Type field in the basic trigger frame, and the GI and HE / EHT-LTF Type field may be set as a reserved field in the MU-RTS TXS frame.

[0194] The TXOP Sharing Mode subfield can indicate two modes. The first mode indicates that the frame containing the TXOP Sharing Mode subfield is an MU-RTS TXS frame and that P2P PPDU transmission is not allowed within the shared TXOP. In this case, the value of the TXOP Sharing Mode subfield can be 1. The second mode indicates that the frame containing the TXOP Sharing Mode subfield is an MU-RTS TXS frame and that UL PPDU transmission and P2P PPDU transmission are allowed within the shared TXOP. In this case, the value of the TXOP Sharing Mode subfield can be 2.

[0195] A non-AP station to which a shared TXOP is assigned within a shared TXOP can perform non-HT protection with a non-AP station that is the intended recipient of the P2P PPDU before transmitting the P2P PPDU. That is, transmission protection other than the shared TXOP can be performed. Specifically, a non-AP station to which a shared TXOP is assigned can exchange RTS and CTS frames with a non-AP station that is the intended recipient of the P2P PPDU before transmitting the P2P PPDU. In this case, a non-AP station to which a shared TXOP is assigned can transmit an RTS frame within the subchannel in which the CTS frame was transmitted in response to the MU-RTS TXS. In this specification, "within a channel" refers to being included in a frequency band corresponding to the channel, and refers to a frequency band that is the same as or smaller than the bandwidth of the frequency band corresponding to the channel. Also, "within a frequency band" refers to being included in a frequency band, and refers to a frequency bandwidth that is the same as or smaller than the bandwidth of the frequency band. Also, non-HT PPDU exchange may be performed instead of exchanging RTS and CTS frames.

[0196] In an embodiment of the present invention, when a non-AP station that is the intended recipient of a P2P PPDU receives an RTS frame from a station that is not the TXOP holder, the non-AP station can transmit a CTS frame in response to the RTS frame. In another specific embodiment, when a non-AP station that is the intended recipient of a P2P PPDU receives an RTS frame from a station that has been assigned a shared TXOP by the TXOP holder, the non-AP station that is the intended recipient of the P2P PPDU can transmit a CTS frame in response to the RTS frame. In this case, if the station that has been assigned the shared TXOP is the sender of the CTS frame in response to the MU-RTS TXS frame, the non-AP station that is the intended recipient of the P2P PPDU can determine that the station that has been assigned the shared TXOP by the TXOP holder sent the CTS frame. Depending on whether the intended recipient of the CTS frame is an AP, the non-AP station that is the intended recipient of the P2P PPDU can determine that the CTS frame received by the non-AP station is a CTS frame in response to the MU-RTS TXS frame. Furthermore, based on whether the interval between the first transmitted CTS frame and the second transmitted RTS frame is SIFS, the non-AP station that is the intended recipient of the P2P PPDU can determine that the received CTS frame is a CTS frame in response to the MU-RTS TXS frame. Furthermore, based on whether the intended recipient of the MU-RTS frame transmitted by the TXOP holder AP is the same as the sender of the received RTS frame, the non-AP station that is the intended recipient of the P2P PPDU can determine that the received CTS frame is a CTS frame in response to the MU-RTS TXS frame.If the intended recipient of the MU-RTS frame sent by the AP that is the TXOP holder is the same as the sender of the received RTS frame, the non-AP station that is the intended recipient of the P2P PPDU can determine that the CTS frame received by the non-AP station is a CTS frame that is a response to the MU-RTS TXS frame.

[0197] Although the above embodiment has been described using the MU-RTS frame as an example, the above embodiment may be equally applied to the RTS frame.

[0198] In such an embodiment, as described above, the intended recipient of the P2P PPDU can ignore the NAV set by the TXOP holder and send a CTS frame. However, if the NAV of the intended recipient of the P2P PPDU is set by a frame sent by a station that is not the TXOP holder, the intended recipient of the P2P PPDU cannot ignore the NAV. Therefore, in this case, the intended recipient of the P2P PPDU cannot send a CTS frame.

[0199] The intended recipient of the P2P PPDU can determine the sub-channel on which to transmit the CTS frame according to the embodiment described with reference to FIG.

[0200] Furthermore, the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT value of the TXVECTOR of the P2P PPDU can be set to a bandwidth equal to or narrower than the bandwidth of the frequency band in which the CTS frame transmitted by the intended recipient of the P2P PPDU was transmitted. The size of the frequency band in which the CTS frame was transmitted may be the frequency band in which the non-HT PPDU or non-HT duplicate PPDU containing the CTS frame was transmitted. Furthermore, a station to which a shared TXOP is assigned can set the INACTIVE_SUBCHANNELS value of the TXVECTOR of the P2P PPDU based on the subchannels occupied by the CTS frame transmitted by the intended recipient of the P2P PPDU. Specifically, a station to which a shared TXOP is assigned can set the INACTIVE_SUBCHANNELS value of the TXVECTOR of the P2P PPDU to the subchannels not occupied by the CTS frame transmitted by the intended recipient of the P2P PPDU. In a specific embodiment, a station to which a shared TXOP is assigned may set to 1 the INACTIVE_SUBCHANNELS bits of the TXVECTOR of the P2P PPDU that correspond to subchannels not occupied by the CTS frame sent by the intended recipient of the P2P PPDU.

[0201] 16 and 17 illustrate an AP sending an MU-RTS TXS frame to allocate a shared TXOP to a non-AP station according to an embodiment of the present invention.

[0202] In Figure 16, the AP transmits a CTS-to-Self frame to acquire a TXOP. Then, the AP transmits an MU-RTS TXS frame to allocate a shared TXOP to the first station (SAT1). At this time, the AID12 field in the User Info field of the MU-RTS TXS frame indicates the first station (STA1). Also, the value of the TXOP Sharing Mode field of the MU-RTS TXS frame indicates that P2P PPDU transmission is not allowed within the shared TXOP.

[0203] The first station (STA1) determines the duration of the shared TXOP based on the value of the UL Length subfield of the MU-RTS TXS frame. The first station (STA1) prepares an UL PPDU transmission according to the value of the TXOP Sharing Mode field of the MU-RTS TXS frame.

[0204] The first station (STA1) transmits a CTS frame in response to the MU-RTS TXS frame. At this time, the interval between the MU-RTS TXS frame and the CTS frame is SIFS. That is, when SIFS has elapsed since the PHY-RXEND.indication primitive was generated by the PPDU containing the MU-RTS TXS frame, the first station (STA1) transmits the CTS frame. The first station (STA1) transmits the CTS frame and then transmits a UL PPDU. At this time, the interval between the CTS frame and the UL PPDU is SIFS.

[0205] The first station (STA1) transmits the UL PPDU in the subchannel in which it transmitted the CTS frame. At this time, the first station (STA1) can transmit the UL PPDU only in the subchannels included in the RU / MRU in which the first station (STA1) can transmit. Also, as described above, the first station (STA1) can transmit the UL PPDU ignoring the NAV set in the frame transmitted by the AP. At this time, the first station (STA1) performs physical carrier sensing on the subchannel in which the first station (STA1) can transmit the UL PPDU, and if the subchannel is idle, it can transmit the UL PPDU ignoring the NAV set in the frame transmitted by the AP.

[0206] The first station (STA1) can transmit multiple PPDUs within a shared TXOP, specifically, if the PPDUs transmitted by the first station (STA1) and the responses to the PPDUs are completed within the shared TXOP.

[0207] Once the shared TXOP is finished, the AP that is the TXOP holder can start transmitting PPDUs in the remaining TXOP.

[0208] In Figure 17, the AP transmits a CTS-to-Self frame to acquire a TXOP. Then, the AP transmits an MU-RTS TXS frame to allocate a shared TXOP to the first station (SAT1). At this time, the AID12 field in the User Info field of the MU-RTS TXS frame indicates the first station (STA1). Also, the value of the TXOP Sharing Mode field of the MU-RTS TXS frame indicates that UL PPDU and P2P PPDU transmissions are allowed within the shared TXOP.

[0209] The first station (STA1) determines the duration of the shared TXOP based on the value of the UL Length subfield of the MU-RTS TXS frame, and prepares a P2P PPDU transmission to the second station (STA2) based on the value of the TXOP Sharing Mode field of the MU-RTS TXS frame.

[0210] The first station (STA1) sends a CTS frame to the AP, and the first station (STA1) sends an RTS frame to protect P2P PPDU transmission to the second station (STA2). The second station (STA2) sends a CTS frame in response to the RTS frame sent by the first station (STA1).

[0211] The first station (STA1) can transmit multiple PPDUs within a shared TXOP, specifically, if the PPDUs transmitted by the first station (STA1) and the responses to the PPDUs are completed within the shared TXOP.

[0212] Once the shared TXOP is finished, the AP that is the TXOP holder can start transmitting PPDUs.

[0213] <MU-RTS TXSフレームのRU Allocationサブフィールド>

[0214] As described above, the RU Allocation subfield of the trigger frame indicates the RU that will transmit a response to the trigger frame. The RU Allocation subfield of the MU-RTS frame can also indicate the channel on which a CTS frame will be transmitted in response to the MU-RTS. The RU Allocation subfield of the MU-RTS TXS frame can also indicate the RUs on which TXOP sharing will take place. A station that has been allocated a shared TXOP can transmit a UL PPDU or P2P PPDU within the shared TXOP to the RU that the RU Allocation subfield of the MU-RTS TXS frame indicates to the station that has been allocated the shared TXOP.

[0215] The RU Allocation subfield of the MU-RTS frame indicates the channel on which to transmit a CTS frame in response to the MU-RTS, and therefore the RU Allocation subfield of the MU-RTS frame may be set to any one of values ​​61 to 68. Furthermore, a station that receives an MU-RTS frame can determine the location of the primary 20 MHz channel on which to transmit a CTS frame based solely on the value of the RU Allocation subfield of the MU-RTS frame.

[0216] The method for determining the RU indicated by the RU Allocation subfield of the MU-RTS TXS frame may differ from the method for determining the RU indicated by the RU Allocation subfield of the MU-RTS frame. Specifically, a station receiving an MU-RTS TXS frame can determine the RU indicated by the RU Allocation subfield of the MU-RTS TXS frame by the method for determining the RU indicated by the RU Allocation field of a trigger frame other than MU-RTS.

[0217] In addition, when the RU Allocation subfield of the MU-RTS TXS frame indicates the RU with which TXOP sharing is performed, the RU Allocation subfield of the MU-RTS TXS frame can have a value less than 61 in addition to 61 to 68. In this case, the station to which the shared TXOP is allocated can determine the RU with which TXOP sharing is performed based on the UL BW subfield of the Common field and the RU Allocation subfield of the User Info field of the MU-RTS TXS frame.

[0218] Also, a station that receives an MU-RTS TXS frame can transmit a CTS frame on the primary 20 MHz channel even if the RU assigned to the station by the MU-RTS TXS frame does not include the primary 20 MHz channel.A station that receives an MU-RTS TXS frame can transmit a CTS frame on the primary 20 MHz channel and the RU assigned to the station by the MU-RTS TXS frame.

[0219] Furthermore, a station receiving an MU-RTS TXS frame can determine the RUs allocated to the station based on the RU allocation subfield and the PS160 subfield.

[0220] The number of bits in the RU Allocation subfield of the MU-RTS TXS frame may be greater than the number of bits in the RU Allocation field of the MU-RTS frame, for example, the number of bits in the RU Allocation subfield of the MU-RTS frame may be 8 bits, and the number of bits in the RU Allocation subfield of the MU-RTS TXS frame may be 9 bits.

[0221] <BW(TXVECTOR) setting of PPDU sent in shared TXOP>

[0222] A method for setting frequency band-related parameters of a PPDU transmitted in a shared TXOP will be described. Specifically, the bandwidth of the frequency band in which the PPDU is transmitted and whether preamble puncturing is applied to PPDU transmission will be described. Preamble puncturing may be performed by setting frequency band-related TXVECTOR parameters of the PPDU transmitted in the shared TXOP of the PPDU according to a predetermined rule. In this case, the frequency band-related TXVECTOR parameters may include at least one of CH_BANDWIDTH, CH_BANDWIDTH_IN_NON_HT, and INACTIVE_SUBCHANNES. Preamble puncturing may indicate that PPDU transmission is performed without occupying some RUs included in the frequency band (TXVECTOR BW) of the PPDU or some subchannels included in the frequency band. The name TXVECTOR used in the following description is for convenience of explanation, and other parameter names indicating the same information may also be used in the same manner.

[0223] <CH_BANDWIDTH>

[0224] A station to which a shared TXOP is assigned can set the CH_BANDWIDTH of the TXVECTOR of the PPDU to be transmitted within the shared TXOP to be equal to or smaller than the CH_BANDWIDTH of the TXVECTOR of the PPDU containing the CTS frame transmitted in response to the MU-RTS TXS frame. In this case, if the station transmits a non-HT PPDU, CH_BANDWIDTH_IN_NON_HT may be applied instead of CH_BANDWIDTH. These embodiments may be applied when the MU-RTS TXS frame assigns a shared TXOP to only one station.

[0225] In another specific embodiment, a station allocated a shared TXOP can set the CH_BANDWIDTH of the TXVECTOR of the PPDU to be transmitted within the shared TXOP to be equal to or smaller than the RU allocated to the station by the MU-RTS TXS frame. In this case, when the station transmits a non-HT PPDU, CH_BANDWIDTH_IN_NON_HT, not CH_BANDWIDTH, may be applied.

[0226] According to this embodiment, if an MU-RTS TXS frame allocates 484+242-tone RUs in the primary 80 MHz band to a station, the station must set the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the PPDU to be transmitted within the shared TXOP to a bandwidth equal to or narrower than 80 MHz. In this case, even if the station transmits a CTS frame in the 160 MHz frequency band in response to the MU-RTS TXS frame, the station must set the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the PPDU to be transmitted after transmitting the CTS frame to a bandwidth equal to or narrower than 80 MHz. Also, even if the MU-RTS TXS frame is transmitted using a 160 MHz PPDU, if the MU-RTS TXS frame allocates 484+242-tone RUs within the primary 80 MHz to the station, the station can set a bandwidth equal to or narrower than 80 MHz as the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the PPDU transmitted within the shared TXOP.

[0227] The station to which the shared TXOP is assigned can set the CH_BANDWIDTH of the TXVECTOR of the P2P PPDU based on whether the station to which the shared TXOP is assigned exchanges a non-HT PPDU within the shared TXOP with the station receiving the P2P PPDU. The exchange of non-HT PPDUs may be for protecting the transmission of the P2P PPDU. Specifically, the non-HT PPDU exchange may include an RTS frame and a CTS frame. The non-HT PPDU exchange may also include a data frame and an ACK frame. When the station to which the shared TXOP is assigned exchanges a non-HT PPDU within the shared TXOP with the station receiving the P2P PPDU, the station to which the shared TXOP is assigned can set the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the P2P PPDU to a bandwidth equal to or narrower than the CH_BANDWIDTH of the RXVECTOR of the non-HT PPDU received from the station receiving the P2P PPDU.

[0228] If a station to which a shared TXOP is assigned does not exchange non-HT PPDUs within the shared TXOP with a station receiving a P2P PPDU, the station to which the shared TXOP is assigned can set the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the P2P PPDU to a bandwidth equal to or narrower than the value of CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the PPDU containing the CTS frame sent in response to the MURTS TXS frame.

[0229] In yet another specific embodiment, if a station to which a shared TXOP is allocated does not exchange a non-HT PPDU within the shared TXOP with a station receiving a P2P PPDU, the station to which the shared TXOP is allocated can set the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the P2P PPDU to a bandwidth that is equal to or narrower than the value of CH_BANDWIDTH of the TXVECTOR of the PPDU previously transmitted by the station within the shared TXOP.

[0230] A station to which a shared TXOP is assigned can set the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the UL PPDU to a bandwidth equal to or narrower than the value of the CH_BANDWIDTH_IN_NON_HT or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the PPDU containing the CTS frame transmitted in response to the MU-RTS TXS frame.

[0231] A station allocated a shared TXOP can exchange RTS and CTS frames with the AP within the shared TXOP. Specifically, a station allocated a shared TXOP can send RTS frames to the AP and receive CTS frames from the AP. In this case, the station can set the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the UL PPDU to be transmitted after transmitting the CTS frame to a bandwidth equal to or narrower than the CH_BANDWIDTH_IN_NON_HT of the RXVECTOR of the PPDU containing the CTS frame.

[0232] <INACTIVE_SUBCHANNELS>

[0233] A station to which a shared TXOP is assigned can set the INACTIVE_SUBCHANNELS of the TXVECTOR of the PPDU to be transmitted within the shared TXOP based on the subchannels on which it transmitted a PPDU containing a CTS frame in response to an MU-RTS TXS frame. A station to which a shared TXOP is assigned can set the value of the INACTIVE_SUBCHANNELS bits of the TXVECTOR of the PPDU to 1, corresponding to the subchannels on which it does not transmit a PPDU containing a CTS frame in response to an MU-RTS TXS frame.

[0234] A station to which a shared TXOP is assigned can set the INACTIVE_SUBCHANNELS of the TXVECTOR of the PPDU it transmits within the shared TXOP based on the RUs assigned to that station by the MU-RTS TXS frame. A station to which a shared TXOP is assigned can set the value of the INACTIVE_SUBCHANNELS bits of the TXVECTOR of the PPDU to 1, corresponding to the subchannels containing the RUs assigned to the station by the MU-RTS TXS frame.

[0235] A station allocated a shared TXOP can set the INACTIVE_SUBCHANNELS of the TXVECTOR of the P2P PPDU based on whether the station allocated the shared TXOP exchanged a non-HT PPDU within the shared TXOP with the station receiving the P2P PPDU. The exchange of non-HT PPDUs may be for protecting the transmission of the P2P PPDU. Specifically, the non-HT PPDU exchange may include an RTS frame and a CTS frame. The non-HT PPDU exchange may also include a data frame and an ACK frame. If a station allocated a shared TXOP exchanged a non-HT PPDU within the shared TXOP with the station receiving the P2P PPDU, the station can set the INACTIVE_SUBCHANNELS of the TXVECTOR of the P2P PPDU based on the subchannels not occupied by the non-HT PPDU received from the station receiving the P2P PPDU. Specifically, a station to which a shared TXOP is assigned can set the value of the INACTIVE_SUBCHANNELS bits of the TXVECTOR of the P2P PPDU to 1, which bits correspond to subchannels not occupied by non-HT PPDUs received from the station receiving the P2P PPDU.

[0236] In yet another specific embodiment, when a station allocated a shared TXOP has not exchanged a non-HT PPDU in the shared TXOP with a station receiving a P2P PPDU, the station allocated the shared TXOP may set the INACTIVE_SUBCHANNELS of the TXVECTOR of the P2P PPDU based on the subchannels not occupied by the PPDU received by the station in the shared TXOP. Specifically, the station allocated the shared TXOP may set the value of the INACTIVE_SUBCHANNELS bit of the TXVECTOR of the P2P PPDU, which corresponds to the subchannel not occupied by the PPDU received by the station in the shared TXOP, to 1. In these embodiments, the previously transmitted PPDU may be a PPDU transmitted by the station receiving the P2P PPDU.

[0237] Furthermore, the above-described embodiment of the method for setting INACTIVE_SUBCHANNELS of TXVECTOR may be applied when the station receiving the P2P PPDU does not belong to the BSS to which the station to which the shared TXOP is assigned belongs. Furthermore, the above-described embodiment of the method for setting INACTIVE_SUBCHANNELS of TXVECTOR may be applied regardless of whether the station receiving the P2P PPDU belongs to the BSS to which the station to which the shared TXOP is assigned belongs.

[0238] A station to which a shared TXOP is allocated can set the INACTIVE_SUBCHANNELS of the TXVECTOR of the P2P PPDU based on whether the station receiving the P2P PPDU belongs to the BSS to which the station to which the shared TXOP is allocated belongs. Specifically, if the station receiving the P2P PPDU belongs to the BSS to which the station to which the shared TXOP is allocated belongs, the station to which the shared TXOP is allocated can set the INACTIVE_SUBCHANNELS of the TXVECTOR of the P2P PPDU based on the disabled subchannel last indicated by the AP to which the station to which the shared TXOP is allocated is associated. In this case, the station to which the shared TXOP is allocated can set the value of the bit of the INACTIVE_SUBCHANNELS of the TXVECTOR of the P2P PPDU corresponding to the disabled subchannel last indicated by the AP to which the station to which the shared TXOP is allocated is associated to 1. This embodiment prevents a station receiving a P2P PPDU from transmitting on a disabled subchannel of an associated AP. A disabled subchannel may represent a subchannel that the AP has determined not to be used in the BSS operated by the AP. Specifically, a disabled subchannel may be signaled by a Disable Subchannel bitmap in the EHT Operation element.

[0239] If the station receiving the P2P PPDU does not belong to the BSS to which the station to which the shared TXOP is assigned belongs, the station can set the INACTIVE_SUBCHANNELS bit of the TXVECTOR of the P2P PPDU based on the subchannels not occupied by the PPDU received from the station to which the shared TXOP is assigned. Specifically, the station to which the shared TXOP is assigned can set the value of the bit of the INACTIVE_SUBCHANNELS bit of the TXVECTOR of the P2P PPDU corresponding to the subchannels not occupied by the PPDU received from the station to 1. The PPDU received from the station to which the P2P PPDU is assigned may be limited to a PPDU containing a CTS frame. Furthermore, the PPDU received from the station to which the P2P PPDU is assigned may be the PPDU last received from the station to which the P2P PPDU is assigned.

[0240] Furthermore, a station to which a shared TXOP is assigned can transmit a PPDU using the shared TXOP based on the subchannel last designated as a disabled subchannel by the AP to which the station is associated. Specifically, a station to which a shared TXOP is assigned can set the value of the bit corresponding to the subchannel last designated as a disabled subchannel by the AP to which the station is associated to 1 among the INACTIVE_SUBCHANNELS bits of the TXVECTOR of the PPDU to be transmitted using the shared TXOP.

[0241] <How to set TXVECTOR of AP after shared TXOP ends>

[0242] Generally, a TXOP holder station sets the TXVECTOR parameter of a PPDU to be transmitted based on the previous PPDU transmitted within the TXOP. For example, a TXOP holder station sets the TXVECTOR parameter of a PPDU to be transmitted based on the bandwidth of the PPDU previously transmitted within the TXOP. When a shared TXOP is assigned, an AP may not be able to receive the PPDU transmitted within the shared TXOP. Specifically, when a station assigned a shared TXOP transmits a P2P PDDU, there is a high possibility that the AP will not be able to receive the PPDU from the station that is the intended recipient of the P2P PPDU. In particular, the station that is the intended recipient of the P2P PPDU may be a hidden node to the AP. This situation must be taken into consideration when setting the TXVECTOR parameter of a PPDU when the TXOP holder AP transmits after the shared TXOP has ended. A method for setting the TXVECTOR parameter of a PPDU when the TXOP holder AP transmits after the shared TXOP has ended, according to an embodiment of the present invention, will be described.

[0243] In one embodiment of the present invention, the AP that is the TXOP holder can set the TXVECTOR parameter of the PPDU that the AP will transmit after the shared TXOP ends, based on the PPDU that the AP last received. Specifically, the AP that is the TXOP holder can set the CH_BANDWIDHT of the TXVECTOR of the PPDU that the AP will transmit after the shared TXOP ends, based on the bandwidth of the PPDU that the AP last received. In this case, the AP that is the TXOP holder can set the CH_BANDWIDHT of the TXVECTOR of the PPDU that the AP will transmit after the shared TXOP ends to a bandwidth that is equal to or narrower than the bandwidth of the PPDU that the AP last received. The AP that is the TXOP holder can set the INACTIVE_SUBCHANNELS of the TXVECTOR of the PPDU that the AP will transmit after the shared TXOP ends, based on the subchannel occupied by the PPDU that the AP last received. In this case, the TXOP holder AP can set to 1 the INACTIVE_SUBCHANNELS bits of the TXVECTOR of the PPDU that the AP will transmit after the shared TXOP has ended, corresponding to the subchannel not occupied by the PPDU last received by the AP. In one embodiment of the present invention, the TXOP holder AP can set the RU_ALLOCATION of the TXVECTOR of the MU PPDU that the AP will transmit after the shared TXOP has ended, based on the PPDU last received by the AP. Specifically, the TXOP holder AP can set the RU_ALLOCATION of the TXVECTOR of the MU PPDU that the AP will transmit after the shared TXOP has ended, based on the 20 MHz subchannel occupied by the PPDU last received by the AP. In this case, the TXOP holder AP may not be allowed to set the RU included in the 20 MHz subchannel occupied by the PPDU last received by the AP as the RU_ALLOCATION of the TXVECTOR of the MU PPDU that the AP will transmit after the shared TXOP has ended. In this case, the MU PPDU may include at least one of an EHT MU PPDU and an HE MU PPDU.

[0244] The above-described embodiment may be applied when the TXOP of the TXOP holder is not protected by a non-HT PPDU or a non-HT duplicate PPDU.

[0245] Another embodiment for setting the TXVECTOR parameter of the PPDU transmitted by the AP after the shared TXOP has ended may be applied when the TXOP holder AP replaces the non-HT PPDU transmitted to protect the TXOP. For ease of explanation, a PPDU received in response to a non-HT PPDU transmitted to protect the TXOP is referred to as a response non-HT PPDU. The TXOP holder AP can set the TXVECTOR parameter of the PPDU transmitted by the AP after the shared TXOP has ended based on the response non-HT PPDU. Specifically, the TXOP holder AP can set the CH_BANDWIDHT of the TXVECTOR of the PPDU transmitted by the AP after the shared TXOP has ended based on the bandwidth of the response non-HT PPDU. In this case, the TXOP holder AP can set the CH_BANDWIDHT or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the PPDU transmitted by the AP after the shared TXOP has ended to a bandwidth that is equal to or narrower than the bandwidth of the response non-HT PPDU. The TXOP holder AP can set the INACTIVE_SUBCHANNELS in the TXVECTOR of the PPDU that the AP will transmit after the shared TXOP ends, based on the subchannels occupied by the response non-HT PPDU. In this case, the TXOP holder AP can set to 1 the INACTIVE_SUBCHANNELS bits in the TXVECTOR of the PPDU that the AP will transmit after the shared TXOP ends, corresponding to the subchannels not occupied by the response non-HT PPDU. In one embodiment of the present invention, the TXOP holder AP can set the RU_ALLOCATION in the TXVECTOR of the MU PPDU that the AP will transmit after the shared TXOP ends, based on the response non-HT PPDU. Specifically, the TXOP holder AP can set the RU_ALLOCATION in the TXVECTOR of the MU PPDU that the AP will transmit after the shared TXOP ends, based on the 20 MHz subchannels occupied by the response non-HT PPDU.In this case, the TXOP holder AP may not be allowed to set RUs included in the 20 MHz subchannel occupied by the response non-HT PPDU as the RU_ALLOCATION of the TXVECTOR of the MU PPDU that the AP transmits after the shared TXOP ends. In this case, the MU PPDU may include at least one of an EHT MU PPDU and an HE MU PPDU. This embodiment may be applied only when the AP transmits after the shared TXOP ends to a station that transmitted a response non-HT PPDU before the shared TXOP.

[0246] In addition, TXOP protection using non-HT PPDU transmission may include at least one of RTS frame and CTS frame exchange, and MU-RTS frame and CTS frame exchange. In addition, when TXOP protection using non-HT PPDU uses CTS-to-self frame transmission, as in the above-mentioned embodiment, the AP, which is the TXOP holder, can set the TXVECTOR parameter of the PPDU that the AP will transmit after the shared TXOP ends, based on the PPDU that the AP last received.

[0247] 18 and 19 illustrate a method in which an AP, which is a TXOP holder, sets the TXVECTOR parameter of a PPDU that the AP transmits after the shared TXOP ends, according to an embodiment of the present invention.

[0248] In Figure 18(a), the AP transmits a CTS-to-Self frame to acquire a TXOP. The AP transmits an MU-RTS TXS frame to the first station (STA1) to allocate a shared TXOP to the first station (STA1). The first station (STA1) transmits a UL PPDU to the AP within the shared TXOP. After the shared TXOP ends, the AP transmits a PPDU to the second station (STA2). At this time, the AP and the second station (STA2) have not exchanged non-HT PPDUs within the TXOP. Therefore, the AP sets the TXVECTOR parameter of the DL PPDU to be transmitted to the second station (STA2) based on the last received PPDU. At this time, the last received PPDU by the AP is the PPDU containing the ACK frame transmitted by the first station (AP). Because the bandwidth of the PPDU containing the ACK frame transmitted by the first station (STA1) is 80 MHz, the AP sets the CH_BANDWIDTH of the TXVECTOR of the DL PPDU to be transmitted to the second station (STA2) to 80 MHz or a value smaller than 80 MHz. Also, because the third subchannel (SC#3) is punctured in the PPDU containing the ACK frame transmitted by the first station (AP), the AP sets the bit corresponding to the third subchannel in the INACTIVE_SUBCHANNEL of the TXVECTOR of the DL PPDU to be transmitted to the second station (STA2) to 1.

[0249] In Figure 18(b), the AP transmits MU-RTS frames to the first station (STA1) and the second station (STA2) and receives CTS frames from the first station (STA1) and the second station (STA2). As a result, the AP acquires a TXOP. The AP transmits an MU-RTS TXS frame to the first station (STA1) and allocates a shared TXOP to the first station (STA1). The first station (STA1) transmits a UL PPDU to the AP within the shared TXOP. After the shared TXOP ends, the AP transmits a PPDU to the second station (STA2). At this time, the AP and the second station (STA2) have exchanged a non-HT PPDU containing an RTS frame and a non-HT PPDU containing a CTS frame within the TXOP. Therefore, the AP sets the TXVECTOR parameter of the DL PPDU to be transmitted to the second station (STA2) based on the non-HT PPDU containing the CTS frame. Because the bandwidth of the non-HT PPDU containing the CTS frame is 80 MHz, the AP sets the CH_BANDWIDTH of the TXVECTOR of the DL PPDU to be transmitted to the second station (STA2) to 80 MHz or a value smaller than 80 MHz. Also, the non-HT PPDU containing the CTS frame does not include punctured subchannels. Therefore, the AP sets the bits corresponding to the first subchannel (SC#1) through the fourth subchannel (SC#4) of the INACTIVE_SUBCHANNEL of the TXVECTOR of the DL PPDU to be transmitted to the second station (STA2) to 0.

[0250] In Figure 19(a), the AP transmits a CTS-to-Self frame to acquire a TXOP. The AP transmits an MU-RTS TXS frame to the first station (STA1) to allocate a shared TXOP to the first station (STA1). The first station (STA1) transmits a P2P PPDU to the second station (STA2) within the shared TXOP. After the shared TXOP ends, the AP transmits a DL PPDU to the third station (STA3). At this time, the AP and the third station (STA3) have not exchanged non-HT PPDUs within the TXOP. Therefore, the AP sets the TXVECTOR parameter of the DL PPDU to be transmitted to the third station (STA3) based on the last PPDU received. At this time, the last PPDU received by the AP is the P2P PPDU transmitted by the first station (AP). Because the bandwidth of the P2P PPDU transmitted by the first station (AP) is 80 MHz, the AP sets the CH_BANDWIDTH of the TXVECTOR of the DL PPDU to be transmitted to the third station (STA3) to 80 MHz or a value smaller than 80 MHz. Also, because the third subchannel (SC#3) is punctured in the P2P PPDU transmitted by the first station (STA1), the AP sets the bit corresponding to the third subchannel in the INACTIVE_SUBCHANNEL of the TXVECTOR of the DL PPDU to be transmitted to the third station (STA3) to 1.

[0251] In Figure 19(b), the AP transmits MU-RTS frames to the first station (STA1) through the third station (STA3) and receives CTS frames from the first station (STA1) through the third station (STA3). This allows the AP to acquire a TXOP. The AP then transmits an MU-RTS TXS frame to the first station (STA1) and allocates a shared TXOP to the first station (STA1). The first station (STA1) transmits a P2P PPDU to the second station (STA3) within the shared TXOP. After the shared TXOP ends, the AP transmits a PPDU to the third station (STA3). At this time, the AP and the third station (STA3) have exchanged a non-HT PPDU containing an RTS frame and a non-HT PPDU containing a CTS frame within the TXOP. Therefore, the AP sets the TXVECTOR parameter of the DL PPDU to be transmitted to the third station (STA3) based on the non-HT PPDU containing the CTS frame. Because the bandwidth of the non-HT PPDU containing the CTS frame is 80 MHz, the AP sets the CH_BANDWIDTH of the TXVECTOR of the DL PPDU to be transmitted to the third station (STA3) to 80 MHz or a value smaller than 80 MHz. Also, the non-HT PPDU containing the CTS frame does not include punctured subchannels. Therefore, the AP sets the bits corresponding to the first subchannel (SC#1) through the fourth subchannel (SC#4) of the INACTIVE_SUBCHANNEL of the TXVECTOR of the DL PPDU to be transmitted to the third station (STA3) to 0.

[0252] In yet another specific embodiment, restrictions may be applied to the last PPDU transmitted within a shared TXOP, specifically, the last PPDU transmitted within a TXOP may be limited to a PPDU containing a frame transmitted by a station to which the shared TXOP is assigned or for which the AP is the intended recipient.

[0253] In yet another specific embodiment, a station to which a shared TXOP is assigned may signal information about the bandwidth of the PPDU last transmitted in the shared TXOP using the PPDU last transmitted by the station in the shared TXOP. In this case, the PPDU last transmitted by the station in the shared TXOP or a MAC frame included in the PPDU last transmitted by the station in the shared TXOP may include information about the bandwidth of the PPDU last transmitted in the shared TXOP. In addition, the information about the bandwidth of the PPDU last transmitted in the TXOP may include at least one of information about the subchannel occupied by the PPDU last transmitted and information about the subchannel punctured in the PPDU last transmitted.

[0254] <How to set the TXVECTOR of a PPDU when the intended recipient of a PPDU sent within a shared PPDU is changed>

[0255] FIG. 20 illustrates a method for setting the TXVECTOR of a PPDU sent in a shared TXOP when the intended recipient of the PPDU changes, according to an embodiment of the present invention.

[0256] In Figure 20(a), the AP acquires a TXOP and transmits an MU-RTS TXS frame to the first station (STA1). The MU-RTS TXS frame indicates that transmission of P2P PPDUs in addition to UL PPDUs is permitted within the shared TXOP. The first station (STA1) transmits a CTS frame to the AP in response to the MU-RTS TXS frame. At this time, the CTS frame is transmitted in the 80 MHz frequency band. The first station (STA1) transmits an RTS frame to the second station (STA2) before transmitting a P2P PPDU to the second station (STA2). At this time, the RTS frame is transmitted in the 80 MHz frequency band. The second station (STA2) transmits a CTS frame to the first station (STA1). At this time, the CTS frame is transmitted in the 40 MHz frequency band. Therefore, the first station (SAT1) sets the CH_BANDWIDTH of the TXVECTOR of the PPDU to be transmitted to the second station (STA2) to 40 MHz or a value smaller than 40 MHz. The first station (SAT1) receives an ACK frame in the P2P PPDU from the second station (STA2) in the remaining shared TXOP, and transmits a UL PPDU to the AP. Because the bandwidth of the PPDU containing the CTS frame transmitted by the first station (STA1) to the AP is 80 MHz, the first station (STA1) sets the CH_BANDWIDTH of the TXVECTOR of the UL PPDU to 80 MHz or a value smaller than 80 MHz.

[0257] In Figure 20(b), AP acquires the TXOP and transmits a MU-RTS TXS frame to the first station (STA1). The MU-RTS TXS frame indicates that in addition to UL PPDUs, the transmission of P2P PPDUs is allowed within the shared TXOP. The first station (STA1) transmits a CTS frame to AP as a response to the MU-RTS TXS frame. At this time, the CTS frame is transmitted in the 80 MHz frequency band. The first station (SAT1) transmits an RTS frame to the second station (STA2) before transmitting a P2P PPDU to the second station (STA2). At this time, the RTS frame is transmitted in the 80 MHz frequency band. The second station (STA2) transmits a CTS frame to the first station (STA1). At this time, the CTS frame is transmitted in the 40 MHz frequency band. Therefore, the first station (SAT1) sets the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the PPDU to be transmitted to the second station (STA2) to 40 MHz or a value smaller than 40 MHz. The first station (SAT1) receives an ACK frame with a P2P PPDU from the second station (STA2), and in the remaining shared TXOP, transmits a P2P PPDU to the third station (STA3). The first station (STA1) and the third station (STA3) have not exchanged RTS and CTS frames. Also, since the bandwidth of the PPDU including the CTS frame transmitted to AP is 80 MHz, the first station (STA1) sets the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the PPDU to be transmitted to the third station (STA3) to 80 MHz or a value smaller than 80 MHz.

[0258] <AP's TXOP Management Method>

[0259] The AP can perform TXOP recovery after the shared TXOP has ended. If the AP receives a CTS frame from a station after sending an MU-RTS TXS frame to the station, the AP can determine that the shared TXOP allocation to the station has been completed. The AP may be restricted from transmitting PPDUs in the shared TXOP. Furthermore, the station to which the shared TXOP has been assigned may not transmit. This means that the station to which the shared TXOP has been assigned may not have any traffic to transmit within the shared TXOP. If the station to which the shared TXOP has been assigned does not transmit within the shared TXOP, the AP can perform TXOP recovery. Specifically, only UL PPDU transmission is allowed within the shared TXOP, and the channel on which the TXOP sharing took place is idle within PIFS (SIFS + a SlotTime) since the last PPDU transmission within the shared TXOP. In this case, the AP can determine that the shared TXOP has ended. Additionally, only UL PPDU transmissions are allowed within a shared TXOP, and an AP can begin transmitting if the channel where the TXOP sharing took place is idle within PIFS (SIFS+aSlotTime) since the last PPDU transmission within the shared TXOP. These embodiments prevent the TXOP from being lost if no transmission is performed within a PIFS.

[0260] In addition, after the shared TXOP is terminated, the AP can perform TXOP recovery. Specifically, when the shared TXOP is terminated, if the channel on which the TXOP sharing took place is not idle, the AP can perform TXOP recovery. In a specific embodiment, when the shared TXOP is terminated, if there is a TXOP remaining and the channel on which the TXOP sharing took place is not idle, the AP can perform TXOP recovery.

[0261] TXOP recovery performed by the AP may be to attempt a PPDU transmission after the channel has been idle in PFIS. TXOP recovery performed by the AP may also be to perform a new backoff operation. TXOP recovery performed by the AP may also be to wait until the TXNAV timer expires. This TXOP recovery operation differs from the recovery operation performed by the TXOP holder due to a PPDU transmission failure in that it is performed even without a transmission failure. When backoff operation is performed during TXOP recovery, the AP can set the CW[AC] value used during backoff operation to the minimum value of CW[AC]. This is because the MU-RTS TXS frame sent for TXOP sharing was successfully transmitted. When backoff operation is performed during TXOP recovery, the AP can set the QSRC[AC] value used during backoff operation to 0.

[0262] Furthermore, if a backoff operation is performed during TXOP recovery, the AP may not be allowed to extend the TXNAV due to the backoff operation. In this case, the AP maintains the existing TXNAV value and decreases the TXNAV value according to the timer. Furthermore, if a backoff operation is performed during TXOP recovery, the AP may not be allowed to expand the bandwidth of the frequency band in which the TXOP was acquired. In this case, the AP can transmit within the bandwidth of the frequency band in which the TXOP was acquired. If the AP acquired the TXOP using non-HT PPDU protection, the bandwidth of the frequency band in which the TXOP was acquired may be the bandwidth of the frequency band in which the non-HD PPDU was transmitted. If the AP did not acquire the TXOP using non-HT PPDU protection, the bandwidth of the frequency band in which the TXOP was acquired may be the bandwidth of the last PPDU received in the TXOP. If TXOP recovery involves waiting until the TXNAV timer expires, this restriction does not apply. This is because the AP acquires a new TXOP after the TXOP expires.

[0263] <P2P transmission protection method for legacy P2P peer stations>

[0264] As described above, a station assigned a shared TXOP can protect the P2P PPDU transmission by exchanging RTS and CTS frames with the intended recipient of the P2P PPDU before transmitting the P2P PPDU. If the intended recipient of the P2P PPDU is a legacy station, the intended recipient of the P2P PPDU can ignore the RTS frame because it was transmitted by a station other than the AP that holds the TXOP. Therefore, the intended recipient of the P2P PPDU may not transmit a CTS frame to the AP that holds the TXOP. Therefore, a method for protecting the transmission of a P2P PPDU is needed even when the intended recipient of the P2P PPDU is a legacy station.

[0265] The AP can set the value of the Duration field of the MU-RTS TXS frame to a value that will last until a CTS frame is received from the station to which the shared TXOP is assigned. In a specific embodiment, the AP can set the value of the Duration field of the MU-RTS TXS frame and frames transmitted before the MU-RTS TXS frame to a value that will last until a CTS frame is received from the station to which the shared TXOP is assigned. This allows legacy stations to determine that the station to which the shared TXOP is assigned and that sends an RTS frame within the shared TXOP is the TXOP holder. The AP can set the value of the Duration field of the MU-RTS TXS frame to a value that is the time required to transmit a CTS frame, which is a response to the MU-RTS TXS frame, plus 2xSIFS. In yet another specific embodiment, the AP can set the value of the Duration field of the MU-RTS TXS frame to a value that is the time required to transmit a CTS frame plus SIFS. In a specific embodiment, the value of the Duration field can be set to a value that will last until a CTS frame is received from the station to which the TXOP is assigned.

[0266] The above-described and following embodiments may be applied only when P2P PPDU transmission is permitted within a shared TXOP. Furthermore, the above-described embodiments may be applied only when a TXOP is shared within a restricted target wake time (R-TWT) service period (SP). The R-TWT SP is a type of TWT SP, and is a service period in which traffic of a TID designated by an AP as low latency traffic is prioritized. The R-TWT SP may be an R-TWT SP in which at least one MU-RTS TXS frame is scheduled to be transmitted. Specifically, the R-TWT SP may be configured by a TWT element with a Broadcast TWT Recommendation field value set to 5.

[0267] In yet another specific embodiment, the above and below described embodiments may only be applied when the station to which the shared TXOP is assigned exchanges RTS and CTS frames to signal to the AP that it intends to protect its P2P PPDU transmission.

[0268] In yet another specific embodiment, the above-described embodiment and the following embodiment may be applied only when a station to which a shared TXOP is assigned reports that it has traffic to transmit to a P2P peer station. Specifically, the above-described embodiment may be applied only when a station to which a shared TXOP is assigned reports that it has low-latency traffic to transmit to a P2P peer station. In this case, the station to which a shared TXOP is assigned may report to the AP that it has traffic to transmit to the P2P peer station using a PBSR (P2P Buffer Status Report) Control field in the A-Control field of the MAC frame. In this case, the station to which a shared TXOP is assigned indicates the Control ID of the A-Control field in the P2P Buffer Status Report Control.

[0269] In the embodiment described above, a neighboring station may determine that the shared TXOP has ended before the station to which the shared TXOP is assigned sends a non-HT PPDU to protect the transmission of the P2P PPDU. This may result in the neighboring station attempting to transmit within the shared TXOP before the P2P PPDU transmission begins. This will be explained with reference to FIG. 21.

[0270] FIG. 21 illustrates an embodiment of the present invention in which an AP sets the value of the Duration field of an MU-RTS TXS frame until it receives a CTS frame for the MU-RTS TXS frame.

[0271] In FIG. 21, the AP acquires a TXOP and transmits an MU-RTS TXS frame to the first station (STA1). The MU-RTS TXS frame indicates that transmission of a P2P PPDU is permitted in addition to a UL PPDU within the shared TXOP. The AP also sets the value of the Duration field of the MU-RTS TXS frame by the time it receives a CTS frame for the MU-RTS TXS frame. The first station (STA1) transmits an RTS frame to a P2P peer station (P2P peer STA). At this time, a neighboring station (Other STA), which is located near the AP and is a hidden node of the first station (STA1), determines that the TXOP set by the AP has expired. Therefore, while the first station (STA1) is transmitting an RTS frame to the P2P peer station (P2P peer STA), the neighboring station (Other STA) may attempt a new transmission. This may result in interruption of the P2P PPDU transmission. Taking this into consideration, an embodiment of setting the value of the Duration field of the MU-RTS TXS frame will be described.

[0272] The AP may set the value of the Duration field of the MU-RTS TXS frame based on the transmission of a specific frame in the shared TXOP. Specifically, the AP may set the value of the Duration field of the MU-RTS TXS frame to the time of transmission of a specific frame in the shared TXOP. In this case, the specific frame may be a frame included in the UL PPDU that a station assigned to the shared TXOP transmits first after transmitting a response to the MU-RTS TXS frame. For convenience of explanation, the frame included in the UL PPDU that a station assigned to the shared TXOP transmits first after transmitting a response to the MU-RTS TXS frame is referred to as the initiation frame. In yet another specific embodiment, the specific frame may be the AP's response to the initiation frame. The Duration fields of the initiation frame and the response frame may be set to values ​​equal to or smaller than the end point of the shared TXOP.

[0273] In the above embodiment, the AP can set the value of the Duration field of frames transmitted before the MU-RTS TXS frame, as well as the MU-RTS TXS frame, based on the transmission of a specific frame in the shared TXOP. When the above-described embodiment regarding the Duration field value setting is applied, the station to which the shared TXOP is assigned can perform the first frame exchange in the shared TXOP using the previously configured frame exchange. The station to which the shared TXOP is assigned can determine whether the above-described embodiment regarding the Duration field value setting is applied based on the value of the Duration field. Specifically, if the value of the Duration field is equal to or less than the previously configured value, the station to which the shared TXOP is assigned can determine that the above-described embodiment regarding the Duration field value setting is applied. The previously configured value may represent the value set by the embodiment regarding the Duration field setting.

[0274] Specifically, a station to which a shared TXOP is assigned can compare the value of the Duration field with the end time of the shared TXOP to determine whether the above-described embodiment regarding the setting of the Duration field value applies. In a specific embodiment, if the value of the Duration field is smaller than the end time of the shared TXOP, the station to which a shared TXOP is assigned can determine that the above-described embodiment regarding the setting of the Duration field value applies. Also, if the value of the Duration field is equal to or larger than the end time of the shared TXOP, the station to which a shared TXOP is assigned can determine that the above-described embodiment regarding the setting of the Duration field value does not apply.

[0275] The above-mentioned initiation frame may be an RTS frame. Furthermore, the UL PPDU including the initiation frame may be a PPDU including only an RTS frame. In these embodiments, the RTS frame may be an RTS frame whose recipient address is specified as an AP. The value of the Duration field of the RTS frame may be set to the end point of the shared TXOP. Furthermore, the value of the Duration field of the RTS frame may not be set to a value greater than the end point of the shared TXOP. Furthermore, the transmission method of the PPDU including the RTS frame may be specified as follows: A station to which a shared TXOP is assigned can transmit a PPDU including an RTS frame using a pre-specified format and a pre-specified MCS. In this case, the pre-specified format may be a non-HT PPDU or a non-HT duplicate PPDU. Furthermore, the pre-specified MCS may be MCS0 or MCS1. For example, the PPDU including the RTS frame may be a non-HT PPDU in which the RATE subfield of the L-SIG field indicates 6 MB / s.

[0276] The AP can set the duration field of the MU-RTS TXS frame and frames transmitted before the MU-RTS TXS frame to the following values:

[0277] - Time required to transmit a CTS frame in response to an MU-RTS TXS frame + 2*SIFS + time required to transmit an RTS frame sent by a non-AP station, i.e., 2*SIFS + CTS + RTS (2*16us + 44us (6Mbps CTS) + 52us (6Mbps RTS) = 128us)

[0278] - Time required to send a CTS frame in response to an MU-RTS TXS frame + 2*SIFS + time required to send an RTS frame sent by a non-AP station + SIFS. That is, 3*SIFS + CTS + RTS (3*16us + 44us (6Mbps CTS) + 52us (6Mbps RTS) = 144us)

[0279] - Time required to send a CTS frame in response to a MU-RTS TXS frame + 2*SIFS + time required to send an RTS frame sent by a non-AP station + SIFS + time required to send a CTS frame in response from the AP, i.e., 3*SIFS + 2*CTS + RTS (3*16us + 2*44us (6Mbps CTS) + 52us (6Mbps RTS) = 188us).

[0280] As described above, the value of the Duration field of the MU-RTS TXS frame and frames transmitted before the MU-RTS TXS frame may be set based on the transmission time of the response to the UL PPDU containing the start frame. In this case, the PPDU containing the start frame may include a frame requesting an immediate response frame from the AP. The value of the Duration field of the frame requesting an immediate response frame may be set to the end time of the shared TXOP. The AP can set the value of the Duration field of the MU-RTS TXS frame and frames transmitted before the MU-RTS TXS frame as follows:

[0281] - The time required to transmit a CTS frame in response to an MU-RTS TXS frame + 2*SIFS + the time required to transmit a UL PPDU containing a start frame sent by a non-AP station, i.e., 2*SIFS + CTS + UL PPDU containing a start frame.

[0282] - The time required to transmit a CTS frame in response to an MU-RTS TXS frame + 2*SIFS + the time required to transmit a UL PPDU containing a start frame sent by a non-AP station + SIFS, i.e., 3*SIFS + CTS + UL PPDU containing a start frame

[0283] - Time required for sending a CTS frame in response to an MU-RTS TXS frame + 2*SIFS + time required for sending a UL PPDU containing a start frame sent by a non-AP station + SIFS + time required for sending a response frame from the AP, i.e. 3*SIFS + CTS + UL PPDU containing a start frame + response PPDU

[0284] When a station assigned a shared TXOP attempts to transmit both an UL PPDU and a P2P PPDU within the shared TXOP, the station can transmit the P2P PPDU after transmitting the UL PPDU. This prevents a neighboring station from interfering with the P2P PPDU transmission by transmitting the UL PPDU. When a station assigned a shared TXOP transmits a P2P PPDU after transmitting a UL PPDU, the above-described restrictions on PPDU transmissions containing start frames do not apply. In these embodiments, a station assigned a shared TXOP can complete transmission of the UL PPDU containing the start frame within the time indicated by the Duration field values ​​of the MU-RTS TXS frame and the frame transmitted before the MU-RTS TXS frame. The station assigned a shared TXOP can receive a response to the UL PPDU from the AP and transmit an RTS frame to the P2P peer station. Before receiving the RTS frame, the P2P peer station can determine that the AP has ended the TXOP for which it is the TXOP holder and send a CTS frame in response to the RTS frame.

[0285] If the AP sets the value of the Duration field as in the above embodiment, the AP can transmit a frame for TXOP protection after the shared TXOP ends. In this case, the frame for TXOP protection may include at least one of an MU-RTS frame, an RTS frame, and a CTS-to-Self frame. In this case, the AP must set the value of the Duration field of the TXOP protection frame so that the sum of the time used before transmitting the MU-RTS TXS frame and the duration of the shared TXOP does not exceed the TXOP limit.

[0286] FIG. 22 illustrates an AP setting the value of the Duration field of the MU-RTS TXS frame based on the start frame according to an embodiment of the present invention.

[0287] In Figure 22, the AP transmits an MU-RTS TXS frame to allocate a shared TXOP to a station (non-AP STA). The AP sets the values ​​of the Duration fields of the DL PPDU and MU-RTS TXS frame transmitted before transmitting the MU-RTS TXS frame to be equal to or longer than the transmission time of the first UL PPDU transmitted by the station (non-AP STA) in the shared TXOP. The AP transmits a response to the UL PPDU. A neighboring station that receives the response to the UL PPDU sets its NAV based on the response. As a result, when a P2P peer station (P2P peer STA) receives an RTS frame transmitted by the station (non-AP STA), the P2P peer station (P2P peer STA) determines that the station (non-AP STA) is the TXOP holder. The P2P peer station (P2P peer STA) transmits a CTS frame to the station (non-AP STA) in response to the RTS frame.

[0288] In yet another specific embodiment, a station to which a shared TXOP has been assigned can set the sender address, i.e., the TA field, of an RTS frame for protecting the transmission of a P2P PPDU to the MAC address of the AP that established the shared TXOP. Because the sender address indicates the AP that is the TXOP holder, a P2P peer station that receives the RTS frame can transmit a CTS frame in response to the RTS frame. This allows a TXOP for a P2P PPDU to be established without changing the value of the Duration field of the MU-RTS TXS frame or the frame transmitted before the MU-RTS TXS frame, as in the embodiment described with reference to FIG. 22. When a station to which a shared TXOP has been assigned receives a CTS frame from a P2P peer station, the station to which the shared TXOP has been assigned can operate as if the station to which the shared TXOP has been assigned and the P2P peer station had exchanged RTS and CTS frames. Therefore, when a station to which a shared TXOP has been assigned transmits a P2P PPDU, the station to which the shared TXOP has been assigned can apply the frequency bandwidth rules that apply after the exchange of RTS and CTS frames. A station assigned a shared TXOP can operate in this manner when the recipient address of the CTS frame, i.e., the RA field, is identical to the recipient address of the AP that established the shared TXOP. In yet another specific embodiment, a station assigned a shared TXOP can operate in this manner when the recipient address of the CTS frame, i.e., the RA field, is identical to the sender address of the station assigned the shared TXOP, i.e., the TA field.

[0289] Also, when a station to which a shared TXOP is assigned transmits a trigger frame within the shared TXOP, the sender address of the trigger frame can be set to the MAC address of the AP that established the shared TXOP.

[0290] FIG. 23 illustrates that a station that has been allocated a shared TXOP sends an RTS frame with the sender address set as the AP that established the shared TXOP, according to one embodiment of the present invention.

[0291] In Figure 23, the AP transmits an MU-RTS TXS frame to allocate a shared TXOP to a station (non-AP STA). Within the shared TXOP, the station (non-AP STA) transmits an RTS frame to the P2P peer station (P2P peer STA) with the sender address set to AP. When the P2P peer station (P2P peer STA) receives the RTS frame with the sender address set to AP, the P2P peer station (P2P peer STA) transmits a CTS frame to the AP. At this time, the station (non-AP STA) receives the CTS frame and can operate as if it had received a CTS frame with the receiver address indicating the station (non-AP STA). The values ​​of the Duration fields of the MU-RTS TXS frame and frames transmitted before the MU-RTS TXS frame are set to the duration including the shared TXOP. Therefore, stations that are hidden nodes to the station (non-AP STA) in the BSS operated by the AP do not attempt to transmit within the shared TXOP.

[0292] Although the present invention has been described above with reference to wireless LAN communications, the present invention is not limited thereto and may be equally applied to other communications systems such as cellular communications. Furthermore, although the method, apparatus, and system of the present invention have been described in connection with specific embodiments, some or all of the components and operations of the present invention may be implemented using a computer system having a general-purpose hardware architecture.

[0293] The features, structures, effects, etc. described in the above embodiments are included in at least one embodiment of the present invention and are not necessarily limited to one embodiment. Furthermore, the features, structures, effects, etc. exemplified in each embodiment can be combined or modified in other embodiments by a person skilled in the art to which the embodiment belongs. Therefore, the content related to such combinations and modifications should be interpreted as being included within the scope of the present invention.

[0294] The above description focuses on the embodiments, but these are merely illustrative and do not limit the present invention. Therefore, those skilled in the art will understand that various modifications and applications not exemplified above are possible within the scope of the essential characteristics of the present invention. For example, each component specifically illustrated in the embodiments can be modified and implemented. Differences related to such modifications and applications should be construed as being included within the scope of the present invention as defined by the appended claims. [Explanation of symbols]

[0295] 110 processors 120 Communications Department 140 User Interface Section 150 display units 160 memory 210 processor 220 Communications Department 260 memory

Claims

1. A non-AP station for communicating with an AP (access point), a transceiver; and a processor; The processor: Receive a first PPDU including a multi-user-request-to-send (MU-RTS) TXS (TXOP sharing) trigger frame from the AP using the transceiver unit, and the MU-RTS TXS trigger frame allocates a shared TXOP, which is a portion of the TXOP acquired by the AP, to the non-AP station; Using the transceiver unit, transmit a second PPDU including a CTS frame to the AP in response to the MU-RTS TXS frame; A non-AP station transmits a third PPDU within the shared TXOP using the transceiver unit.

2. The processor: The non-AP station of claim 1 , wherein the non-AP station transmits a third PPDU in a bandwidth that is equal to or narrower than the bandwidth of the second PPDU.

3. The non-AP station of claim 2 , wherein the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU is set to a value equal to or narrower than the CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the second PPDU.

4. The processor: The non-AP station of claim 1 , wherein the third PPDU is transmitted based on a subchannel last designated as disabled by the AP.

5. The processor: The non-AP station of claim 1, wherein the non-AP station sets to 1 a bit of INACTIVE_SUBCHANNELS in TXVECTOR of the third PPDU, the bit corresponding to the subchannel last designated as disabled by the AP.

6. The processor: The non-AP station of claim 1 , further comprising: setting a parameter related to a frequency band of the third PPDU based on whether or not a non-HT PPDU exchange has occurred prior to the transmission of the third PPDU in the shared TXOP.

7. The parameters related to the frequency band include CH_BANDWIDTH of TXVECTOR, The processor: If a non-HT PPDU exchange is performed before the transmission of the third PPDU in the shared TXOP, setting the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU to a bandwidth equal to or narrower than the CH_BANDWIDTH_IN_NON_HT of the RXVECTOR of the non-HT PPDU received before the transmission of the third PPDU; The non-AP station of claim 6, wherein if no non-HT PPDU exchange has been performed prior to the transmission of the third PPDU in the shared TXOP, the non-AP station sets the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU to a bandwidth equal to or narrower than the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the second PPDU.

8. The non-AP station of claim 6, wherein the non-HT PPDU exchange before the transmission of the third PPDU in the shared TXOP is an exchange of a non-HT PPDU including an RTS frame and a non-HT PPDU including a CTS frame.

9. The non-AP station of claim 6 , wherein the third PPDU is a P2P PPDU transmitted to a P2P peer station of the non-AP station.

10. The non-AP station of claim 1, wherein a value of a Duration field of the MU-RTS TXS frame is set based on a transmission time point of the second PPDU.

11. the third PPDU is a P2P PPDU transmitted to a P2P peer station of the non-AP station; The processor: The non-AP station of claim 1 , further comprising: before transmitting the third PPDU, transmitting an RTS frame to the P2P peer station, the RTS frame having the MAC address of the AP as a sender address.

12. A method of operating a non-AP station to communicate with an access point (AP), comprising: receiving a first PPDU including a multi user-request to send (MU-RTS) TXS (TXOP sharing) trigger frame from the AP, the MU-RTS TXS trigger frame allocating a shared TXOP, which is a portion of the TXOP acquired by the AP, to the non-AP station; transmitting a second PPDU including a CTS frame to the AP in response to the MU-RTS TXS frame; and A method of operation comprising transmitting a third PPDU within the shared TXOP.

13. Transmitting a third PPDU within the shared TXOP comprises:

13. The method of claim 12, comprising transmitting a third PPDU in a bandwidth that is equal to or narrower than the bandwidth of the second PPDU.

14. The step of transmitting a third PPDU at a bandwidth equal to or narrower than the bandwidth of the second PPDU comprises:

14. The method of claim 13, further comprising setting the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU to a value equal to or narrower than the CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the second PPDU.

15. Transmitting a third PPDU within the shared TXOP comprises: The method of claim 12 , further comprising transmitting the third PPDU based on a subchannel last designated as disabled by the AP.

16. transmitting the third PPDU based on a subchannel last designated as disabled by the AP, The method of claim 12, further comprising setting to 1 a bit of INACTIVE_SUBCHANNELS in TXVECTOR of the third PPDU, the bit corresponding to a subchannel last designated as disabled by the AP.

17. Transmitting a third PPDU within the shared TXOP comprises:

13. The method of claim 12, further comprising: setting a parameter related to a frequency band of the third PPDU based on whether a non-HT PPDU exchange has occurred prior to transmission of the third PPDU in the shared TXOP.

18. The parameters related to the frequency band include CH_BANDWIDTH of TXVECTOR, setting a parameter related to a frequency band of the third PPDU based on whether a non-HT PPDU exchange has been performed before transmitting the third PPDU in the shared TXOP, setting a bandwidth equal to or narrower than the CH_BANDWIDTH_IN_NON_HT of the RXVECTOR of the non-HT PPDU received before the transmission of the third PPDU as the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU when a non-HT PPDU exchange is performed before the transmission of the third PPDU in the shared TXOP; 18. The method of claim 17, further comprising: setting the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU to a bandwidth equal to or narrower than the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the second PPDU when no non-HT PPDU exchange has occurred prior to the transmission of the third PPDU in the shared TXOP.

19. 18. The method of claim 17, wherein the non-HT PPDU exchange before the transmission of the third PPDU in the shared TXOP is an exchange of a non-HT PPDU including an RTS frame and a non-HT PPDU including a CTS frame.

20. The method of claim 17, wherein the third PPDU is a P2P PPDU transmitted to a P2P peer station of the non-AP station.

Images