Wireless communication device using shared TXOP and method of operating the wireless communication device

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 apparatus using a shared TXOP and an operating method of the wireless communication apparatus.

Background Art

[0002] Recently, as the penetration of mobile devices expands, wireless LAN (Wireless Local Area Network) technology that can provide fast wireless internet services to these devices is attracting attention. Wireless LAN technology is a technology that enables mobile devices such as smartphones, smart pads, laptop PCs, portable multimedia players, and embedded devices to wirelessly connect to the Internet in homes, enterprises, or specific service provision areas based on short-range wireless communication technology.

[0003] IEEE (Institute of Electrical and Electronics Engineers) 802.11 has been commercializing or developing various technical standards since it supported the early wireless LAN technology using the 2.4GHz frequency. First, IEEE 802.11b uses the 2.4GHz band frequency and supports a maximum communication speed of 11Mbps. IEEE 802.11a, which was commercialized after IEEE 802.11b, uses the 5GHz band frequency instead of the 2.4GHz band, which reduces the impact of interference compared to the rather crowded 2.4GHz band frequency, and uses OFDM technology to increase the communication speed up to 54Mbps. However, IEEE 802.11a has the disadvantage of a shorter communication range than IEEE 802.11b. Then, IEEE 802.11g, like IEEE 802.11b, uses the 2.4GHz band to achieve a maximum communication speed of 54Mbps, satisfies backward compatibility and has received considerable attention, and is also superior to IEEE 802.11a in terms of communication range.

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

[0005] As the proliferation of wireless LANs accelerates and the applications using them diversify, there is a growing need for new wireless LAN systems that can support very high throughput (VHT) higher than the data processing speed supported by IEEE 802.11n. Among these, IEEE 802.11ac supports a wide bandwidth (80MHz to 160MHz) at the 5GHz frequency. Although the IEEE 802.11ac standard is defined only in the 5GHz band, early 11ac chipsets are expected to support operation in the 2.4GHz band for backward compatibility with older 2.4GHz band products. Theoretically, this standard allows for a minimum wireless LAN speed of 1Gbps and a maximum single-link speed of 500Mbps. This is achieved by extending the wireless interface concepts accepted in 802.11n, including wider radio frequency bandwidth (up to 160MHz), more MIMO spatial streams (up to 8), multi-user MIMO, and high-density modulation (up to 256QAM). Another method for transmitting data using the 60GHz band instead of the conventional 24GHz / 5GHz band is IEEE 802.11ad. IEEE 802.11ad is a transmission standard that 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, limiting its use to devices in short-range spaces.

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

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

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

[0009] According to an embodiment of the present invention, a non-AP station for communicating with an AP (access point) includes a transceiver unit and a processor. The processor uses the transceiver unit to receive a first PPDU from the AP, which includes a MU-RTS (multi-user-request to send) TXS (TXOP sharing) trigger frame. 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. The transceiver unit then uses the transceiver unit to transmit a second PPDU, which includes a CTS frame, to the AP as a response to the MU-RTS TXS frame, and transmits a third PPDU within the shared TXOP.

[0010] The processor can transmit the third PPDU with the same or narrower bandwidth as the second PPDU.

[0011] The same or a narrower value as CH_BANDWIDTH_IN_NON_HT for the TXVECTOR of the second PPDU can be set as CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT for the TXVECTOR of the third PPDU.

[0012] The processor can transmit the third PPDU based on the subchannel that the AP last specified as disabled.

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

[0014] The processor can set parameters related to the frequency bandwidth of the third PPDU based on whether or not a non-HT PPDU exchange occurred in the shared TXOP before the transmission of the third PPDU.

[0015] The frequency bandwidth parameter may include the CH_BANDWIDTH of the TXVECTOR. In this case, if a non-HT PPDU exchange occurs 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 be the same as 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. Also, if a non-HT PPDU exchange does not occur 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 be the same as or narrower than the 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 prior to the transmission of the third PPDU may be an exchange of a non-HT PPDU containing an RTS frame and a non-HT PPDU containing a CTS frame.

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

[0018] The value of the Duration field in 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 the P2P peer station of the non-AP station.

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

[0021] According to an embodiment of the present invention, the operation method of a non-AP station for communicating with an AP (access point) includes the steps of: receiving a first PPDU from the AP including a MU-RTS (multi-user-request to send) TXS (TXOP sharing) trigger frame; the MU-RTS TXS trigger frame assigning 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] The step of transmitting the third PPDU within the shared TXOP may include the step of transmitting the third PPDU with the same or narrower bandwidth than the second PPDU.

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

[0024] The step of transmitting the third PPDU within the shared TXOP may include the step of transmitting the third PPDU based on the 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 the bit corresponding to the subchannel last designated as disabled by the AP, among the bits of INACTIVE_SUBCHANNELS in the TXVECTOR of the third PPDU, to 1.

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

[0027] The parameter relating to the aforementioned frequency band may include the CH_BANDWIDTH of TXVECTOR. At this time, the step of setting parameters related to the frequency bandwidth of the third PPDU based on whether or not a non-HT PPDU exchange occurred in the shared TXOP before the transmission of the third PPDU may include the step of setting the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU to be the same as or narrower than the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the RXVECTOR of the non-HT PPDU received before the transmission of the third PPDU, if a non-HT PPDU exchange occurred in the shared TXOP before the transmission of the third PPDU, and the step of setting the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the third PPDU to be the same as or narrower than the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the second PPDU, if a non-HT PPDU exchange did not occur in the shared TXOP before the transmission of the third PPDU.

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

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

[0030] One embodiment of the present invention provides a wireless communication device using a shared TXOP and a method for operating the wireless communication device. [Brief explanation of the drawing]

[0031] [Figure 1] This figure shows a wireless LAN system according to one embodiment of the present invention. [Figure 2]This figure shows a wireless LAN system according to another embodiment of the present invention. [Figure 3] This figure shows the configuration of a station according to one embodiment of the present invention. [Figure 4] This figure shows the configuration of an access point according to one embodiment of the present invention. [Figure 5] This diagram schematically illustrates the process by which STA establishes a link with AP. [Figure 6] This diagram illustrates the CSMA (Carrier Sense Multiple Access) / CA (Collision Avoidance) method used in wireless LAN communication. [Figure 7] Examples of various standard generational PPDU (PLCP Protocol Data Unit) formats are shown. [Figure 8] Examples of various EHT (Extremely High Throughput) PPDU (Physical Protocol Data Unit) formats and methods for specifying them according to embodiments of the present invention are shown. [Figure 9] This document describes a TXOP protection method using RTS frame and CTS frame exchange. [Figure 10] This document describes a TXOP protection method using MU-RTS and CTS frames. [Figure 11] The format of the trigger frame according to an embodiment of the present invention is shown. [Figure 12] The format of the Common Info field in a trigger frame according to an embodiment of the present invention is shown. [Figure 13] The format of the User Info field in a trigger frame according to an embodiment of the present invention is shown. [Figure 14] This invention provides a method for determining the subchannel through which a station transmits CTS frames. [Figure 15] The format of the MU-RTS TXS frame according to an embodiment of the present invention is shown. [Figure 16]An embodiment of the present invention demonstrates that an AP transmits a MU-RTS TXS frame and assigns a shared TXOP to a non-AP station. [Figure 17] An embodiment of the present invention demonstrates that an AP transmits a MU-RTS TXS frame and assigns a shared TXOP to a non-AP station. [Figure 18] This embodiment of the present invention demonstrates a method by which an AP, which is a TXOP holder, sets the parameters of the TXVECTOR of the PPDU that the AP transmits after the shared TXOP has ended. [Figure 19] This embodiment of the present invention demonstrates a method by which an AP, which is a TXOP holder, sets the parameters of the TXVECTOR of the PPDU that the AP transmits after the shared TXOP has ended. [Figure 20] This invention illustrates a method for setting the TXVECTOR of a PPDU when the intended recipient of the PPDU to which a shared TXOP is sent is changed, according to an embodiment of the present invention. [Figure 21] An embodiment of the present invention shows that the AP sets the value of the Duration field of the MU-RTS TXS frame by the time it receives the CTS frame for the MU-RTS TXS frame. [Figure 22] This embodiment of the present invention demonstrates that the AP sets the value of the Duration field of the MU-RTS TXS frame based on the start frame. [Figure 23] One embodiment of the present invention indicates that a station to which a shared TXOP is assigned transmits an RTS frame in which the sender address is set as the AP that configured the shared TXOP. [Modes for carrying out the invention]

[0032] The terminology used herein has been selected to the greatest extent possible from currently widely used general terms, taking into account the function of the present invention; however, this may differ depending on the intent, conventions, or emergence of new technologies of the articulate persons in the relevant field. In addition, in certain cases, the applicant has arbitrarily selected some terms, and in such cases, the meaning of these terms will be described in the relevant section of the invention description. Therefore, it should be made clear that the terms used herein are not merely names of terms, but should be interpreted based on the substantive meaning of the terms and the content of this specification as a whole.

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

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

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

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

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

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

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

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

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

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

[0043] Figure 3 is a block diagram showing the configuration of station 100 according to one embodiment of the present invention. As shown, 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 wireless LAN packets and may be incorporated into the station 100 or provided externally. According to one embodiment, the communication unit 120 may include at least one communication module using different frequency bands. For example, the communication unit 120 may include communication modules of different frequency bands such as 2.4GHz, 5GHz, 6GHz, and 60GHz. According to one embodiment, the station 100 may include a communication module using a frequency band of 7.125GHz or higher and a communication module using a frequency band of 7.125GHz or lower. Each communication module can perform wireless communication with an AP or external station based on the wireless LAN standard of the frequency band supported by the communication module. Depending on the performance and requirements of the station 100, the communication unit 120 may operate only one communication module at a time or operate multiple communication modules together simultaneously. When the station 100 includes multiple communication modules, each communication module may be provided in an independent form, or the multiple modules may be integrated as a single chip. In embodiments of the present invention, the communication unit 120 can represent an RF (Radio Frequency) communication module that processes RF signals.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0060] <Examples of various PPDU formats>

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

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

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

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

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

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

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

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

[0069]

number

[0070] At this time,

number

[0071]

number

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0095] For example, among the 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 user fields corresponding to the remaining resource units not used for data transmission may include a pre-configured Null STA ID.

[0096] For convenience of description, in the present specification, a frame or a MAC frame may be used with the same meaning as an MPDU.

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

[0098] A Wi-Fi terminal (AP and non-AP station) performs channel sensing to determine whether the channel is idle before transmitting a frame. The Wi-Fi terminal performs communication in an unlicensed band shared with other devices. Such a channel access operation has been described with reference to FIG. 6. Such a channel access operation is applied to DCF (distributed coordination function) and EDCAF (enhanced distributed channel access function) defined in the IEEE 802.11 standard.

[0099] In DCF and EDCAF channel access, stations determine the channel status by performing both physical carrier sensing (CS) and virtual carrier sensing. A station determines a channel is in use if either physical or virtual carrier sensing indicates that the channel is busy. In virtual channel sensing, a station determines a channel is in use if the network allocation vector (NAV) value is not zero. 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 may represent a time interval during which each station does not begin transmitting on the wireless medium, regardless of whether the wireless medium is idle or not. The NAV value decreases over time. In virtual channel sensing, a station determines a channel is idle if the NAV value is zero. The NAV may be set by RTS / CTS frame exchange. Specifically, in RTS frame / CTS frame exchange, the setting may be based on the value of the Duration field of the RTS frame and the Duration field of the CTS frame. In addition to RTS frame / CTS frame exchange, it may also be set based on the value of the Duration field of other MAC frames.

[0100] <EDCAとTXOP>

[0101] EDCA manages traffic by classifying it into four types of access categories (ACs) based on its 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. In addition, the channel access parameters may include one of the parameters related to CW, TXOP, and AIFSN used in backoff operation. This allows for the management of priority for traffic channel access by AC. In EDCA, traffic (MSDU) may be mapped to one of the four ACs based on the traffic category (TC) or traffic stream (TS). In EDCA, each of the four ACs is mapped to one of the four queues, and the traffic is managed by the queue corresponding to the AC. In this case, the four queues may be physically separated, or logically separated even if they are not physically separated.

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

[0103] AC_VI is more robust to transmission delays than voice traffic, but may be an AC for traffic such as video traffic that requires low-latency transmission and must handle large volumes of traffic. AC_VI may have CW-related parameter values ​​that are larger than AC_VO but smaller than other ACs. The TXOP parameter of AC_VI is approximately twice as long as that of AC_VI.

[0104] AC_BE is an AC for traffic that is 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. Also, AC_BE does not have separate TXOP parameters, and a station cannot perform a TXOP transmission sequence in which it transmits a PPDU containing AC_BE traffic, receives an ACK, and then transmits another PPDU containing AC_BE traffic after SIFS.

[0105] AC_BK is a type of AC (Acceptance Code) that is similar to AC_BE in that it is robust to transmission delays, but has a lower priority than the traffic that corresponds to AC_BE. AC_BK uses the same CW parameter values ​​as AC_BE, but uses larger AIFSN parameter values ​​than AC_BE. Also, a TXOP transmission sequence is not possible where a station transmits a PPDU containing AC_BK traffic, receives an ACK, and then transmits another PPDU containing AC_BK traffic after SIFS (Signal Identification System).

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

[0107] Furthermore, 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] By utilizing the EDCA mechanism, Wi-Fi traffic is stored in one of four queues corresponding to four ACs, and can be transmitted to the target device if the AC of the traffic wins a channel access competition with other ACs. In this case, channel access competition between ACs is performed according to each AC's channel access parameters (CW[AC], AIFSN[AC]). The channel access competition behavior performed by each AC is the same as that of DCF. In this case, ACs whose transmitted traffic is not stored in the Q do not need to participate in the channel access competition. Since the CW-related parameters and AIFSN parameter values ​​of each AC are different, AC_VO, which has the smallest CW-related parameters and AIFSN parameters, has a high probability of winning the channel access competition with other ACs. Therefore, AC_VO's traffic is more likely to be served with priority over the traffic of other ACs.

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

[0110] A TXOP holder can transmit multiple frames (multiple PPDUs) within an EDCA TXOP interval, and within the TXOP interval, the TXOP holder can transmit multiple frames consecutively without performing a separate channel access procedure (e.g., a backoff procedure) between the transmissions of each frame. In this case, if the multiple frames are MPDUs or A-MPDUs (Aggregated MAC protocol data units) that do not request an immediate ACK, the transmission of the multiple frames may be performed at SIFS (short interframe space) or RIFS (reduced interframe space) intervals. In this case, if the multiple frames include an MPDU or A-MPDU that requests an immediate ACK, the TXOP holder can transmit the frame requesting an immediate ACK, receive an ACK after transmission, and then transmit the next frame after SIFS.

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

[0112] As mentioned above, a TXOP holder can transmit consecutive frames within a TXOP without performing a separate channel access procedure. Therefore, it is necessary to prevent other terminals from accessing the channel within the TXOP interval. Consequently, a TXOP holder can make known information about the TXOP interval they have acquired.

[0113] A station that is a TXOP holder or begins transmitting after completing the channel access procedure can send an RTS frame to inform other stations of the TXOP section. In this case, the RTS frame is defined as having a Type subfield (the third (B2) and fourth (B3) bits of the Frame Control field) of the MAC frame header set to 01. 2b It is set to and the Subtype subfield of the Frame Control field (bits 5th to 8th of the Frame Control field (B4 to B7)) is 1011 2bThis is a frame that has been set. A terminal that receives an RTS frame from a TXOP holder can set the NAV based on the duration-related information contained in the RTS frame, for example, 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 target device for an RTS frame must respond to the RTS frame with a CTS frame instead of setting the NAV based on the duration information of the RTS frame. In this case, the target device of the RTS frame sent to initiate the TXOP is the TXOP responder and must send a CTS frame as a response to the RTS frame. In this case, the space 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 as: value indicated in the Duration field of the received RTS frame - CTS frame transmission time - SIFS. A terminal that receives a CTS frame can set the NAV based on the duration-related information contained in the CTS frame. The NAV of a terminal that receives an RTS frame from a TXOP holder and a terminal that receives a CTS frame from a TXOP responder are set to 0 after the TXOP acquired by the TXOP holder has ended. This allows the Wi-Fi MAC mechanism to enable the TXOP holder and 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 80MHz bandwidth, but the CTS frame (non-HT duplicate PPDU) responded to by the TXOP responder is only in the primary 40MHz bandwidth, the TXOP holder may use only the primary 40MHz or less primary 40MHz bandwidth (i.e., primary 20MHz) for frame exchange in the acquired TXOP. In other words, the TXOP holder must set the CH_BANDWIDTH (a type of TXVECTOR parameter) of the transmitted PPDU to the same or smaller value 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 the CTS frame to be responded to in a bandwidth smaller than the bandwidth from which the RTS frame was transmitted. In other words, an RTS frame may be an RTS frame transmitted with TXVECTOR's DYN_BANDWIDTH_IN_NON_HT set to Dynamic. If DYN_BANDWIDTH_IN_NON_HT is set to Static and an RTS frame is transmitted from the TXOP holder, the TXOP responder may have to transmit a CTS frame in the same frequency band (BW) in which the RTS frame was received.

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

[0116] In Figure 9, before transmitting the PPDU, the first station (STA1) sends an RTS frame to the second station (STA2), which is the target device for the PPDU. The second station (STA2) determines that the received RTS frame is an RTS frame intended for itself and responds to the first station (STA1) with a CTS frame after SIFS.

[0117] A first neighbor station (STA1_Neighbor), which is a neighbor station of a first station (STA1), sets the value of the Duration field of an RTS frame as NAV after receiving the RTS frame transmitted by the first station (STA1). A second neighbor station (STA2_Neighbor), which is a neighbor station of a second station (STA2), sets NAV based on the value of the Duration field of a 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 while the set NAV is maintained at a non-zero value, and perform operations such as not decrementing a backoff counter. As a result, neighbor terminals that have received the RTS frame or the CTS frame do not attempt transmission in the period where the NAV is maintained at a non-zero value, so the first station (STA1) and the second station (STA2) are free from interference by the neighbor terminals while transmitting / receiving PPDU and ACK frames.

[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 an operation in consideration of the fact that the channel is busy while the first station (STA1) transmits a 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 the CTS frame exchange procedure. APs can use the MU-RTS frame to initiate TXOP and protect the TXOP frame exchange procedure. The MU-RTS frame is a type of trigger frame. When a station receives a MU-RTS frame and the User field of the MU-RTS frame indicates the station's AID12 (LSB12 bit of the Association ID), it sends a CTS frame as a response to the station MU-RTS frame. At this time, multiple stations can send CTS frames simultaneously. When an AP uses the MU-RTS frame to perform TXOP protection, multiple stations can respond with CTS frames, thus protecting TXOP from each neighboring station of multiple stations that are the target devices of DL MU PPDU (Down link multi-user PPDU). In addition, the MU-RTS frame may be used to protect UL MU PPDU. Specifically, before requesting a Trigger-based PPDU (TB) from multiple stations using a trigger frame, the AP can send a MU-RTS frame, causing the multiple stations responding with a TB PPDU to send a CTS frame. At this time, the CTS frames responded by the multiple stations set up a NAV (Network Address Venture) for each station's neighboring stations to protect the TB PPDU and subsequent ACK frames (e.g., Ack, Block Ack). This means that legacy stations (Legacy STAs) 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 sent).

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

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

[0123] The first neighbor station (STA1_Neighbor), being a neighbor of the first station (STA1), sets the NAV based on the value of the Duration field in the CTS frame after receiving the CTS frame transmitted by the first station (STA1). The second neighbor station (STA2_Neighbor), being a neighbor of the second station (STA2), sets the NAV based on the value of the Duration field in the CTS frame after receiving the CTS frame transmitted by the second station (STA2). 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 in virtual carrier sensing while the set NAV is maintained at a non-zero value, and take actions such as not decreasing the backoff counter. Therefore, since a station that has received a CTS frame will not attempt to transmit while the NAV is maintained at a non-zero value, the AP can send an MU PPDU and the first station (STA1) and the second station (STA2) can respond with ACK frames without interference from neighbor stations.

[0124] A trigger frame is a frame type defined in IEEE 802.11ax, where the Type subfield and Subtype subfield of the Frame Control field are both set to 01. 2b and 0010 2b This is the frame that has been set to 01. The value of the Type subfield of the Frame Control field is 01. 2bThis indicates that it is a Control Type, and the value of the Subtype subfield is 0010. 2b This indicates a trigger frame. IEEE 802.11ax defines trigger frames for APs to request response frames from multiple stations simultaneously. MU-RTS frames are used by APs to request CTS frames from multiple STAs (non-AP STAs). Other trigger types besides MU-RTS frames include the Basic Tigger frame for UL MU PPDU requests, the Beamforming Report Poll Tigger frame for requesting beamforming reports, the MU-BAR trigger frame for requesting BlockAck, the Buffer Status Report Poll Tigger frame for requesting buffer status reports, the GCR MU-BAR trigger frame, the Bandwidth Query Report Poll trigger frame, and the NDP Feedback Report Poll trigger frame. The format of trigger frames is explained using Figures 11 to 13.

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

[0126] A trigger frame includes a MAC header containing the Frame Control field, and the Common Info field, User Info List field, Padding field, and FCS field.

[0127] The Frame Control field includes the Type and Subtype subfields, and the trigger frame has two subfields, each 01. 2b and 0010 2b It will be set to this.

[0128] The Common Info field includes a Trigger Type subfield to indicate the type of the trigger frame, a UL Length subfield to indicate the length of the UL transmission to be responded to, and several other fields. The specific format of the Common Info field is illustrated with Figure 12.

[0129] The User Info List field may contain zero or one or more User Info fields that contain information to indicate the target device of the trigger frame. In this case, the User Info fields may also include parameters that the target device should use when sending a response frame after receiving the trigger frame, depending on the type of trigger frame, such as UL DCM and UL MCS. The specific format of the User Info field will be explained using Figure 13.

[0130] The padding field is set to allow time for the target device of the trigger frame to prepare a response frame after the station receives the trigger frame. The AP sending the trigger frame can adjust the length of the padding field considering the performance of the target 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). The CRC is obtained based on the MAC Header value and the Frame Body field value.

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

[0133] The Trigger Type subfield is used to indicate the type of trigger frame. 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 a MU-BAR frame. If the value of the Trigger Type subfield is 3, it indicates a 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 frame. 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 that should be set in the L-SIG LENGTH field of the TB PPDU, which is the response to the trigger frame.

[0135] The More TF subfield indicates whether there are any trigger frames that have been sent since the trigger frame.

[0136] The CS Required subfield indicates whether the target device of the trigger frame should perform CS (Physical & Virtual CS, ED & NAV) when transmitting the response frame. A station transmitting a response frame after receiving a trigger frame instructed 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, the HE-SIG-A field or the 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 the response of the trigger frame.

[0139] The MU-MIMO HE(EHT)-LTF Mode subfield indicates information related to the HE(EHT)-LTF mode that should be applied to the TB PPDU, which is the 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 responded TB PPDU, and is set to 1 if STBC encoding should be applied. However, the UL STBC subfield of the trigger frame that responds with an EHT TB PPDU is a reserved field.

[0142] The LDPC Extra Symbol Segment subfield indicates whether the TB PPDU, which is the response to the trigger frame, should include an LDPC extra symbol segment. If the LDPC Extra Symbol Segment subfield is set to 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's transmit power used when the station transmits the trigger frame. When the station transmits the response frame, it can adjust the 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 provide information to clarify the length of the Packet Extension (PE).

[0145] The UL Spatial Reuse subfield contains four Spatial Reuse subfields that indicate the value to be set in the HE-SIG-A Spatial Reuse field of the HE TB PPDU, which is the response to the trigger frame.

[0146] The Doppler subfield indicates whether the TB PPDU, which is the response to the trigger frame, contains a mid-amble. For trigger frames that trigger the transmission of an EHT TB PPDU, the Doppler subfield may be set as a reserved field. When the subfield is set as a reserved field, the station can operate without considering the value of that field.

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

[0148] The Special User Info Field Present subfield indicates whether or not a User Info field is included in the User Info fields whose AID12 subfield is indicated as 2007.

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

[0150] Figure 13 shows the format of the User Info field in 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 one station, the AID12 subfield may be set to 1-2006. If the trigger frame is an HE trigger frame and the User Info field is for one station, the AID12 subfield may be set to 1-2007. If the User Info field is for random access of an associated station, the value of the AID12 subfield may be set to 0. If the User Info field is for random access of an unassociated station, 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 sent via random access. A value of 2044 in the AID12 subfield indicates that an EHT TB PPDU should be sent via random access. When the AID12 subfield is set to a pre-configured value, the AID12 subfield can indicate that a padding field should begin immediately after it. In this case, the pre-configured value may be 4095 or 4094. When the value of the AID12 subfield is set to 2046, the AID12 subfield can indicate that the User Info field is for a resource unit (RU) that is not assigned to any station.

[0152] The RU Allocation subfield of trigger frames other than MU-RTS frames indicates the size and location information of the RU / MRU (Multiple Resource Unit) assigned to the target device in the User Info field, i.e., the station indicated by the AID12 subfield. However, the RU Allocation subfield of MU-RTS frames indicates the channel only if the target device in the User Info field transmits CTS frames. The RU Allocation subfield of MU-RTS frames indicates the channel on which the target station's CTS frames are transmitted. Specifically, the RU Allocation subfield of MU-RTS frames indicates which channel the CTS frames are transmitted on: Primary 20MHz, Primary 40MHz, Primary 80MHz, Primary 160MHz, 80+80MHz, and Primary 320MHz channels. In this case, MRU means a RU formed by the combination 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 the response to the trigger frame. When the value of the UL FEC Coding Type subfield is 0, it indicates BCC (binary convolution coding). When the value of the UL FEC Coding Type subfield is 1, it indicates LDPC (low density parity check).

[0154] The UL EHT-MCS subfield indicates the EHT-MCS that should be applied to a TB PPDU transmitted in response to a 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 related to special spatial stream allocation. Specifically, the SS Allocation / RA-RU Information subfield includes a Starting Spatial Stream subfield which is a 4-bit field and a Number Of Spatial Streams subfield which is a 2-bit field.

[0156] The UL Target Receive Power subfield indicates the power of a signal that the TB PPDU transmitted in response to the trigger frame can be received at the antenna side of the AP. When transmitting the TB PPDU, the station can adjust the transmit power of the TB PPDU to the value of the UL Target Receive Power subfield, so that the AP receives the TB PPDU within the power magnitude indicated by the UL Target Receive Power.

[0157] The PS160 subfield indicates information related to the position and size of 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 a MU-RTS frame may have one or more fields set as reserved in the format of a basic trigger frame. In the Common Info field of a 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 a 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 sending a CTS frame as a response to a MU-RTS frame are pre-specified. Specifically, a station that receives a MU-RTS frame can transmit it at 6 Mbps using a non-HT duplicate PPDU that includes a CTS frame.

[0160] A station receiving a MU-RTS frame can determine the subchannel on which to transmit the CTS frame as follows: Specifically, the station can transmit the 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 of the User Info field corresponding to the station in the MU-RTS frame. A station receiving a MU-RTS frame can transmit the CTS frame using an MRU on which transmission is possible.

[0161] For example, a MU-RTS frame may assign a station a primary 320MHz frequency band, and it may be determined that one of the 16 subchannels included in the 320MHz frequency band is not idle. In this case, since there is no MRU consisting of 15 subchannels, the station transmits a CTS frame using 14 of the 16 subchannels included in the 320MHz frequency band. In this case, the 14 subchannels may consist of 3x996+484-tones.

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

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

[0164] 2. A subchannel is determined to be idle in the SIFS after the station receives a PPDU containing a MU-RTS frame. At this time, the idleness of the subchannel is determined 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. A subchannel includes a subcarrier of MRU that the station can transmit. In this case, the subchannel includes the primary channel.

[0167] When a MU-RTS frame triggers CTS frame transmission from multiple stations, each station can transmit the CTS frame on a subchannel that satisfies all of conditions 1-3. Similarly, when a MU-RTS frame triggers CTS frame transmission from a single station, that station can transmit the CTS frame on a subchannel that satisfies all of conditions 1-4.

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

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

[0170] 2. Subchannels are determined to be idle in the 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. A subchannel includes a subcarrier of MRU that the station can transmit. In this case, the subchannel includes the primary channel.

[0173] In the embodiment described above, the CTS frame may be transmitted separately for each subchannel having a 20 MHz bandwidth. A specific embodiment of transmitting the CTS frame will be explained with reference to Figure 14.

[0174] In the previous explanation, we mentioned the CH_BANDWIDTH of RXVECTOR. We will now explain the CH_BANDWIDTH of RXVECTOR and the CH_BANDWIDTH of TXVECTOR.

[0175] When a station transmits, the CH_BANDWIDTH parameter of TXVECTOR is one of the TXVECTOR parameters of the PHY-TXSTART.request primitive issued from the MAC layer to the physical layer. CH_BANDWIDTH represents 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 represents 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] Furthermore, when a station receives data, the CH_BANDWIDTH parameter of RXVECTOR is one of the RXVECTOR parameters of the PHY-RXSTART.indication primitive issued from the physical layer to the MAC layer. Also, 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: 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.

[0177] Figure 14 shows a method for determining the subchannel through which a station according to an embodiment of the present invention transmits CTS frames.

[0178] In Figure 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 using a 20MHz non-HT PPDU. In other specific embodiments, it may also be transmitted using a 160MHz 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 subchannels indicated by the RU Allocation subfield of the MU-RTS frame, from the 1st subchannel (SC#1) to the 8th subchannel (SC#8). The 8th subchannel (SC#8) is not idle, and the 1st subchannel (SC#1) to the 7th subchannel (SC#7) are included in the 996+484+242-tone MRU. The station transmits the CTS frame using a duplicated non-HT PPDU on the 1st subchannel (SC#1) to the 7th 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 CTS frames using duplicated non-HT PPDUs on subchannels 1 (SC#1) through 6 (SC#6).

[0179] Referring to FIG. 14(b), an MU-RTS frame may be received on 8 subchannels. The MU-RTS frame is received on 7 subchannels (SC#1 to SC#3, SC#5 to SC#8). The station indicated by the AID12 subfield of the User Info field of the MU-RTS frame determines whether a CTS frame can be transmitted on the 7 subchannels (SC#1 to SC#3, SC#5 to SC#8) that are the subchannels indicated by the RU Allocation subfield of the MU-RTS frame. The station determines that the 5th subchannel (SC#5) is not idle. Among the MRU configurations that allow the station to transmit on the 7 subchannels (SC#1 to SC#3, SC#5 to SC#8), the MRU with the largest bandwidth is a 484+242-tone MRU. When the MU-RTS frame triggers CTS frame transmission of a plurality of stations, the station can transmit the CTS frame on the 7 subchannels (SC#1 to SC#3, SC#5 to SC#8).

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

[0181] <TXOP sharing using MU-RTS trigger frame>

[0182] The format of the PPDU sent as a response to an IEEE 802.11ax (Wi-Fi 6) trigger frame is determined by the type of trigger frame. For example, a station that receives a MU-RTS trigger frame sends a CTS frame as a response to the MU-RTS trigger frame. For convenience of explanation, the MU-RTS trigger frame will be abbreviated as the MU-RTS frame. A station that receives a basic trigger frame sends an HE TB PPDU as a response to the basic trigger frame. In this case, the station sends the HE TB PPDU based on the transmission parameters indicated in the User Info field of the trigger frame. In this way, the AP instructs the non-AP station on the transmission parameters to apply when sending a response to a trigger frame. The transmission parameters determined by the AP may not be the optimal transmission parameters. Specifically, even if the AP determines that a subchannel is idle, the station may determine that the subchannel is not idle. Therefore, an implementation is needed in which the station can determine the transmission parameters to use when sending a response to a trigger frame.

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

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

[0185] Specifically, the 12 bits of the UL length subfield in the Common Info field of the MU-RTS TXS frame can indicate the duration of a shared TXOP. In this case, the UL length subfield can indicate the duration of a shared TXOP in 4us units. Furthermore, in other specific embodiments, some bits of the UL length subfield in the Common Info field of the MU-RTS TXS frame can indicate the duration of a shared TXOP. For example, 7 of the 12 bits of the UL length subfield in the Common Info field of the MU-RTS TXS frame can indicate the duration of a shared TXOP. In this case, the UL length subfield can indicate the duration of a shared TXOP in 128us units. For example, 8 of the 12 bits of the UL length subfield in the Common Info field of the MU-RTS TXS frame can indicate the duration of a shared TXOP. In this case, the UL length subfield can indicate the duration of a shared TXOP in 64us units. In the embodiment described above, the maximum duration that can be indicated by the UL length subfield may be 2^14us. The UL length subfield can 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 embodiment described above, if the UL length subfield indicates a duration in units of 4us and the value of the UL length subfield is 10, the duration of the shared TXOP may be 44us. The station can determine that the TXOP will be shared from the time the MU-RTS TXS frame is received until the duration indicated by the UL length subfield. In this case, the station can determine that it received the MU-RTS TXS frame at the time the PHY-RXEND.indication primitive occurred because the PPDU contained the MU-RTS TXS frame.A non-AP station with a shared TXOP must perform transmission such that the PPDU transmitted by the station and the PPDU that is a response to the PPDU transmitted by the station end within the shared TXOP.

[0186] A non-AP station may 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. Accordingly, 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 a station that is unassociated with the AP that the non-AP station is associated with. This allows the non-AP station to transmit a PPDU to a non-AP station that is not associated with the AP that the non-AP station is associated with.

[0187] The non-AP station assigned the shared TXOP within the shared TXOP may 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 the transmission of P2P PPDUs is permitted within a shared TXOP. A non-AP station assigned to a shared TXOP can decide whether or not to transmit P2P PPDUs within the shared TXOP based on whether the MU-RTS TXS frame indicates that the transmission of P2P PPDUs is permitted within the shared TXOP. If the MU-RTS TXS frame indicates that the transmission of P2P PPDUs is permitted within the shared TXOP, the non-AP station assigned to the shared TXOP can transmit P2P PPDUs within the shared TXOP. If the MU-RTS TXS frame does not indicate that the transmission of P2P PPDUs is permitted within the shared TXOP, the non-AP station assigned to the shared TXOP cannot transmit P2P PPDUs within the shared TXOP. This is because the transmission of P2P PPDUs can reduce the overall traffic processing efficiency of the BSS, and therefore the transmission of P2P PPDUs needs to be restricted.

[0190] Specifically, the MU-RTS TXS frame can specify the mode of a shared TXOP. The mode of the shared TXOP can specify the types of PPDUs that a non-AP station to which the shared TXOP is assigned can transmit. In this case, the mode of the shared TXOP may include a mode that allows both P2P PPDU and UL PPDU transmissions, and a mode that allows UL PPDU transmissions but does not allow P2P PPDU transmissions.

[0191] A specific subfield in the MU-RTS TXS frame can indicate the mode of a shared TXOP. In this case, the field can be called the TXOP Sharing Mode subfield.

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

[0193] In the embodiment shown in Figure 15, the Common Info field of the MU-RTS TXS frame includes the TXOP Sharing Mode subfield. The reserved field of 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 can 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 a MU-RTS TXS frame, and that P2P PPDU transmission is not permitted within the shared TXOP. In this case, the value of the TXOP Sharing Mode subfield may be 1. The second mode indicates that the frame containing the TXOP Sharing Mode subfield is a MU-RTS TXS frame, and that both UL PPDU transmission and P2P PPDU transmission are permitted within the shared TXOP. In this case, the value of the TXOP Sharing Mode subfield may be 2.

[0195] Within a shared TXOP, a non-AP station to which a shared TXOP has been assigned can perform non-HT protection with the non-AP station that is the recipient of the P2P PPDU before transmitting the P2P PPDU. In other words, a different transmission protection other than the shared TXOP may be performed. Specifically, a non-AP station to which a shared TXOP has been assigned can perform RTS frame and CTS frame exchange with the non-AP station that is the intended recipient of the P2P PPDU before transmitting the P2P PPDU. At this time, the non-AP station to which a shared TXOP has been assigned can transmit an RTS frame within the subchannel in which it transmitted a CTS frame as a response to the MU-RTS TXS. In this specification, "within the channel" means being included in the 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 the frequency band" means being included in the wavenumber band, and refers to a frequency bandwidth that is the same as or smaller than the bandwidth of the frequency band. In addition, non-HT PPDU exchange may be performed instead of RTS frame and CTS frame exchange.

[0196] In an embodiment of the present invention, if a non-AP station, which is the intended recipient of a P2P PPDU, receives an RTS frame from a station that is not a TXOP holder, the non-AP station can send a CTS frame as a response to the RTS frame. In yet another specific embodiment, if a non-AP station, which is the intended recipient of a P2P PPDU, receives an RTS frame from a station to which a shared TXOP has been assigned by a TXOP holder, the non-AP station, which is the intended recipient of the P2P PPDU, can send a CTS frame as a response to the RTS frame. At this time, if the station to which the shared TXOP has been assigned is the sender of the CTS frame which is a response to the MU-RTS TXS frame, the non-AP station, which is the intended recipient of the P2P PPDU, can determine that the station to which the shared TXOP has been assigned by the TXOP holder has sent the CTS frame. Based on whether or not the intended recipient of the CTS frame is an AP, the non-AP station, which is the intended recipient of the P2P PPDU, can determine that the CTS frame received by the non-AP station is a CTS frame which is a response to the MU-RTS TXS frame. Furthermore, based on whether the interval between the first-sent CTS frame and the later-sent RTS frame is SIFS, a 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. Also, based on whether the intended recipient of the MU-RTS frame sent by the AP, which is the TXOP holder, is the same as the sender of the received RTS frame, a 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.If the intended recipient of a MU-RTS frame sent by an AP that is a TXOP holder is the same as the sender of a received RTS frame, a 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 MU-RTS frame was used as an example in the above embodiment, the above embodiment may also be applied identically to an 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 transmit a CTS frame. However, if the NAV is set for the intended recipient of the P2P PPDU by a frame transmitted 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 transmit a CTS frame.

[0199] The intended recipient of the P2P PPDU can determine the subchannel on which to transmit the CTS frame, as described in the embodiment illustrated with Figure 14.

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

[0201] Figures 16 and 17 illustrate an embodiment of the present invention in which an AP transmits a MU-RTS TXS frame and assigns a shared TXOP to a non-AP station.

[0202] In Figure 16, the AP obtains a TXOP by sending a CTS-to-Self frame. Subsequently, the AP assigns the shared TXOP to the first station (SAT1) by sending a MU-RTS TXS frame. 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 in the MU-RTS TXS frame indicates that P2P PPDU transmission is not permitted within the shared TXOP.

[0203] Station 1 (STA1) determines the duration of the shared TXOP based on the value of the UL Length subfield of the MU-RTS TXS frame. Station 1 (STA1) prepares for UL PPDU transmission based on the value of the TXOP Sharing Mode field of the MU-RTS TXS frame.

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

[0205] Station 1 (STA1) transmits the UL PPDU within the subchannel from which it transmitted the CTS frame. At this time, Station 1 (STA1) can only transmit the UL PPDU within the subchannels included in the RU / MRU from which Station 1 (STA1) can transmit. Furthermore, as mentioned above, Station 1 (STA1) can transmit the UL PPDU while ignoring the NAV set by the frame transmitted by the AP. At this time, Station 1 (STA1) performs physical carrier sensing on the subchannel from which it can transmit the UL PPDU, and if the subchannel is idle, it can transmit the UL PPDU while ignoring the NAV set by the frame transmitted by the AP.

[0206] The first station (STA1) can send multiple PPDUs within the shared TXOP. Specifically, if the PPDUs sent by the first station (STA1) and the responses to those PPDUs are completed within the shared TXOP, the first station (STA1) can send multiple PPDUs within the shared TXOP.

[0207] Once the shared TXOP ends, the AP that holds the TXOP can begin sending PPDUs within the remaining TXOP.

[0208] In Figure 17, the AP obtains a TXOP by sending a CTS-to-Self frame. Subsequently, the AP assigns the shared TXOP to the first station (SAT1) by sending a MU-RTS TXS frame. 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 in the MU-RTS TXS frame indicates that UL PPDU and P2P PPDU transmissions are permitted within the shared TXOP.

[0209] Station 1 (STA1) determines the duration of the shared TXOP based on the value of the UL Length subfield of the MU-RTS TXS frame. Station 1 (STA1) prepares for a P2P PPDU transmission to Station 2 (STA2) based on the value of the TXOP Sharing Mode field of the MU-RTS TXS frame.

[0210] Station 1 (STA1) sends a CTS frame to AP, and Station 1 (STA1) sends an RTS frame to Station 2 (STA2) to protect P2P PPDU transmission. Station 2 (STA2) sends a CTS frame in response to the RTS frame sent by Station 1 (STA1).

[0211] The first station (STA1) can send multiple PPDUs within the shared TXOP. Specifically, the first station (STA1) can send multiple PPDUs within the shared TXOP when the PPDUs sent by the first station (STA1) and the responses to those PPDUs are completed within the shared TXOP.

[0212] Once the shared TXOP is terminated, the AP that holds the TXOP can begin sending PPDUs.

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

[0214] As mentioned above, the RU Allocation subfield of the trigger frame indicates the RU that will send a response to the trigger frame. The RU Allocation subfield of the MU-RTS frame can also indicate the channel to send a CTS frame as a response to MU-RTS. The RU Allocation subfield of the MU-RTS TXS frame can indicate the RU on which TXOP sharing will take place. A station to which a shared TXOP is assigned can send a UL PPDU or P2P PPDU within the shared TXOP at the RU indicated by the RU Allocation subfield of the MU-RTS TXS frame to the station to which the shared TXOP is assigned.

[0215] The RU Allocation subfield of the MU-RTS frame indicates the channel on which to send the CTS frame in response to MU-RTS; therefore, the RU Allocation subfield of the MU-RTS frame may be set to any one of the values ​​from 61 to 68. Furthermore, a station receiving the MU-RTS frame can determine the location of the primary 20MHz channel on which to send the 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 a MU-RTS TXS frame may differ from the method for determining the RU indicated by the RU Allocation subfield of a MU-RTS frame. Specifically, a station receiving a MU-RTS TXS frame can determine the RU indicated by the RU Allocation subfield of the MU-RTS TXS frame using the same method as for determining the RU indicated by the RU Allocation field of a non-MU-RTS trigger frame.

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

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

[0219] Furthermore, a station that receives a MU-RTS TXS frame can determine the RU assigned 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 RU Allocation subfield of the MU-RTS frame may have 8 bits, while the RU Allocation subfield of the MU-RTS TXS frame may have 9 bits.

[0221] <BW (TXVECTOR) settings for PPDU sent within a shared TXOP>

[0222] This document describes how to set frequency band-related parameters for PPDUs transmitted within a shared TXOP. Specifically, it describes the bandwidth of the frequency band to which the PPDU is transmitted and whether or not to apply preamble puncturing to the PPDU transmission. Preamble puncturing may be set according to pre-specified rules for the frequency band-related TXVECTOR parameters of the PPDU transmitted within the shared TXOP of the PPDU. In this case, the frequency band-related TXVECTOR parameters may include at least one of CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT and INACTIVE_SUBCHANNES. Preamble puncturing can indicate that the PPDU transmission will not occupy some of the RUs included in the frequency band of the PPDU (TXVECTOR's BW) or some of the subchannels included in the frequency band. The names of TXVECTOR used in the following description are for illustrative purposes only, and the embodiments of this invention may be applied identically to other parameter names that indicate the same information.

[0223] <CH_BANDWIDTH>

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

[0225] In yet another specific embodiment, a station assigned a shared TXOP may set the CH_BANDWIDTH of the TXVECTOR of the PPDU transmitted within the shared TXOP to be the same as or smaller than the RU assigned 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, which is not CH_BANDWIDTH, may be applied.

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

[0227] Based on whether the station assigned to the shared TXOP has exchanged a non-HT PPDU within the shared TXOP with a station receiving a P2P PPDU, the station assigned to the shared TXOP can set the CH_BANDWIDTH of the P2P PPDU's TXVECTOR. The exchange of non-HT PPDUs may be for the purpose of protecting the transmission of P2P PPDUs. Specifically, the non-HT PPDU exchange may include RTS frames and CTS frames. The non-HT PPDU exchange may also include data frames and ACK frames. If the station assigned to the shared TXOP has exchanged a non-HT PPDU within the shared TXOP with a station receiving a P2P PPDU, the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the P2P PPDU's TXVECTOR can be set to the same or narrower bandwidth as the CH_BANDWIDTH of the non-HT PPDU received from the P2P PPDU receiving station.

[0228] If a station assigned a shared TXOP does not exchange non-HT PPDUs within the shared TXOP with a station receiving P2P PPDUs, the station assigned the shared TXOP may set the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the P2P PPDU to the same or narrower bandwidth as the CH_BANDWIDTH_IN_NON_HT value of the TXVECTOR of the PPDU containing the CTS frame transmitted as a response to the MURTS TXS frame.

[0229] In yet another specific embodiment, if a station assigned a shared TXOP does not exchange non-HT PPDUs within the shared TXOP with a station receiving P2P PPDUs, the station assigned the shared TXOP can set the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the P2P PPDU's TXVECTOR to be the same as or narrower than the CH_BANDWIDTH value 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 value of the TXVECTOR of a PPDU containing a CTS frame transmitted as a response to a MU-RTS TXS frame to the same or narrower bandwidth as the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT value of the PU PPDU's TXVECTOR.

[0231] A station assigned a shared TXOP can exchange RTS and CTS frames with an AP within the shared TXOP. Specifically, a station assigned a shared TXOP can send an RTS frame to an AP and receive a CTS frame from the AP. At this time, the station can set the CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the PPDU containing the CTS frame to be the same as or narrower than the CH_BANDWIDTH_IN_NON_HT of the PUDU that will be sent after the CTS frame is sent.

[0232] <INACTIVE_SUBCHANNELS>

[0233] A station assigned a shared TXOP can set the INACTIVE_SUBCHANNELS bit of the TXVECTOR of the PPDU to be transmitted within the shared TXOP, based on the subchannel from which the PPDU containing the CTS frame sent as a response to the MU-RTS TXS frame was transmitted. The station assigned a shared TXOP can set the value of the bit in the INACTIVE_SUBCHANNELS bit of the PPDU's TXVECTOR to 1, corresponding to the subchannel from which the PPDU containing the CTS frame sent as a response to the MU-RTS TXS frame was not transmitted.

[0234] A station assigned a shared TXOP can set the INACTIVE_SUBCHANNELS bit of the TXVECTOR of the PPDU transmitted within the shared TXOP based on the RU assigned to that station by the MU-RTS TXS frame. The station assigned a shared TXOP can set the value of the bit in the INACTIVE_SUBCHANNELS bit of the PPDU's TXVECTOR that corresponds to the subchannel containing the RU assigned to the station by the MU-RTS TXS frame to 1.

[0235] Based on whether the station assigned to the shared TXOP has exchanged non-HT PPDUs within the shared TXOP with a station receiving P2P PPDUs, the station assigned to the shared TXOP can set the INACTIVE_SUBCHANNELS of the P2P PPDU's TXVECTOR. The exchange of non-HT PPDUs may be for the purpose of protecting the transmission of P2P PPDUs. Specifically, the non-HT PPDU exchange may include RTS frames and CTS frames. The non-HT PPDU exchange may also include data frames and ACK frames. If the station assigned to the shared TXOP has exchanged non-HT PPDUs within the shared TXOP with a station receiving P2P PPDUs, the INACTIVE_SUBCHANNELS of the P2P PPDU's TXVECTOR can be set based on the subchannels not occupied by the non-HT PPDU received from the P2P PPDU receiving station. Specifically, a station to which a shared TXOP is assigned can set the value of the bit in the INACTIVE_SUBCHANNELS bit of the P2P PPDU's TXVECTOR to 1, corresponding to the bit that is not occupied by the non-HT PPDU received from the station receiving the P2P PPDU.

[0236] In further specific embodiments, if a station assigned a shared TXOP has not exchanged a non-HT PPDU within the shared TXOP with a station receiving a P2P PPDU, the station assigned the shared TXOP can set the INACTIVE_SUBCHANNELS of the P2P PPDU's TXVECTOR based on subchannels not occupied by the PPDU received by the station within the shared TXOP. Specifically, the station assigned the shared TXOP can set the value of the bit in the INACTIVE_SUBCHANNELS of the P2P PPDU's TXVECTOR corresponding to a subchannel not occupied by the PPDU received by the station within 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 aforementioned embodiment of the method for setting INACTIVE_SUBCHANNELS for TXVECTOR may be applied when the station receiving P2P PPDU does not belong to the same BSS as the station to which the shared TXOP is assigned. Also, the aforementioned embodiment of the method for setting INACTIVE_SUBCHANNELS for TXVECTOR may be applied regardless of whether the station receiving P2P PPDU belongs to the same BSS as the station to which the shared TXOP is assigned.

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

[0239] If a station receiving P2P PPDUs does not belong to the same BSS as the station to which the shared TXOP is assigned, the INACTIVE_SUBCHANNELS bit of the P2P PPDU's TXVECTOR can be set based on the subchannels not occupied by the PPDU received from the P2P PPDU receiving station. Specifically, the station to which the shared TXOP is assigned can set the value of the bit in the INACTIVE_SUBCHANNELS bit of the P2P PPDU's TXVECTOR corresponding to the subchannel not occupied by the PPDU received from the P2P PPDU receiving station to 1. The PPDU received from the P2P PPDU receiving station may be limited to PPDUs containing CTS frames. Also, the PPDU received from the P2P PPDU receiving station may be the last PPDU received from that station.

[0240] Furthermore, a station assigned a shared TXOP can transmit a PPDU via the shared TXOP based on the subchannel that the AP to which the station assigned the shared TXOP is connected last designated as a disabled subchannel. Specifically, a station assigned a shared TXOP can set the value of the bit in the INACTIVE_SUBCHANNELS bit of the TXVECTOR of the PPDU transmitted via the shared TXOP that corresponds to the subchannel that the AP to which the station assigned the shared TXOP is connected last designated as a disabled subchannel to 1.

[0241] <How to configure AP's TXVECTOR after shared TXOP operation>

[0242] Generally, a station that is a TXOP holder sets the TXVECTOR parameter of the PPDU to be transmitted based on previously transmitted PPDUs within the TXOP. For example, a station that is a TXOP holder sets the TXVECTOR parameter of the PPDU to be transmitted based on the bandwidth of previously transmitted PPDUs within the TXOP. When a shared TXOP is configured, an AP may not be able to receive PPDUs transmitted within the shared TXOP. Specifically, when a station to which a shared TXOP has been assigned transmits a P2P PPDU, it is highly likely 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 for the AP. When an AP that is a TXOP holder transmits after the shared TXOP has ended, it is necessary to consider this situation when setting the TXVECTOR parameter of the PPDU. An embodiment of the present invention describes a method for setting the TXVECTOR parameter of the PPDU when an AP that is a TXOP holder transmits after the shared TXOP has ended.

[0243] In one embodiment of the present invention, an AP, which is a TXOP holder, can set the parameters of the TXVECTOR of the PPDU that the AP transmits after the shared TXOP ends, based on the last PPDU the AP received. Specifically, the AP, which is a TXOP holder, can set the CH_BANDWIDHT of the TXVECTOR of the PPDU that the AP transmits after the shared TXOP ends, based on the bandwidth of the last PPDU the AP received. In this case, the AP, which is a TXOP holder, can set the CH_BANDWIDHT of the TXVECTOR of the PPDU that the AP transmits after the shared TXOP ends to be the same as or narrower than the bandwidth of the last PPDU the AP received. The AP, which is a TXOP holder, can set the INACTIVE_SUBCHANNELS of the TXVECTOR of the PPDU that the AP transmits after the shared TXOP ends, based on the subchannels occupied by the last PPDU the AP received. At this time, the AP, which is the TXOP holder, can set to 1 the bits in the INACTIVE_SUBCHANNELS of the TXVECTOR of the PPDU that the AP transmits after the shared TXOP ends, specifically the bits corresponding to subchannels not occupied by the last PPDU received by the AP. In one embodiment of the present invention, the AP, which is the TXOP holder, can set the RU_ALLOCATION of the TXVECTOR of the MU PPDU that the AP transmits after the shared TXOP ends, based on the last PPDU that the AP received. Specifically, the AP, which is the TXOP holder, can set the RU_ALLOCATION of the TXVECTOR of the MU PPDU that the AP transmits after the shared TXOP ends, based on the 20MHz subchannel occupied by the last PPDU that the AP received. At this time, the AP, which is the TXOP holder, is not permitted to set the RUs included in the 20MHz subchannel occupied by the last PPDU that the AP received as the RU_ALLOCATION of the TXVECTOR of the MU PPDU that the AP transmits after the shared TXOP ends. In this case, MU PPDU may include at least one of EHT MU PPDU and 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 non-HT duplicate PPDU.

[0245] Another embodiment of setting the TXVECTOR parameters of a PPDU transmitted by an AP after the shared TXOP has ended may apply when an AP that is the TXOP holder replaces a non-HT PPDU that was transmitted to protect the TXOP. For convenience of explanation, the PPDU received as a response to a non-HT PPDU transmitted to protect the TXOP will be called the response non-HT PPDU. Based on the response non-HT PPDU, the AP that is the TXOP holder can set the TXVECTOR parameters of the PPDU that the AP transmits after the shared TXOP has ended. Specifically, the AP that is the TXOP holder can set the CH_BANDWIDHT of the TXVECTOR of the PPDU that the AP transmits after the shared TXOP has ended based on the bandwidth of the response non-HT PPDU. In this case, the AP that is the TXOP holder can set the CH_BANDWIDHT or CH_BANDWIDTH_IN_NON_HT of the TXVECTOR of the PPDU that the AP transmits after the shared TXOP has ended to be the same as or narrower than the bandwidth of the response non-HT PPDU. An AP that is a TXOP holder can set the INACTIVE_SUBCHANNELS of the TXVECTOR of the PPDU that the AP transmits after the shared TXOP ends, based on the subchannel occupied by the response non-HT PPDU. At this time, the AP that is a TXOP holder can set the bits of INACTIVE_SUBCHANNELS in the TXVECTOR of the PPDU that the AP transmits after the shared TXOP ends that correspond to subchannels not occupied by the response non-HT PPDU to 1. In one embodiment of the present invention, an AP that is a TXOP holder can set the RU_ALLOCATION of the TXVECTOR of the MU PPDU that the AP transmits after the shared TXOP ends, based on the response non-HT PPDU. Specifically, the AP that is a TXOP holder can set the RU_ALLOCATION of the TXVECTOR of the MU PPDU that the AP transmits after the shared TXOP ends, based on the 20MHz subchannel occupied by the response non-HT PPDU.In this case, the AP, which is the TXOP holder, is not permitted to set the RU included in the 20MHz 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 either an EHT MU PPDU or an HE MU PPDU. Such an embodiment may apply only when the AP transmits to a station that sent a response non-HT PPDU before the shared TXOP ended, after the shared TXOP has ended.

[0246] Furthermore, TXOP protection using non-HT PPDU transmission may include at least one of the following: RTS frame-to-CTS frame exchange, and MU-RTS frame-to-CTS frame exchange. Also, when TXOP protection using non-HT PPDU uses CTS-to-self frame transmission, as in the embodiment described above, the AP, which is the TXOP holder, can set the TXVECTOR parameters of the PPDU that the AP transmits after the shared TXOP ends, based on the last PPDU the AP received.

[0247] Figures 18 and 19 illustrate, according to an embodiment of the present invention, how an AP, which is a TXOP holder, sets the TXVECTOR parameters of the PPDU that the AP transmits after the shared TXOP has finished.

[0248] In Figure 18(a), the AP obtains a TXOP by sending a CTS-to-Self frame. The AP assigns the shared TXOP to the first station (STA1) by sending a MU-RTS TXS frame. The first station (STA1) sends a UL PPDU to the AP within the shared TXOP. After the shared TXOP ends, the AP sends 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 send to the second station (STA2) based on the last PPDU received. At this time, the last PPDU received by the AP is the PPDU containing the ACK frame sent by the first station (AP). Since the bandwidth of the PPDU containing the ACK frame transmitted by the first station (STA1) is 80MHz, the AP sets the CH_BANDWIDTH of the TXVECTOR of the DL PPDU to be transmitted to the second station (STA2) to 80MHz or a value smaller than 80MHz. Also, since 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 a MU-RTS TXS frame to the first station (STA1) to assign the 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) 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 transmit to the second station (STA2) based on the non-HT PPDU containing the CTS frame. Since the bandwidth of a non-HT PPDU containing a 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 a value of 80 MHz or less. Also, a non-HT PPDU containing a CTS frame does not contain punctured subchannels. Therefore, the AP sets the bits corresponding to the 1st subchannel (SC#1) to the 4th 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 obtains a TXOP by sending a CTS-to-Self frame. The AP sends a MU-RTS TXS frame to the first station (STA1) and assigns the shared TXOP to the first station (STA1). The first station (STA1) sends a P2P PPDU to the second station (STA2) within the shared TXOP. After the shared TXOP ends, the AP sends 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 send 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 sent by the first station (AP). Since the bandwidth of the P2P PPDU transmitted by Station 1 (AP) is 80MHz, AP sets the CH_BANDWIDTH of the TXVECTOR of the DL PPDU to be transmitted to Station 3 (STA3) to 80MHz or a value smaller than 80MHz. Also, since the third subchannel (SC#3) is punctured in the P2P PPDU transmitted by Station 1 (STA1), AP sets the bit corresponding to the third subchannel in the INACTIVE_SUBCHANNEL of the TXVECTOR of the DL PPDU to be transmitted to Station 3 (STA3) to 1.

[0251] In Figure 19(b), the AP transmits MU-RTS frames to stations 1 (STA1) through 3 (STA3) and receives CTS frames from stations 1 (STA1) through 3 (STA3). This allows the AP to acquire a TXOP. The AP transmits a MU-RTS TXS frame to station 1 (STA1) to assign the shared TXOP to station 1 (STA1). Within the shared TXOP, station 1 (STA1) transmits a P2P PPDU to station 2 (STA3). After the shared TXOP ends, the AP transmits a PPDU to station 3 (STA3). At this time, the AP and station 3 (STA3) 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 station 3 (STA3) based on the non-HT PPDU containing the CTS frame. Since the bandwidth of a non-HT PPDU containing a 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 less than 80 MHz. Also, a non-HT PPDU containing a CTS frame does not contain punctured subchannels. Therefore, the AP sets the bits corresponding to the 1st subchannel (SC#1) to the 4th 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 other specific embodiments, restrictions may be applied to the last PPDU transmitted within a shared TXOP. Specifically, the last PPDU transmitted within a TXOP may be restricted to a PPDU containing a frame transmitted by the station to which the shared TXOP is assigned or to which the AP is the intended recipient.

[0253] In yet another specific embodiment, a station assigned to a shared TXOP can signal information about the bandwidth of the last PPDU transmitted within the shared TXOP using the last PPDU transmitted by the station within the shared TXOP. In this case, the last PPDU transmitted by the station within the shared TXOP, or the MAC frame contained within the last PPDU transmitted by the station within the shared TXOP, may include information about the bandwidth of the last PPDU transmitted within the shared TXOP. Furthermore, the information about the bandwidth of the last PPDU transmitted within the TXOP may include at least one of the following: information about the subchannels occupied by the last transmitted PPDU, and information about the subchannels that were punctured in the last transmitted PPDU.

[0254] <How to configure the TXVECTOR of a PPDU when the intended recipient of a PPDU sent within a shared PPDU changes>

[0255] Figure 20 shows a method for configuring the TXVECTOR of a PPDU when the intended recipient of the PPDU transmitted via shared TXOP changes, according to an embodiment of the present invention.

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

[0257] In Fig. 20(b), 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 allowed within the shared TXOP. The first station (STA1) transmits a CTS frame to the AP as a response to the MU-RTS TXS frame. At this time, the CTS frame is transmitted in the 80 MHz frequency band. Before transmitting a P2P PPDU to the second station (STA2), the first station (STA1) transmits an RTS frame 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. Accordingly, the first station (STA1) sets CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT in 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 (STA1) receives an ACK frame in a P2P PPDU from the second station (STA2), and transmits a P2P PPDU to the third station (STA3) in the remaining shared TXOP. The first station (STA1) and the third station (STA3) have never exchanged an RTS frame and a CTS frame. In addition, since the bandwidth of the PPDU including the CTS frame transmitted to the AP is 80 MHz, the first station (STA1) sets CH_BANDWIDTH or CH_BANDWIDTH_IN_NON_HT in 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 TXOP management method>

[0259] An AP can perform TXOP recovery after a shared TXOP has ended. When an AP sends a MU-RTS TXS frame to a station and then receives a CTS frame from the station, the AP can determine that the shared TXOP assignment to the station is complete. The AP may be restricted from sending PPDUs within a shared TXOP. Also, a station to which a shared TXOP has been assigned may not transmit. This is because a station to which a shared TXOP has been assigned may not have any traffic to transmit within the shared TXOP. If a station to which a shared TXOP has been assigned does not transmit within the shared TXOP, the AP can perform TXOP recovery. Specifically, if only UL PPDU transmission is allowed within the shared TXOP, and the channel on which the TXOP was shared is idle in PIFS (SIFS + aSlotTime) after the last PPDU transmission within the shared TXOP, the AP can perform TXOP recovery. At this time, the AP can determine that the shared TXOP has ended. Furthermore, only UL PPDU transmissions are permitted within a shared TXOP, and if the channel on which the TXOP was shared is idle in PIFS (SIFS + aSlotTime) after the last PPDU transmission within the shared TXOP, the AP can start transmitting. These embodiments prevent the loss of the TXOP when no transmission occurs in PIFS.

[0260] Furthermore, after the shared TXOP terminates, the AP can perform TXOP recovery. Specifically, if the channel on which the TXOP was shared is not idle when the shared TXOP terminates, the AP can perform TXOP recovery. In a specific example, if a TXOP remains active when the shared TXOP terminates and the channel on which the TXOP was shared is not idle, the AP can perform TXOP recovery.

[0261] TXOP recovery performed by an AP may involve attempting to transmit a PPDU after the channel has been idle due to PFIS. Alternatively, TXOP recovery performed by an AP may involve performing a new backoff operation. Furthermore, TXOP recovery performed by an AP may involve waiting until the TXNAV timer expires. Such TXOP recovery operations differ from recovery operations performed by a TXOP holder due to PPDU transmission failure in that they are performed even if there is no transmission failure. When a backoff operation is performed during TXOP recovery, the AP may set the CW[AC] value used in the backoff operation to the minimum value of CW[AC]. This is because the transmission of the MU-RTS TXS frame sent for TXOP sharing was successful. Also, when a backoff operation is performed during TXOP recovery, the AP may set the QSRC[AC] value used in the backoff operation to 0.

[0262] Furthermore, when a backoff operation is performed during TXOP recovery, the AP is not permitted to extend 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. Also, when a backoff operation is performed during TXOP recovery, the AP is not permitted 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. When the AP acquires a TXOP through 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 occurred. When the AP does not acquire a TXOP through 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 within the TXOP. If TXOP recovery involves waiting until the TXNAV timer expires, these restrictions do not apply, because the AP acquires a new TXOP after the TXOP has expired.

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

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

[0265] The AP can set the value of the Duration field in a MU-RTS TXS frame to the time until the CTS frame is received from the station to which the shared TXOP is assigned. In a specific example, the AP can set the value of the Duration field in a MU-RTS TXS frame and frames transmitted prior to the MU-RTS TXS frame to the time until the 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, which transmits RTS frames within the shared TXOP, is the TXOP holder. The AP can set the value of the Duration field in a MU-RTS TXS frame to the transmission time of the CTS frame, which is the response to the MU-RTS TXS frame, plus 2xSIFS. In yet another specific example, the AP can set the value of the Duration field in a MU-RTS TXS frame to the transmission time of the CTS frame, plus SIFS. In a specific example, the value of the Duration field can be set before the CTS frame is received from the station to which the TXOP is assigned.

[0266] The embodiments described above and those described below may apply only when P2P PPDU transmission is permitted within a shared TXOP. Furthermore, the embodiments described above may apply only when a TXOP is shared within an R-TWT (restricted target wake time) SP (service period). In this case, the R-TWT SP is a type of TWT SP, which is a service period in which traffic with a TID designated as low-latency traffic by the AP is given priority processing. In this case, 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 the Broadcast TWT Recommendation field value set to 5.

[0267] Furthermore, in other specific embodiments, the embodiments described above and those described later may apply only if the station to which the shared TXOP is assigned signals to the AP that it will protect P2P PPDU transmission by performing RTS frame and CTS frame exchange.

[0268] Furthermore, in other specific embodiments, the embodiments described above and those described below may apply only when the station to which the shared TXOP is assigned reports that it has traffic to send to the P2P peer station. Specifically, the embodiments described above may apply only when the station to which the shared TXOP is assigned reports that it has low-latency traffic to send to the P2P peer station. In this case, the station to which the shared TXOP is assigned can report to the AP that it has traffic to send to the P2P peer station using the PBSR (P2P Buffer Status Report) Control field in the A-Control field of the MAC frame. In this case, the station to which the shared TXOP is assigned indicates the Control ID in the A-Control field as P2P Buffer Status Report Control.

[0269] In the embodiment described above, a neighboring station can determine that the TXOP has ended before the station to which the shared TXOP is assigned sends a non-HT PPDU to protect the transmission of P2P PPDUs. Therefore, a neighboring station may attempt to transmit within the shared TXOP before the transmission of P2P PPDUs begins. This will be explained using Figure 21.

[0270] Figure 21 shows an embodiment of the present invention in which the AP sets the value of the Duration field of the MU-RTS TXS frame by the time it receives the CTS frame for the MU-RTS TXS frame.

[0271] In Figure 21, the AP acquires a TXOP and transmits a MU-RTS TXS frame to a 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. Further, the AP sets the value of the Duration field of the MU-RTS TXS frame to the point in time at which a CTS frame in response to the MU-RTS TXS frame is received. The first station (STA1) transmits an RTS frame to a P2P peer station (P2P peer STA). At this time, a neighboring station (Other STA) that is located near the AP and is a hidden node for the first station (STA1) determines that the TXOP set by the AP has expired. Therefore, while the first station (STA1) is transmitting the RTS frame to the P2P peer station (P2P peer STA), the neighboring station (Other STA) may attempt a new transmission. As a result, the transmission of the P2P PPDU may be interfered with. In consideration of this, an embodiment for 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 within 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 the specific frame within the shared TXOP. At this time, the specific frame may be a frame included in the first UL PPDU transmitted by the station to which the shared TXOP is allocated after transmitting a response to the MU-RTS TXS frame. For convenience of description, the frame included in the first UL PPDU transmitted by the station to which the shared TXOP is allocated after transmitting a response to the MU-RTS TXS frame is referred to as a start frame. In still another specific embodiment, the specific frame may be a response from the AP to the start frame. The Duration fields of the start frame and the response frame may be set to a value equal to or smaller than the end point of the shared TXOP.

[0273] In the foregoing embodiments, in addition to the MU-RTS TXS frame, the AP may set the value of the Duration field of a frame transmitted before the MU-RTS TXS frame based on the transmission of a specific frame within the shared TXOP. When the above-described embodiments related to setting the value of the Duration field are applied, a station to which the shared TXOP is allocated may perform the first frame exchange within the shared TXOP by a pre-configured frame exchange. The station to which the shared TXOP is allocated may determine, based on the value of the Duration field, whether the above-described embodiments related to setting the value of the Duration field are applied. Specifically, when the value of the Duration field is equal to or less than a pre-configured value, the station to which the shared TXOP is allocated may determine that the above-described embodiments related to setting the value of the Duration field are applied. The pre-configured value may represent a value set by the embodiments related to setting the Duration field.

[0274] Specifically, the station to which the shared TXOP is allocated may compare the value of the Duration field with the end point of the shared TXOP, and determine whether the above-described embodiments related to setting the value of the Duration field are applied. In a specific embodiment, when the value of the Duration field is less than the end point of the shared TXOP, the station to which the shared TXOP is allocated may determine that the above-described embodiments related to setting the value of the Duration field are applied. In addition, when the value of the Duration field is equal to or greater than the end point of the shared TXOP, the station to which the shared TXOP is allocated may determine that the above-described embodiments related to setting the value of the Duration field are not applied.

[0275] The aforementioned start frame may be an RTS frame. Furthermore, the UL PPDU containing the start frame may be a PPDU containing only RTS frames. In these embodiments, the RTS frame may be an RTS frame in which the receiver address of the RTS frame is specified as AP. The value of the Duration field of the RTS frame may be set to the end time of the shared TXOP. Furthermore, it is not permitted for the value of the Duration field of the RTS frame to be set to a value greater than the end time of the shared TXOP. The transmission method for a PPDU containing an RTS frame may be specified as follows: A station to which a shared TXOP has been assigned can transmit a PPDU containing 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. Also, the pre-specified MCS may be MCS0 or MCS1. For example, a PPDU containing an 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 MU-RTS TXS frames and frames transmitted prior to the MU-RTS TXS frames to the following values:

[0277] - Transmission time of the CTS frame in response to the MU-RTS TXS frame + 2*SIFS + transmission time of the RTS frame transmitted by the non-AP station. That is, 2*SIFS+CTS+RTS(2*16us+44us(6Mbps CTS)+52us(6Mbps RTS)=128us)

[0278] - Transmission time of the CTS frame in response to the MU-RTS TXS frame + 2 * SIFS + Transmission time of the RTS frame transmitted by the non-AP station + SIFS. That is, 3 * SIFS + CTS + RTS (3 * 16us + 44us (6Mbps CTS) + 52us (6Mbps RTS) = 144us)

[0279] - Transmission time of the CTS frame in response to the MU-RTS TXS frame + 2*SIFS + Transmission time of the RTS frame transmitted by the non-AP station + SIFS + Transmission time of the CTS frame in response by the AP. That is, 3*SIFS + 2*CTS + RTS (3*16us + 2*44us (6Mbps CTS) + 52us (6Mbps RTS) = 188us)

[0280] As mentioned above, the value of the Duration field for MU-RTS TXS frames and frames transmitted before the MU-RTS TXS frame may be set based on the time of transmission 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 for 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 for MU-RTS TXS frames and frames transmitted before the MU-RTS TXS frame as follows:

[0281] - Transmission time of the CTS frame in response to the MU-RTS TXS frame + 2*SIFS + transmission time of the UL PPDU including the start frame transmitted by the non-AP station. That is, 2*SIFS + CTS + UL PPDU including the start frame

[0282] - Transmission time of the CTS frame in response to the MU-RTS TXS frame + 2 * SIFS + Transmission time of the UL PPDU including the start frame transmitted by the non-AP station + SIFS. That is, 3 * SIFS + CTS + UL PPDU including the start frame.

[0283] - Transmission time of the CTS frame in response to the MU-RTS TXS frame + 2 * SIFS + Transmission time of the UL PPDU including the start frame transmitted by the non-AP station + SIFS + Transmission time of the response frame in response by the AP. That is, 3 * SIFS + CTS + UL PPDU including the start frame + Response PPDU

[0284] When a station assigned a shared TXOP attempts to transmit both UL PPDUs and P2P PPDUs within the shared TXOP, the station can transmit the P2P PPDU after transmitting the UL PPDU. This prevents the station from transmitting the UL PPDU and having its P2P PPDU transmission interfered with by neighboring stations. When a station assigned a shared TXOP transmits a P2P PPDU after transmitting a UL PPDU, the restrictions that apply to PPDU transmissions including the start frame, as described above, do not apply. In these embodiments, the station assigned a shared TXOP can complete the UL PPDU transmission including the start frame within the time indicated by the value of the Duration field of the MU-RTS TXS frame and the frames transmitted prior to 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. A P2P peer station can determine that the AP has terminated the TXOP, for which it is the TXOP holder, before receiving an RTS frame, and then send a CTS frame, which is a response to the RTS frame.

[0285] If the AP sets the value of the Duration field as in the embodiment described above, the AP can send a frame for TXOP protection after the shared TXOP has finished. In this case, the frame for TXOP protection may include at least one of a 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 frame for TXOP protection, the sum of the time used before sending the MU-RTS TXS frame and the duration of the shared TXOP, so as not to exceed the TXOP limit.

[0286] Figure 22 shows an embodiment of the present invention in which the AP sets the value of the Duration field of the MU-RTS TXS frame based on the start frame.

[0287] In Figure 22, the AP sends a MU-RTS TXS frame to assign the shared TXOP to the station (non-AP STA). The AP sets the value of the DL PPDU and the Duration field of the MU-RTS TXS frame, which are sent before the MU-RTS TXS frame is sent, to be the same as or longer than the time the station (non-AP STA) first sends the UL PPDU within the shared TXOP. The AP sends a response to the UL PPDU. The neighboring station that receives the response to the UL PPDU sets the NAV based on the response. As a result, when a P2P peer station (P2P Peer STA) receives an RTS frame sent 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) sends a CTS frame to the station (non-AP STA) as a response to the RTS frame.

[0288] In yet another specific embodiment, a station assigned a shared TXOP can set the sender address, i.e., the TA field, of the RTS frame to protect the transmission of P2P PPDUs to the MAC address of the AP that configured the shared TXOP. Since the sender address points to the AP that is the TXOP holder, a P2P peer station that receives an RTS frame can send a CTS frame as a response to the RTS frame. This allows the TXOP for P2P PPDUs to be configured without changing the value of the Duration field of the MU-RTS TXS frame or the frame sent before the MU-RTS TXS frame, as in the embodiment described with Figure 22. When a station assigned a shared TXOP receives a CTS frame from a P2P peer station, the station assigned the shared TXOP can act as if the station assigned the shared TXOP and the P2P peer station had exchanged RTS and CTS frames. Therefore, when a station assigned a shared TXOP transmits a P2P PPDU, the station assigned the shared TXOP can apply the frequency bandwidth rules that apply after the RTS and CTS frame exchange. A station to which a shared TXOP is assigned can operate in this manner when the recipient address of the CTS frame, i.e., the RA field, is the same as the recipient address of the AP that configured the shared TXOP. In yet another specific embodiment, a station to which a shared TXOP is assigned can operate in this manner when the recipient address of the CTS frame, i.e., the RA field, is the same as the sender address of the station to which the shared TXOP is assigned, i.e., the TA field.

[0289] Furthermore, when a station assigned to a shared TXOP sends 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 configured the shared TXOP.

[0290] Figure 23 shows that, according to one embodiment of the present invention, a station to which a shared TXOP is assigned transmits an RTS frame in which the sender address is set as the AP that configured the shared TXOP.

[0291] In Figure 23, the AP sends a MU-RTS TXS frame to assign a shared TXOP to a station (non-AP STA). Within the shared TXOP, the station (non-AP STA) sends an RTS frame to a P2P peer station (P2P Peer STA) with the sender address set to AP. Since the P2P peer station (P2P Peer STA) receives the RTS frame with the sender address AP, it sends a CTS frame to the AP. At this time, the station (non-AP STA) receives the CTS frame and can operate as if it has received a CTS frame whose recipient address points to the station (non-AP STA). The Duration field value of the MU-RTS TXS frame and frames sent before the MU-RTS TXS frame is set to the interval containing the shared TXOP. Therefore, stations that are hidden nodes for stations (non-AP STA) in the BSS operated by the AP will not attempt to send within the shared TXOP.

[0292] Although the present invention has been described using wireless LAN communication as an example, it is not limited to this and may be applied similarly to other communication systems such as cellular communication. Furthermore, although the methods, apparatus, and systems of the present invention have been described in relation to 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 and the like described in the above embodiments are included in at least one embodiment of the present invention, and are not necessarily limited to a single embodiment. It should be noted that the features, structures, effects and the like exemplified in each embodiment can be combined or modified for implementation with other embodiments by a person having ordinary knowledge in the field to which the embodiments pertain. Accordingly, contents related to such combinations and modifications should be construed as being included in the scope of the present invention.

[0294] While the foregoing description has centered on the embodiments, this is merely an example and does not limit the present invention. Therefore, a person having ordinary knowledge in the field to which the present invention pertains will appreciate that various modifications and applications not exemplified above are possible without departing from the essential characteristics of the present embodiment. For example, each component specifically shown in the embodiments may be modified and implemented. Furthermore, differences related to such modifications and applications should be construed as falling within the scope of the present invention as defined in the appended claims. [Description of Reference Numerals]

[0295] 110 Processor 120 Communication Unit 140 User Interface Unit 150 Display Unit 160 Memory 210 Processor 220 Communication Unit 260 Memory

Claims

1. A non-AP station for communicating with an AP (access point), Transmitting and receiving unit; and Including the processor, The aforementioned processor, Using the transmitting / receiving unit, the AP receives a first PPDU (physical layer protocol data unit) including a MU-RTS (multi-user-request to send) TXS (TXOP (transmit opportunity) sharing) trigger frame, 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 aforementioned transmitting / receiving unit, a second PPDU including a CTS (clear to send) frame is transmitted to the AP as a response to the MU-RTS TXS trigger frame. Based on the disabled subchannel and the last specified subchannel, the AP transmits the third PPDU within the shared TXOP using the transmitting / receiving unit with a bandwidth equal to or narrower than the bandwidth of the second PPDU. The third PPDU is a non-AP station, which is a P2P PPDU transmitted to a P2P (peer-to-peer) peer station of the non-AP station.

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

3. The non-AP station according to claim 1, wherein the processor sets to 1 the bit of the INACTIVE_SUBCHANNELS parameter of the TXVECTOR of the third PPDU that corresponds to the subchannel that the AP last designated as a disabled subchannel.

4. The non-AP station according to claim 1, wherein the processor sets parameters relating to the frequency band of the third PPDU based on whether or not a non-HT (non-high throughput) PPDU exchange was performed in the shared TXOP before the transmission of the third PPDU.

5. The parameters relating to the frequency band include the CH_BANDWIDTH parameter of TXVECTOR, The aforementioned processor, If the non-HT PPDU exchange occurs in the shared TXOP before the transmission of the third PPDU, the CH_BANDWIDTH_IN_NON_HT parameter of the TXVECTOR of the third PPDU is set to be the same as or narrower than the CH_BANDWIDTH_IN_NON_HT parameter of the RXVECTOR of the non-HT PPDU received before the transmission of the third PPDU, The non-AP station according to claim 4, wherein, in the shared TXOP, if non-HT PPDU exchange has not been performed before the transmission of the third PPDU, the CH_BANDWIDTH parameter or CH_BANDWIDTH_IN_NON_HT parameter of the TXVECTOR of the second PPDU is set to be the same as or narrower than the CH_BANDWIDTH parameter or CH_BANDWIDTH_IN_NON_HT parameter of the TXVECTOR of the third PPDU.

6. The non-AP station according to claim 4, wherein in the shared TXOP, prior to the transmission of the third PPDU, the non-HT PPDU exchange is an exchange of a non-HT PPDU containing an RTS frame and a non-HT PPDU containing a CTS frame.

7. The non-AP station according to claim 1, wherein the value of the Duration field of the MU-RTS TXS trigger frame is set based on the transmission time of the second PPDU.

8. The non-AP station according to claim 1, wherein the processor transmits an RTS frame to the P2P peer station before transmitting the third PPDU.

9. A method for operating a non-AP station to communicate with an AP (access point), The AP receives a first PPDU (physical layer protocol data unit) including a MU-RTS (multi-user-request to send) TXS (TXOP (transmit opportunity) sharing) trigger frame, 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; The steps include: transmitting a second PPDU, including a CTS (clear to send) frame, to the AP in response to the MU-RTS TXS trigger frame; and The AP includes the step of transmitting a third PPDU within the shared TXOP with the same or narrower bandwidth as the second PPDU, based on the disabled subchannel and the last specified subchannel. The operation method wherein the third PPDU is a P2P PPDU transmitted to the P2P (peer-to-peer) peer station of the non-AP station.

10. The operation method according to claim 9, wherein the step of transmitting the third PPDU with the same or narrower bandwidth as the second PPDU includes the step of setting the CH_BANDWIDTH parameter or CH_BANDWIDTH_IN_NON_HT parameter of the TXVECTOR of the third PPDU to the same or narrower value as the CH_BANDWIDTH parameter of the TXVECTOR of the second PPDU.

11. The operation method according to claim 9, wherein the step of the AP transmitting the third PPDU based on the disabled subchannel and the last specified subchannel includes setting to 1 the bits of the INACTIVE_SUBCHANNELS parameter of the TXVECTOR of the third PPDU that correspond to the disabled subchannel and the last specified subchannel by the AP.

12. The operation method according to claim 9, wherein the step of transmitting a third PPDU within the shared TXOP includes the step of setting parameters relating to the frequency band of the third PPDU based on whether or not a non-HT (non-high throughput) PPDU exchange was performed in the shared TXOP prior to the transmission of the third PPDU.

13. The parameters relating to the frequency band include the CH_BANDWIDTH parameter of TXVECTOR, The step of setting parameters relating to the frequency band of the third PPDU based on whether or not a non-HT PPDU exchange occurred in the shared TXOP before the transmission of the third PPDU is, If the non-HT PPDU exchange occurred in the shared TXOP before the transmission of the third PPDU, the steps include setting the CH_BANDWIDTH parameter or CH_BANDWIDTH_IN_NON_HT parameter of the TXVECTOR of the third PPDU to be the same as or narrower than the CH_BANDWIDTH_IN_NON_HT parameter of the RXVECTOR of the non-HT PPDU received before the transmission of the third PPDU, The operation method according to claim 12, further comprising the step of setting the CH_BANDWIDTH parameter or CH_BANDWIDTH_IN_NON_HT parameter of the TXVECTOR of the third PPDU to the same or narrower bandwidth as the CH_BANDWIDTH parameter or CH_BANDWIDTH_IN_NON_HT parameter of the TXVECTOR of the second PPDU, if a non-HT PPDU exchange has not been performed in the shared TXOP prior to the transmission of the third PPDU.

14. The operation method according to claim 12, wherein in the shared TXOP, the non-HT PPDU exchange prior to the transmission of the third PPDU is an exchange of a non-HT PPDU containing an RTS frame and a non-HT PPDU containing a CTS frame.

Images