Wireless communication method using multi-link and wireless communication terminal using the same

Abstract

To provide a method and a device for transmitting and receiving data through setting of a transmission opportunity (TXOP) in a multi-link operation.SOLUTION: A station (STA) in a wireless communication system receives a trigger frame from an AP (Access Point), the trigger frame being used to share, with the STA, a specific time which is a part or all of a transmission opportunity (TXOP) obtained by the AP; on the basis of the trigger frame, transmits a frame including duration information to the AP and / or another STA within the specific time. When a NAV (network allocation vector) and a NAV timeout indicating an end of the NAV are set based on the trigger frame, the NAV is not canceled even after the NAV timeout expires within the specific time.SELECTED DRAWING: Figure 29

Description

[Technical Field]

[0001] The present invention relates to a wireless communication method using multilink and a wireless communication terminal using the same, and more particularly to a method and terminal for setting a TXOP and transmitting and receiving data. [Background technology]

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

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

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

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

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

[0007] Additionally, development of new WLAN standards has begun to increase maximum transmission speeds to support new multimedia applications such as high-definition video and real-time gaming. IEEE 802.11be (Extremely High Throughput, EHT), the seventh generation WLAN standard, is currently under development with the goal of supporting transmission rates of up to 30 Gbps through wider bandwidth in the 2.4 / 5 / 6 GHz bands, increased spatial streams, and multi-AP cooperation. IEEE 802.11be proposes technologies such as a 320 MHz bandwidth, multi-link operation, multi-AP (multi-access point) operation, and hybrid automatic repeat request (HARQ) retransmission.

[0008] Multi-link operation operates in various forms depending on its operation method and implementation method. In this case, problems that did not occur in conventional IEEE 802.11-based WLAN communication operations may occur, so a detailed definition of the operation method for multi-link operation is required.

[0009] On the other hand, the art that forms the background of the invention is created to enhance understanding of the background of the invention and includes content that is not prior art already known to those with ordinary skill in the field to which this technology belongs. Summary of the Invention [Problem to be solved by the invention]

[0010] SUMMARY OF THE INVENTION An object of the present invention is to provide a method and apparatus for transmitting and receiving data using transmission opportunity (TXOP) setting in a multi-link operation.

[0011] Another object of the present invention is to provide a method and apparatus for allowing a non-AP STA to transmit and receive data by sharing a TXOP set by an AP (Access Point) with the non-AP STA.

[0012] Another object of the present invention is to provide a method and apparatus for setting a network allocation vector (NAV) for non-AP STAs to transmit and receive data within a shared TXOP.

[0013] The technical problems to be solved in this specification are not limited to those mentioned above, and other technical problems not mentioned will be clearly understood by those having ordinary skill in the art to which the present invention pertains from the following description. [Means for solving the problem]

[0014] A station (STA) of a wireless communication system includes a transceiver unit; and a processor that controls the transceiver unit. The processor receives a trigger frame from an access point (AP) that instructs uplink transmission, the trigger frame is used to share some or all of a transmission opportunity (TXOP) obtained by the AP with the STA, and transmits a physical layer protocol data unit (PPDU) to the AP and / or other STAs within the shared TXOP based on the trigger frame. The PPDU includes duration information that instructs a TXOP for transmitting the PPDU, and the duration information is set based on the shared TXOP.

[0015] In addition, in the present invention, the end point of the duration indicated by the duration information is the same as the end point of the shared TXOP.

[0016] Also, in the present invention, the duration indicated by the duration information ends before the end of the shared TXOP.

[0017] Also, in the present invention, if a network allocation vector (NAV) is set by a frame transmitted by the AP in the TXOP, the PPDU is transmitted regardless of the set NAV in the shared TXOP.

[0018] In addition, in the present invention, if a NAV and a NAV timeout period indicating the end time of the NAV are set within the shared TXOP by another STA based on the trigger frame, even if the NAV timeout period expires within the shared TXOP, the NAV set by the other STA within the shared TXOP will not be released due to the expiration of the NAV timeout period.

[0019] In addition, in the present invention, the trigger frame includes a subfield indicating whether or not the TXOP is shared by the trigger frame.

[0020] Also, in the present invention, when the subfield indicates the sharing of the TXOP, the value of the subfield indicates whether transmission and reception with the other STA is possible within the shared TXOP.

[0021] In addition, in the present invention, the trigger frame includes a type field indicating the type of the trigger frame, and the sharing of the part or all of the TXOP is set according to the type of the trigger frame according to the type field.

[0022] The present invention also provides a method including: a step of receiving a trigger frame instructing uplink transmission from an AP (Access Point), the trigger frame being used to share some or all of a transmission opportunity (TXOP) obtained by the AP with the STA; and a step of transmitting a PPDU (Physical layer Protocol Data Unit) to the AP and / or other STAs in the shared TXOP based on the trigger frame, the PPDU including duration information instructing a TXOP for transmission of the PPDU, and the duration information being set based on the shared TXOP. [Effects of the Invention]

[0023] According to one embodiment of the present invention, the TXOP set by the AP is shared with the non-AP STAs, thereby enabling the non-AP STAs to transmit and receive data efficiently.

[0024] In addition, according to one embodiment of the present invention, the NAV for a non-AP STA to send and receive data within a shared TXOP is set based on the shared TXOP, or the set NAV is interpreted by the shared TXOP, thereby enabling efficient data transmission.

[0025] The effects obtained from the present invention are not limited to those mentioned above, and other effects not mentioned will be clearly understood by those having ordinary skill in the art to which the present invention pertains from the following description. [Brief explanation of the drawings]

[0026] [Figure 1] 1 is a diagram showing a wireless LAN system according to an embodiment of the present invention. [Figure 2] FIG. 10 is a diagram showing a wireless LAN system according to another embodiment of the present invention. [Figure 3]FIG. 2 is a diagram showing the configuration of a station according to an embodiment of the present invention. [Figure 4] FIG. 2 is a diagram illustrating a configuration of an access point according to an embodiment of the present invention. [Figure 5] 1 is a diagram illustrating a process in which a STA establishes a link with an AP. [Figure 6] FIG. 1 is a diagram illustrating a CSMA (Carrier Sense Multiple Access) / CA (Collision Avoidance) method used in wireless LAN communication. [Figure 7] 1A and 1B are diagrams illustrating examples of various standard generation PPDU (PLCP Protocol Data Unit) formats. [Figure 8] 1A and 1B are diagrams illustrating examples of various EHT (Extremely High Throughput) PPDU (Physical Protocol Data Unit) formats and methods for indicating the same according to an embodiment of the present invention. [Figure 9] 1 is a diagram illustrating a multi-link device according to an embodiment of the present invention. [Figure 10] FIG. 10 is a diagram illustrating an example of a TID-to-link mapping method according to one embodiment of the present invention. [Figure 11] FIG. 10 is a diagram illustrating an example of a multi-link NAV setting operation according to one embodiment of the present invention. [Figure 12] FIG. 10 is a diagram illustrating yet another example of a multi-link NAV setting operation according to one embodiment of the present invention. [Figure 13] FIG. 1 is a diagram illustrating an example of BSS classification and operations based thereon according to an embodiment of the present invention. [Figure 14] FIG. 2 is a diagram illustrating a wireless LAN function according to an embodiment of the present invention. [Figure 15] FIG. 2 is a diagram illustrating an uplink (UL) multi-user (MU) operation according to one embodiment of the present invention. [Figure 16] FIG. 1 is a diagram illustrating a trigger frame format according to one embodiment of the present invention. [Figure 17] A diagram showing a method for indicating a trigger-based PPDU format according to one embodiment of the present invention. [Figure 18] FIG. 10 is a diagram illustrating an example of UL MU operation according to one embodiment of the present invention. [Figure 19] A diagram showing a method for sharing a TXOP according to one embodiment of the present invention. [Figure 20] A diagram illustrating a method related to TXOP sharing and NAV setting in one embodiment of the present invention. [Figure 21] A diagram showing TXOP sharing and CTS frame transmission in one embodiment of the present invention. [Figure 22] A figure showing an example of a trigger frame for sharing a TXOP in one embodiment of the present invention. [Figure 23] FIG. 10 is a diagram illustrating a NAV time out according to one embodiment of the present invention. [Figure 24] A diagram illustrating TXOP sharing and NAV timeout in one embodiment of the present invention. [Figure 25] A diagram showing TXOP sharing and NAV timeout in yet another embodiment of the present invention. [Figure 26] A diagram showing TXOP sharing and NAV timeout in yet another embodiment of the present invention. [Figure 27] A diagram showing that a STA and an AP apply NAV when TXOP sharing is applied according to one embodiment of the present invention. [Figure 28] A diagram showing a STA ending TXOP sharing according to one embodiment of the present invention. [Figure 29] 10 is a flowchart illustrating an example of the operation of an STA according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

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

[0028] Throughout this specification, when a component is referred to as being "connected" to another component, this includes not only when the component is "directly connected" to the other component, but also when the component is "electrically connected" to the other component via another component therebetween. Furthermore, when a component is referred to as "comprising" a specific component, this does not mean that the component excludes the other component, but that the component may further include the other component, unless otherwise specified. Additionally, limitations such as "greater than" or "less than" based on a specific critical value may be appropriately substituted with "exceeds" or "less than," respectively, depending on the embodiment. Hereinafter, in the present invention, the terms "field" and "subfield" may be used interchangeably.

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

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

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

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

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

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

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

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

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

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

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

[0040] Next, the display unit 150 outputs an image on a display screen. The display unit 150 outputs various display objects, such as content generated by the processor 110 or a user interface based on a control command from the processor 110. The memory 160 also stores control programs and various data used by the station 100. Such control programs include a connection program required for the station 100 to connect to an AP or an external station.

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

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

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

[0044] Referring to FIG. 4, the AP 200 according to the present invention includes a communication unit 220 for operating a BSS in at least one frequency band. As described above in the embodiment of FIG. 3, the communication unit 220 of the AP 200 may also include multiple communication modules using different frequency bands. That is, the AP 200 according to the embodiment of the present invention may include two or more communication modules using different frequency bands, for example, 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz. Preferably, the AP 200 may include a communication module using a frequency band above 7.125 GHz and a communication module using a frequency band below 7.125 GHz. Each communication module may perform wireless communication with a station based on the WLAN standard of the frequency band supported by the communication module. The communication unit 220 may operate only one communication module at a time or multiple communication modules simultaneously, depending on the performance and requirements of the AP 200. In the embodiment of the present invention, the communication unit 220 may represent an RF (Radio Frequency) communication module that processes RF signals.

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

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

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

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

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

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

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

[0052] If the channel is determined to be idle, each terminal with data to transmit performs a backoff procedure after an Inter Frame Space (IFS), such as an Arbitration IFS (AIFS) or a PCF IFS (PIFS), depending on the status of each terminal. In some embodiments, the AIFS is used as a configuration replacing the conventional DCF IFS (DIFS). Each terminal waits while decreasing a slot time by a random number determined for the corresponding terminal during the idle interval of the channel, and a terminal that has exhausted all slot times attempts to access the corresponding channel. The period during which each terminal performs the backoff procedure is called a contention window period.

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

[0054] Hereinafter, in the present invention, a terminal may be referred to as a non-AP STA, an AP STA, an AP, an STA, a receiving device, or a transmitting device, and the present invention is not limited thereto. Also, in the present invention, an AP STA may be referred to as an AP.

[0055] <Examples of various PPDU formats>

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

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

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

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

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

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

[0062] The unit of the L_LENGTH field is bytes, and a total of 12 bits are allocated, allowing a maximum of 4095 to be signaled. In combination with the L_RATE field, it can indicate the length of the corresponding PPDU. In this case, legacy and non-legacy terminals can interpret the L_LENGTH field in different ways.

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

[0064]

number

number

[0065]

number

[0066] Here, TXTIME is the total transmission time constituting the PPDU, and is expressed as the following equation 3. In this case, TX represents the transmission time of X.

[0067]

number

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

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

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

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

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

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

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

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

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

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

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

[0079] In addition, one embodiment of the present invention proposes a method of varying the PPDU configuration indicated by the preamble puncturing BW value according to the PPDU format signaled in the PPDU format field. Assuming the length of the BW field is 4 bits, in the case of an EHT SU PPDU or TB PPDU, an EHT-SIG-A symbol of one symbol may be further signaled after the U-SIG, or no EHT-SIG-A may be signaled at all. Taking this into consideration, up to 11 puncturing modes must be signaled using only the BW field of the U-SIG. However, in the case of an EHT MU PPDU, an EHT-SIG-B symbol is further signaled after the U-SIG, so up to 11 puncturing modes may be signaled in a different manner than in the SU PPDU. In the case of an EHT ER PPDU, the BW field can be set to 1 bit to signal whether the PPDU uses a 20 MHz or 10 MHz bandwidth.

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

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

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

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

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

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

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

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

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

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

[0090] Two or more PPDUs shown in FIG. 8 can be indicated by a value indicating the same PPDU format. That is, two or more PPDUs can be indicated as the same PPDU format by the same value. For example, an EHT SU PPDU and an EHT MU PPDU can be indicated by the same value using the U-SIG PPDU format subfield. In this case, the EHT SU PPDU and the EHT MU PPDU can be distinguished depending on the number of STAs receiving the PPDU. For example, a PPDU received by only one STA may be identified as an EHT SU PPDU, and when the number of STAs is set so that two or more STAs can receive the PPDU, it may be identified as an EHT MU PPDU. In other words, two or more PPDU formats shown in FIG. 8 can be indicated using the same subfield value.

[0091] In addition, some of the fields or some information of the fields shown in Figure 8 may be omitted, and such a case where some of the fields or some information of the fields is omitted can be defined as a compression mode or a compressed mode.

[0092] FIG. 9 is a diagram illustrating a multi-link device according to an embodiment of the present invention.

[0093] Referring to FIG. 9, the concept of a device to which one or more STAs are affiliated may be defined. As another example, according to an embodiment of the present invention, a device to which more than one STA (i.e., two or more) is affiliated may be defined. In this case, a device may be a logical concept. Therefore, such a device to which one or more STAs are affiliated may be referred to as a multi-link device (MLD), a multi-band device, or a multi-link logical entity (MLLE).

[0094] Alternatively, the above conceptual device can be called a multi-link entity (MLE). Also, an MLD may have one MAC medium access control service access point (SAP) to a logical link control (LLC), and an MLD may have one MAC data service.

[0095] A STA included in an MLD can operate on one or more links or channels. That is, a STA included in an MLD can operate on multiple different channels. For example, a STA included in an MLD can operate using channels in different frequency bands, such as 2.4 GHz, 5 GHz, and 6 GHz. This allows MLD to gain benefits in channel access and improve overall network performance. While existing WLANs operate on a single link, MLD operation can use multiple links to obtain more channel access opportunities, or allow STAs to operate efficiently on multiple links taking into account channel conditions.

[0096] Also, if the STA affiliated with the MLD is an AP, the MLD to which the AP is affiliated may be an AP MLD, but if the STA affiliated with the MLD is a non-AP STA, the MLD to which the non-AP is affiliated may be a non-AP MLD.

[0097] An AP MLD (Multi-link Device) may be a device including one or more wireless access points (APs) and connected to a higher layer via one interface. That is, the AP MLD may be connected to the LLC (Logical Link Control) layer via one interface. Multiple APs included in the AP MLD may share some functions in the MAC layer. Each AP in the AP MLD may operate on a separate link. An STA MLD may be a device including one or more non-AP STAs and connected to a higher layer via one interface.

[0098] That is, the STA MLD may be connected to the LLC layer via one interface. Multiple STAs included in the STA MLD may share some functions at the MAC layer. The STA MLD may also be called a non-AP MLD. The AP MLD and STA MLD can perform multi-link operation, communicating using multiple individual links. That is, if the AP MLD includes multiple APs, each AP can configure a separate link and transmit and receive frames using multiple links with each UE included in the STA MLD. Each link can operate in the 2.4 GHz, 5 GHz, or 6 GHz band, and each link can perform bandwidth extension. For example, if the AP MLD configures one link in the 2.4 GHz band and two links in the 5 GHz band, the 2.4 GHz band can transmit frames at a bandwidth of 40 MHz using the bandwidth extension method, and each link using the 5 GHz band can transmit frames at a maximum bandwidth of 320 MHz using discontinuous bandwidth.

[0099] Meanwhile, due to interference issues within the device, the AP MLD or STA MLD may prevent one terminal in the MLD from receiving while another terminal is transmitting. This operation, in which one AP or terminal in the MLD receives while another AP or terminal in the MLD is transmitting, is called STR (Simultaneous Transmit and Receive). The AP MLD is capable of STR operation for all links. Alternatively, STR operation is not possible for some links of the AP MLD. An STR-capable terminal MLD may be connected to an AP MLD, or an STR-incapable MLD may be connected to some or all links. Furthermore, an AP included in an AP MLD may also be connected to terminals (e.g., IEEE 802.11a / b / g / n / ac / ax terminals) that do not belong to the MLD.

[0100] The AP MLD and the STA MLD may perform a negotiation process for a multiple link usage operation during the scanning and connection process described in FIG. 5. For example, during the scanning process described in FIG. 5, an AP included in the AP MLD may transmit a beacon frame including an indicator indicating that a multiple link operation is available, the number of available links, and information on the number of available links. Alternatively, a terminal belonging to the STA MLD may transmit a probe request frame including an indicator indicating that a multiple link operation is available, and an AP belonging to the AP MLD may transmit a probe response frame including an indicator indicating that a multiple link operation is available. In this case, the AP may further transmit the number of available links, link information, etc. during the multiple link operation.

[0101] The STA MLD, which has confirmed whether the AP MLD performs a multi-link operation and the link information to be used during the scanning process, can perform a connection process with the AP MLD. At this time, the AP MLD and the STA MLD can start a negotiation process for the multi-link operation. At this time, the negotiation process for the multi-link operation can be performed during a connection process between an AP belonging to the AP MLD and a terminal belonging to the STA MLD. That is, a terminal (e.g., STA1) belonging to the STA MLD can send a connection request frame to an AP (e.g., AP1) belonging to the AP MLD, and can send an indicator indicating that the terminal's multi-link operation is available and a request indicator requesting the terminal to perform the multi-link operation. The AP receiving the connection request frame from the terminal can check the indicator requesting the multi-link operation, and if the AP is capable of the multi-link operation, can send a connection response frame to the terminal that allows the multi-link operation, including link information to be used for the multi-link operation and parameters used for each link. The parameters for the multi-link operation may include one or more of the bandwidth of each link to be used, a bandwidth expansion direction, a Target Beacon Transmission Time (TBTT), and whether or not to perform STR operation. After the connection process, the AP MLD and the STA MLD, which have confirmed the use of the multi-link operation by exchanging the connection request frame and the response frame, can perform a frame transmission operation on multiple links via multiple APs included in the AP MLD and multiple UEs included in the STA MLD.

[0102] 9, there may be an MLD including multiple STAs, and the multiple STAs included in the MLD may operate on multiple links. In FIG. 9, an MLD including APs AP1, AP2, and AP3 may be called an AP MLD, and an MLD including non-AP STAs non-AP STA1, non-AP STA2, and non-AP STA3 may be called a non-AP MLD. The STAs included in the MLD may operate on Link 1, Link 2, Link 3, or some of Links 1 to 3.

[0103] According to an embodiment of the present invention, a multi-link operation may include a multi-link setup operation. The multi-link setup operation may be an operation corresponding to an association performed in a single-link operation. In order to exchange frames over multiple links, multi-link setup must be performed first. The multi-link setup operation may be performed using a multi-link setup element. Here, the multi-link setup element may include capability information related to multiple links. The capability information may include information on whether a STA included in the MLD can receive frames over one link while another STA included in the MLD can transmit frames over another link. That is, the capability information may include information on whether a STA (non-AP STA) and / or an AP (or AP STA) can simultaneously transmit / receive frames in different transmission directions through links included in the MLD. The capability information may also include information on available links or operating channels. The multi-link setup may be set up through negotiation between peer STAs, and a multi-link operation may be set up over a single link.

[0104] According to one embodiment of the present invention, a mapping relationship may exist between a TID and an MLD link. For example, when a TID and a link are mapped, the TID may be transmitted on the mapped link. The mapping between a TID and a link may be direction-based. For example, a mapping may be performed for each direction between MLD1 and MLD2. Also, a default setting may exist for the mapping between a TID and a link. For example, the mapping between a TID and a link may basically be such that all TIDs are mapped to a certain link.

[0105] FIG. 10 is a diagram illustrating an example of a TID-to-link mapping method according to an embodiment of the present invention.

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

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

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

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

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

[0111] According to one embodiment of the present invention, a TID may be mapped to each link of a multi-link. For example, there may be a mapping of which link among multiple links a specific TID or a specific AC is allowed to transmit or receive on. Such mapping may be defined separately for each direction of the link. As described above, a default setting may exist for the mapping between TIDs and links. For example, the mapping between TIDs and links may basically map all TIDs to a certain link. According to one embodiment, at a specific time, a certain TID or a certain AC may be mapped to at least one link. Furthermore, management frames or control frames may be transmitted on all links.

[0112] In the present invention, data frames corresponding to TIDs or ACs that are mapped to either direction of the link may be transmitted, and data frames corresponding to TIDs or ACs that are not mapped to either direction of the link may not be transmitted.

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

[0114] TID-to-link mapping can provide QoS services. For example, by mapping a high-priority AC and TID to a link with good channel conditions or few STAs, data for that AC and TID can be transmitted quickly. Alternatively, TID-to-link mapping can help STAs on a specific link save power (or enter a doze state).

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

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

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

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

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

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

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

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

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

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

[0125] Using a separate inter-link NAV may have advantages over not using an inter-link NAV in situations where the NAV setting is updated. For example, situations may arise where it is acceptable to reset the NAV set by another link. For example, if an inter-link NAV is set based on a certain frame (or PPDU), but it is determined that the frame (or PPDU) is not destined for the same MLD, it may be acceptable to reset the set inter-link NAV. Suppose there is an MLD operating on link 1 and link 2, the NAV for link 1 may be set based on a frame received on link 1. Then, the NAV for link 1 may be updated based on a frame received on link 2. If the NAV for link 2 no longer needs to be maintained, resetting the NAV for link 1 would result in the loss of the NAV information set based on the frame received on link 1. If the inter-link NAV were used together with the NAV for each link, the NAV for each link would be maintained even if the inter-link NAV was reset, thereby resolving the above problem.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0149] The corresponding BSS may include a BSS associated with the STA. The corresponding BSS may also include a BSS included in the same multiple BSSID set as the BSS associated with the STA. The corresponding BSS may also include a BSS included in the same co-hosted BSSID set as the BSS associated with the STA. For one or more BSSs included in the same multiple BSSID set or the same co-hosted BSSID set, information about the one or more BSSs may be transmitted via one frame.

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

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

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

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

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

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

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

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

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

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

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

[0161] STA4 receives the PPDU transmitted by STA1 and can classify the BSS for this PPDU. Also, because STA4 and STA1 belong to BSS B and BSS A, respectively, the PPDU received by STA4 may be classified as an inter-BSS PPDU. Furthermore, the signal strength of the PPDU received by STA4 may be lower than a threshold. Therefore, since the PPDU received by STA4 is classified as an inter-BSS PPDU and the signal strength of the PPDU received by STA4 is lower than a threshold, STA4 can perform spatial reuse. Therefore, STA4 can perform channel access and backoff procedures and begin transmission. For example, STA4 can begin transmission before the PPDU transmitted by STA1 has finished.

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

[0163] According to an embodiment of the present invention, a STA conforming to a certain WLAN standard may include the functionality of a previous WLAN standard. This is for backward compatibility. For example, a STA supporting a specific WLAN standard may support the functionality of a previous generation WLAN standard and also support newer functionality. For example, an HT STA may support the basic functionality of an OFDM PHY STA. Therefore, an HT STA may be classified as an OFDM PHY STA. An HT STA may also support additional functionality that an OFDM PHY STA does not support in addition to the functionality of an OFDM PHY STA. A VHT STA may support the basic functionality of an HT STA and also support functionality that an HT STA does not support. A VHT STA may be classified as an HT STA. An HE STA may also support the basic functionality of a VHT STA and also support functionality that a VHT STA does not support. An HE STA may also be classified as a VHT STA. An EHT STA may also be an HE STA. An EHT STA may also support the basic functionality of an HE STA and also support functionality that an HE STA does not support. Furthermore, an EHT STA may be classified as an HE STA. Furthermore, a new WLAN standard may be defined after the EHT standard. In the present invention, a standard after the EHT standard is called a NEXT standard, and an STA that complies with the NEXT standard is called a NEXT STA. A NEXT STA supports the basic functions of an EHT STA and can also support functions that an EHT STA does not support. A NEXT STA may be classified as an EHT STA.

[0164] Figure 14 is a diagram showing the relationship between STAs supporting each WLAN standard. Referring to Figure 14, an EHT STA may be an HE STA, a VHT STA, an HT STA, or an OFDM PHY STA. Also, a NEXT STA may be an EHT STA, an HE STA, a VHT STA, an HT STA, or an OFDM PHY STA.

[0165] FIG. 15 illustrates an uplink (UL) multi-user (MU) operation according to one embodiment of the present invention.

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

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

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

[0169] The triggering frame may contain information necessary for TB PPDU transmission. b and the value of the subtype subfield (B7 B6 B5 B4) is 0010 b If so, it may indicate that it is a MAC frame trigger frame.

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

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

[0172] In the embodiment of FIG. 15, an AP transmits a trigger frame that schedules transmissions of an HE STA (HE STA) and an EHT STA (EHT STA). At this time, if the trigger frame does not specify the format of the TB PPDU to be transmitted in response to the trigger frame, the HE STA (HE STA) and the EHT STA (EHT STA) or different EHT STAs (EHT STAs) may transmit TB PPDUs in different formats. This may result in a failed TB PPDU transmission, resulting in a wasted transmission opportunity. For convenience of explanation, the trigger frames defined in the HE, EHT, and NEXT standards are referred to as the HE trigger frame, EHT trigger frame, and NEXT trigger frame, respectively. Furthermore, the TRSs defined in the HE, EHT, and NEXT standards are referred to as the HE TRS, EHT TRS, and NEXT TRS. The format of the trigger frame will be described with reference to FIG. 16.

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

[0174] Specifically, FIG. 16(a) shows the format of a trigger frame, FIG. 16(b) shows the Common Info field of the trigger frame, and FIG. 16(c) shows the User Info field of the trigger frame. The MAC header of the trigger frame includes a Frame Control field, a Duration field, and an Address field. Here, the Address field includes an RA field and a TA field. The trigger frame also includes a Common Info field and a User Info List field. The Common Info field includes information for all stations triggered by the trigger frame. The User Info List field may also include a User Info field. In specific embodiments, a specific type of trigger frame may not include a User Info List field. The trigger frame may also include a Padding field and an FCS field. The Padding field may increase the frame length to allow time for a STA receiving the trigger frame to prepare a response, and may be optionally present.

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

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

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

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

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

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

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

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

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

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

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

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

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

[0188] In yet another specific embodiment, whether the trigger frame corresponds to an HE trigger frame, an EHT trigger frame, or a NEXT trigger frame may be determined based on the Common Info field included in the trigger frame. For example, if the value of the Trigger Type subfield in the Common Info field of the trigger frame is a first value, the trigger frame may be classified as an HE trigger frame. If the value of the Trigger Type subfield in the Common Info field of the trigger frame is a second value, the trigger frame may be classified as an EHT trigger frame. If the value of the Trigger Type subfield in the Common Info field of the trigger frame is a third value, the trigger frame may be classified as a NEXT trigger frame. Specifically, if the value of the Trigger Type subfield in the Common Info field of the trigger frame is between 0 and 7, the trigger frame may be classified as an HE trigger frame. Also, if the value of the Trigger Type subfield in the Common Info field of the trigger frame is not between 0 and 7, the trigger frame may be classified as an EHT trigger frame or a NEXT trigger frame. Because the number of bits in the Trigger Type subfield is limited, this embodiment has the disadvantage of restricting the trigger types that can be used in the future with the limited bit field values.

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

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

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

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

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

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

[0195] These embodiments may also be used to determine the format of a TB PPDU sent in response to a TRS field.

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

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

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

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

[0200] The format of the TRS may be determined depending on whether the HT Control field containing the TRS is an HE variant, an EHT variant, or a NEXT variant. If the HT Control field containing the TRS is an EHT variant, the TRS may be an EHT TRS. Also, if the HT Control field containing the TRS is a NEXT variant, the TRS may be a NEXT TRS. Also, the format of the TRS may be determined depending on the value of a pre-specified bit among the bits of the HT Control field containing the TRS, whether the HT Control field is an HE variant, an EHT variant, or a NEXT variant. For example, if the first and second bits (B0, B1) of the HT Control field have values of 11, the TRS may be an EHT TRS. b If so, the HT Control field may be the HE variant. Whether the HT Control field is the HE variant, the EHT variant, or the NEXT variant may be determined based on the first and second bits (B0, B1) of the HT Control field and an additional bit, for example, the 32nd bit (B31).

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

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

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

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

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

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

[0207] TXOP sharing may be performed within an established TXOP, and one or more TXOPs may be shared between established TXOPs. That is, one or more TXOPs may be shared with other STAs within a TXOP established by a STA.

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

[0209] In sharing a TXOP, during the shared TXOP, the STA with which the TXOP is shared can transmit a frame to the STA with which the TXOP is shared or to a third STA (or even another STA). That is, when an AP sets a TXOP and shares a part or all of the set TXOP with a STA, the STA with which the TXOP is shared can transmit a frame to the AP with which the TXOP is shared or to a third STA. In this case, the frame transmitted by the STA to the third STA can be a P2P (peer to peer) frame because it is a frame transmitted between non-AP STAs.

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

[0211] The MU-RTS frame, which is a frame for sharing a TXOP, may be a frame that instructs one or more STAs to transmit a CTS frame. For example, the CTS frame may be transmitted as an immediate response to the MU-RTS frame, and the CTS frame may be a non-HT PPDU. Hereinafter, in the present invention, the MU-RTS frame for sharing a TXOP may be referred to as a modified MU-RTS frame or an MU-RTS TXS trigger frame. However, the frame for sharing a TXOP may be referred to by various names without being limited thereto.

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

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

[0214] A specific field included in the frame may indicate whether a transmitted MU-RTS frame is an MU-RTS frame for TXOP sharing (modified MU-RTS frame) or an MU-RTS frame not used for TXOP sharing. For example, if the value of a specific field included in the frame is a pre-set value, the MU-RTS frame may be a modified MU-RTS frame for TXOP sharing. In this case, the specific field may be the GI and HE-LTF type subfield. For example, if the type field included in the trigger frame indicates an MU-RTS frame, the value of the GI and HE-LTF type subfield may identify whether the MU-RTS frame is a trigger frame for TXOP sharing. That is, if the GI and HE-LTF type subfield are set to a pre-set value, the trigger frame may be a trigger frame for TXOP sharing (e.g., a modified MU-RTS frame or an MU-RTS TXS trigger frame).

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

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

[0217] In the present invention, what is referred to as an MU-RTS frame may be an existing MU-RTS frame, i.e., what is referred to as an MU-RTS frame in the present invention may be an MU-RTS frame that is not a modified MU-RTS frame.

[0218] According to one embodiment of the present invention, a CTS frame may be transmitted in response to a modified MU-RTS frame. The CTS frame may be transmitted by a STA receiving a TXOP share. In this case, the STA receiving a TXOP share may transmit the frame immediately after transmitting the CTS frame. The STA receiving a TXOP share may transmit the frame immediately after transmitting the PPDU including the CTS frame. The frame transmitted immediately after transmitting the CTS frame may be included in a PPDU transmitted by the STA receiving the TXOP share during the shared TXOP. Alternatively, the frame transmitted immediately after transmitting the CTS frame may be included in the non-TB PPDU. In addition, in the present invention, "transmitted immediately" may mean transmitting after SIFS or PIFS from the end of the PPDU including the CTS frame. The CTS frame may serve to notify the STA receiving the TXOP share that it has received the TXOP share.

[0219] According to yet another embodiment, a CTS frame may not be transmitted in response to a modified MU-RTS frame. Alternatively, the STA receiving the TXOP sharing may transmit a frame immediately after the modified MU-RTS frame. Alternatively, the STA receiving the TXOP sharing may transmit a PPDU immediately after the PPDU containing the modified MU-RTS frame. The frame transmitted at this time may be included in the PPDU transmitted by the STA receiving the TXOP sharing during the shared TXOP. Alternatively, the frame transmitted at this time may be included in the non-TB PPDU. In the present invention, transmitting immediately may mean transmitting after SIFS or PIFS from the end of the PPDU containing the modified MU-RTS frame.

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

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

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

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

[0224] For example, an AP can configure the TXOP of the AP by transmitting a trigger frame to a non-AP STA (or STAs). At this time, if the AP intends to share some or all of the TXOP configured by the AP with the non-AP STA that transmitted the trigger frame, the AP can set a specific field (e.g., the GI and HE-LTF type subfield) of the trigger frame to a pre-configured value and transmit the trigger frame. At this time, the specific field can be referred to as the GI and HE-LTF type / triggered TXOP sharing mode subfield. Specifically, if the AP does not share the TXOP configured by the AP, the GI and HE-LTF type / triggered TXOP sharing mode subfield is set to '0' and may be interpreted as the GI and HE-LTF type subfield. However, if the AP does not share the TXOP configured by the AP, the GI and HE-LTF type / triggered TXOP sharing mode subfield is set to '1' or '2' and may be interpreted as the triggered TXOP sharing mode subfield. If the value of the GI and HE-LTF type / triggered TXOP sharing mode subfield is "1" or "2," the trigger frame can be called a modified MU-RTS frame or an MU-RTS TXS trigger frame. When an AP shares part or all of the TXOP set by the AP, the GI and HE-LTF type / triggered TXOP sharing mode subfield of the trigger frame for TXOP sharing indicates the TXOP sharing mode. For example, the GI and HE-LTF type / triggered TXOP sharing mode subfield indicates whether the TXOP is shared only in transmission and reception with the AP that set the TXOP, or whether it is shared in transmission and reception with a third STA (or other STAs) in addition to the AP. That is, if the value of the GI and HE-LTF type / triggered TXOP sharing mode subfield is "1," the STA can only transmit PPDUs to the AP during the shared TXOP.However, if the value of the GI And HE-LTF Type / Triggered TXOP Sharing Mode subfield is "2", the STA can transmit PPDUs to other STAs as well as the AP during the shared TXOP. That is, if the value of the GI And HE-LTF Type / Triggered TXOP Sharing Mode subfield is "2", the STA can also perform P2P communication during the shared TXOP.

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

[0226] [Table 1]

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

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

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

[0230] For a given STA, an intra-BSS frame or an intra-BSS PPDU may be a frame or PPDU that is determined to be transmitted from the same BSS as the STA. For a given STA, an inter-BSS frame or an inter-BSS PPDU may be a frame or PPDU that is determined to be transmitted from a different BSS than the STA. Whether a frame or a PPDU is transmitted from the same BSS or a different BSS may be determined based on the BSS color field included in the PPDU preamble, the address field included in the MAC header, etc. For example, if the BSS color field or the address field contains a value corresponding to the same BSS, the frame or the PPDU can be determined to be an intra-BSS frame or an intra-BSS PPDU. If the BSS color field or the address field does not contain a value corresponding to the same BSS, the frame or the PPDU can be determined to be an inter-BSS frame or an inter-BSS PPDU. The address field may include an RA field, a TA field, a BSSID field, etc.

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

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

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

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

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

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

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

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

[0239] STA1 can also share a TXOP with STA2. That is, STA1 can transmit a modified MU-RTS frame to STA2. As described above, STA2 can use the shared TXOP to 1) transmit a CTS frame followed by another frame, or 2) transmit another frame without transmitting a CTS frame. However, because the NAV is set, STA2 may have difficulty transmitting a frame. For example, STA2's NAV may have been set by a frame sent by STA1 to obtain a TXOP before allocating the shared TXOP. That is, STA2's NAV may have been set by receiving a frame sent by STA1 before transmitting a modified MU-RTS frame. Alternatively, STA2's NAV may have been set by receiving a frame sent by another STA during the same TXOP before receiving a modified MU-RTS frame addressed to itself. Alternatively, STA2's NAV may have been set based on a modified MU-RTS frame addressed to itself. That is, when STA2 uses shared TXOP, it must receive at least the modified MU-RTS frame, so NAV may be set. Therefore, STA2 may have difficulty transmitting frames using shared TXOP.

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

[0241] That is, when a TXOP is shared, a STA can transmit a PPDU regardless of the NAV set in the shared TXOP. Specifically, when an AP transmits a trigger frame (modified MU-RTS frame or MU-RTS TXS trigger frame) for TXOP sharing, the NAV may be set by the AP in the shared TXOP. In this case, the STA with which the TXOP is shared may be unable to transmit a PPDU due to the NAV set in the shared TXOP. Therefore, the STA with which the TXOP is shared can transmit a PPDU in the shared TXOP, ignoring the NAV set by the AP that shared the TXOP.

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

[0243] In this case, the frame transmitted by the TXOP-shared STA regardless of the NAV may be transmitted SIFS after the previous PPDU.

[0244] According to yet another embodiment, when a TXOP-shared STA transmits a frame, it may take the NAV into consideration if the frame is transmitted PIFS after the previous PPDU.

[0245] Referring to FIG. 20 , STA2 may have its NAV set based on the MU-RTS frame or the modified MU-RTS frame. For example, an intra-BSS NAV may be set. Alternatively, STA2 may have its NAV set based on the intra-BSS frame. Alternatively, STA2 may have its NAV set based on a frame transmitted by an associated AP. In this embodiment, NAV may collectively refer to the above-mentioned NAVs. STA1 may perform TXOP sharing with STA2. STA2 may receive TXOP sharing via a modified MU-RTS frame. When STA2 transmits a frame with a shared TXOP, it may transmit the frame regardless of the NAV. According to one embodiment, the frame transmitted at this time may be a frame transmitted immediately after the CTS frame transmitted immediately after the received modified MU-RTS frame. According to another embodiment, the frame transmitted at this time may be a frame transmitted immediately after the received modified MU-RTS frame. Also, according to one embodiment, the frame transmitted by STA2 may be a frame sent to the STA that transmitted the modified MU-RTS frame. That is, the RA field of the transmitted frame may be set to the value of the TA field of the received modified MU-RTS frame. Or, the RA field of the transmitted frame may be set to the MAC address of the AP. According to another embodiment, the frame transmitted by STA2 may be a frame transmitted to STA3. Also, transmitting a frame immediately after may mean that the start of transmission of the PPDU containing the frame is SIFS after the end of the previous PPDU.

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

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

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

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

[0250] Referring to FIG. 21, STA2 can receive a modified MU-RTS frame from STA1. Also, STA2 can transmit a CTS-to-self frame immediately after the modified MU-RTS frame. That is, STA2 can transmit a CTS frame by setting the RA field of the CTS frame to the MAC address of STA2. In this case, the CTS-to-self frame sent by STA2 can be considered to be a frame addressed to STA2 and requiring an immediate response. Alternatively, STA2 can consider that it has received a frame addressed to STA2 and requiring an immediate response in response to the transmission of the CTS-to-self frame. Therefore, STA2 can transmit a frame immediately after the CTS-to-self frame even if NAV is set.

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

[0252] According to one embodiment of the present invention, a STA that receives a TXOP share can perform recovery within the shared TXOP. That is, the STA that receives the TXOP share can perform recovery if the frame it transmitted within the shared TXOP fails. For example, if the frame it transmitted within the shared TXOP fails, the STA that received the TXOP can transmit a frame after the PIFS. According to an embodiment of the present invention, the TXOP holder can perform recovery. In addition, if the TXOP holder shares the TXOP, the STA that received the TXOP can perform recovery. That is, recovery is possible if the STA is 1) the TXOP responder or 2) a STA that is neither the TXOP holder nor the TXOP responder becomes the STA that received the TXOP share. Furthermore, even if the STA that received the TXOP shared transmits the first non-CTS frame after receiving the modified MU-RTS frame, the STA can perform recovery if the non-CTS frame fails. For example, if the TXOP holder cannot perform recovery if the first frame it transmitted in the sequence fails, it is considered that the TXOP was not obtained. However, a STA that receives a shared TXOP can also perform recovery operations if the first non-CTS frame it transmits in the shared TXOP fails.

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

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

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

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

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

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

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

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

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

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

[0263] In addition, in an embodiment of the present invention, a PHY-RXSTART.indication primitive may be received when PPDU reception has successfully started. Alternatively, a PHY-RXSTART.indication primitive may be issued when PPDU reception has successfully started. The PHY-RXSTART.indication primitive may be transmitted from the PHY to the MAC. For example, the PHY-RXSTART.indication primitive may be generated when the PHY receives a valid start of a PPDU. Receiving a valid start of a PPDU may indicate receiving a valid PHY header. The PHY-RXSTART.indication primitive may be generated after determining the PPDU format. When the PHY-RXSTART.indication primitive is generated, the PHY may maintain the physical medium in a busy status for the length of the PPDU or the length indicated by the PPDU preamble. If the PHY-RXSTART.indication primitive is generated, the PHY can keep the physical medium in a busy status for the length of the PPDU or the length indicated by the PPDU preamble even if reception fails during the PPDU. Also, the PHY-RXEND.indication may be generated when PPDU reception is completed.

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

[0265] According to one embodiment, the NAV timeout period may be based on at least one of the following:

[0266] 1) CTS_Time

[0267] 2) aSIFSTime

[0268] 3) aRxPHYStartDelay

[0269] 4) aSlotTime

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

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

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

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

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

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

[0276] Referring to the first sequence of FIG. 23, STA1, STA2, and STA3 may exist. STA1 may transmit an RTS frame or MU-RTS frame to STA2. For example, if the RA field of the RTS frame or MU-RTS frame is set to the address of STA2, the RTS frame or the MU-RTS frame may be transmitted to STA2. Alternatively, if the User Info field included in the MU-RTS frame indicates STA2, the MU-RTS frame may be transmitted to STA2. If STA2 successfully receives the RTS frame or the MU-RTS frame, it may respond with a CTS frame. In this case, STA2 may respond based on a carrier sense (CA) result. Furthermore, when STA3 receives the RTS frame or the MU-RTS frame, STA3 may set its NAV based on the duration information included in the RTS frame or the MU-RTS frame or the duration information included in the PPDU including the RTS frame or the MU-RTS frame. Also, if STA1 successfully receives the CTS frame sent by STA2, STA1 can send a frame to STA2. Also, STA3 may receive the CTS frame sent by STA2 or the frame sent by STA1 to STA2 after setting the NAV. In this case, STA3 may receive the PHY-RXSTART.indication primitive within the NAVTimeout period. Therefore, the NAV set by STA3 may not be released.

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

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

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

[0280] Referring to Figure 24, as described above, STA1 can perform TXOP sharing with STA2. STA1 may be the STA that performs TXOP sharing, and STA2 may be the STA that receives the TXOP sharing. STA1 can transmit the first frame of a sequence to STA2. Referring to Figure 24, the first frame of the sequence that STA1 transmits to STA2 may be an MU-RTS frame. In addition, a CTS frame may be transmitted as a response to the MU-RTS frame.

[0281] For example, a CTS frame may be transmitted from STAs including STA2. STA1 may obtain a TXOP. STA3 may not successfully receive the MU-RTS frame and the CTS frame. STA1 may transmit a modified MU-RTS frame to STA2. That is, STA1 may share a TXOP with STA2. STA3 may successfully receive the modified MU-RTS frame. Therefore, STA3 may set its NAV based on the modified MU-RTS frame. In this case, STA3 may have set its NAV based on the MU-RTS frame. According to the TXOP sharing sequence described above, STA2 may 1) transmit a CTS frame in response to the modified MU-RTS frame and then transmit a frame immediately after transmitting the CTS frame. Alternatively, STA2 may 2) transmit a frame without transmitting a CTS frame in response to the modified MU-RTS frame. STA3 may also not receive a frame or PPDU from STA2. For example, STA3 may be hidden from STA2. For example, STA2 may transmit with insufficient power for STA3 to receive the PPDU. In such a case, STA3 may not receive the PPDU within the NAV timeout period. This may be because the NAV timeout period is determined based on CTS_Time. That is, if STA2 transmits a frame after transmitting a CTS frame, the NAVTimeout period for STA3 should expire while the frame is being transmitted. Alternatively, if STA2 transmits a frame without transmitting a CTS frame, the frame is likely to be longer than the CTS frame, so the NAVTimeout period for STA3 should expire while the frame is being transmitted. Therefore, STA3 can release the NAV. If STA3 releases the NAV, STA3 may connect to the channel and disrupt the sequence between the shared TXOPs.

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

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

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

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

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

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

[0288] The determination of whether a received MU-RTS frame is a modified MU-RTS frame can be made in accordance with the above-described embodiments. For example, whether a MU-RTS frame is a modified MU-RTS frame may be determined based on the GI and HE-LTF Type subfield included in the MU-RTS frame. For example, if the GI and HE-LTF Type subfield value is 0, the MU-RTS frame including the GI and HE-LTF Type subfield may not be a modified MU-RTS frame. Also, if the GI and HE-LTF Type subfield value is not 0, the MU-RTS frame including the GI and HE-LTF Type subfield may be a modified MU-RTS frame. For example, if the GI and HE-LTF Type subfield value is 1 or 2, the MU-RTS frame including the GI and HE-LTF Type subfield may be a modified MU-RTS frame.

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

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

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

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

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

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

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

[0296] According to an embodiment of the present invention, when a STA sets NAV based on a modified MU-RTS frame, if it fails to successfully start PPDU reception within the extended NAVTimeout period, it can cancel the NAV. When a STA sets NAV based on a modified MU-RTS frame, if it fails to successfully start PPDU reception within the NAVTimeout period described in FIG. 23, it may not be possible to cancel the NAV.

[0297] In addition, if a STA sets NAV based on an MU-RTS frame that is not a modified MU-RTS frame, it can cancel the NAV if it is unable to successfully start PPDU reception within the NAVTimeout period described in Figure 23.

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

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

[0300] Referring to FIG. 26, STA1, STA2, and STA3 may exist. STA1 may transmit an MU-RTS frame to STA2. For example, STA1 may transmit an MU-RTS frame that is not a modified MU-RTS frame. However, STA2, the intended recipient of the MU-RTS frame, may fail to respond to the MU-RTS frame. Therefore, STA2 may fail to transmit a CTS frame. STA3 may set a NAV based on the MU-RTS frame. However, because STA2 failed to transmit a CTS frame, STA3 may fail to successfully start PPDU reception within the NAV Timeout period. In this case, STA3 may cancel the set NAV based on the NAV timeout operation. This may be an operation based on the determined NAV Timeout period because the frame for which STA3 set its NAV is an MU-RTS frame that is not a modified MU-RTS frame. That is, since the frame in which STA3 sets the NAV is an MU-RTS frame that is not a modified MU-RTS frame, the NAVTimeout period can be determined based on the time it takes to transmit the CTS frame.

[0301] STA1 may also transmit a modified MU-RTS frame. Figure 26 may omit the frame preceding the modified MU-RTS frame. STA2, the intended recipient of the modified MU-RTS frame, may respond to the modified MU-RTS frame. STA3 may also set its NAV based on the modified MU-RTS frame. However, STA3 may not receive the response sent by STA2 to the modified MU-RTS frame. For example, this may be because STA3 cannot hear the response sent by STA2 with sufficient power. For example, this may be because STA3 and STA2 are far apart. In such a case, STA3 may not be able to successfully start PPDU reception within the NAVTimeout period described in Figure 23. However, in such a case, STA3 may be able to successfully start PPDU reception within the extended NAVTimeout period. Therefore, STA3 does not need to perform a NAV timeout operation. The reason why STA3 was able to wait for the extended NAVTimeout period without performing NAV cancellation operation when the NAVTimeout period described in Figure 23 elapsed may be because the frame in which STA3 set the NAV was a modified MU-RTS frame, that is, an MU-RTS frame.

[0302] If STA2 fails to respond to the modified MU-RTS frame, STA1 can perform a recovery operation, allowing STA3 to successfully begin receiving the PPDU before the NAV timeout occurs.

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

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

[0305] FIG. 27 is a diagram illustrating STAs and APs applying NAV when TXOP sharing is applied according to one embodiment of the present invention.

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

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

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

[0309] In yet another specific embodiment, the shared TXOP period may be from the time the TXOP sharing is established until the time the shared TXOP duration has elapsed, even if the shared TXOP ends before the shared TXOP duration.

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

[0311] In this case, the STA that set up TXOP sharing can also transmit frames regardless of the NAV. In the embodiment of FIG. 27, the first STA (STA1) transmits an MU-RTS frame for TXOP sharing setup to the second STA (STA2). In this case, the first STA (STA1) may be an AP. The second STA (STA2) receives the MU-RTS frame for TXOP sharing setup and transmits a CTS frame in response to the MU-RTS frame for TXOP sharing setup. The second STA (STA2) exchanges frames within the shared TXOP. The first STA (STA1) can set its NAV based on frames transmitted by or to the second STA (STA2). For example, the second STA (STA2) can exchange frames with a third STA (STA3) within the shared TXOP. In this case, the first STA (STA1) can set its NAV based on frames transmitted by the third STA (STA3) to the second STA (STA2). In addition, the first STA (STA1) can set its NAV based on a frame transmitted by the second STA (STA2) to the third STA (STA3). When the first STA (STA1) sets its NAV in this way, it may be difficult for the shared TXOP to transmit a frame within the assigned TXOP. For example, when the first STA (STA1) attempts to transmit a frame after the shared TXOP ends, it may be unable to transmit the frame due to the NAV set within the shared TXOP. Specifically, if the frame included in the PPDU transmitted within the shared TXOP is not a frame that elicits an immediate response from the first STA (STA1), the first STA (STA1) may be unable to transmit the frame due to the set NAV.

[0312] The STA that set up the TXOP sharing can transmit frames regardless of the NAV in the TXOP that the STA acquired. In yet another specific embodiment, the STA that set up the TXOP sharing can transmit frames regardless of the NAV in the TXOP that the STA acquired after the shared TXOP has ended. The STA that set up the TXOP sharing can be the STA that sent the MU-RTS frame to set up the TXOP sharing or the TXOP holder.

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

[0314] In the above-described embodiment, the STA that set up the TXOP sharing to transmit a frame regardless of the NAV may refer to the STA transmitting a frame regardless of the NAV set based on a frame exchanged by a scheduled STA within the TXOP sharing. This is because if the STA that set up the TXOP sharing to transmit a frame regardless of the NAV set based on a frame not exchanged by a scheduled STA within the TXOP sharing, it may interfere with frame exchanges by other STAs. Furthermore, the STA may determine whether a frame has been exchanged by a scheduled STA within the TXOP sharing based on the MAC header of the frame. Specifically, the STA may determine whether a frame has been exchanged by a scheduled STA within the TXOP sharing based on the address field of the frame. The address field may include at least one of the RA field, the TA field, and the BSSID field. For example, if one of the address fields of the frame indicates the MAC address of the STA, the STA may determine whether the frame has been exchanged by a scheduled STA within the TXOP sharing. Furthermore, the STA may determine whether a frame has been exchanged by a scheduled STA within the TXOP sharing based on the preamble of the PPDU containing the frame. Furthermore, a STA can determine whether a frame is exchanged by a scheduled STA within TXOP sharing based on at least one of a BSS color and a STA ID included in the preamble of a PPDU containing the frame. If the preamble of the PPDU includes a BSS color of a BSS to which a scheduled STA of TXOP sharing belongs and the preamble of the PPDU includes a STA ID corresponding to the scheduled STA of TXOP sharing, the STA can determine that the frame included in the PPDU is a frame exchanged by a scheduled STA. In this case, the STA ID may be a value set based on the AID of the STA.

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

[0316] In this specification, setting a NAV may be used interchangeably with updating a NAV. In this specification, NAV may include at least one of an Intra-BSS NAV or a Basic NAV. If no specific reference is made to a type of NAV, NAV may refer to an Intra-BSS NAV. In this specification, setting a NAV by a STA based on a frame may include setting a NAV based on a PPDU containing the frame. Therefore, in this specification, not setting a NAV by a STA based on a frame may include not setting a NAV based on a PPDU containing the frame.

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

[0318] In yet another specific embodiment, the Duration / ID field of a frame transmitted within a shared TXOP or the TXOP of a PPDU including the frame may be set based on the shared TXOP. Specifically, the Duration / ID field of a frame transmitted within a shared TXOP or the TXOP of a PPDU including the frame may not be allowed to be set beyond the shared TXOP. This prevents a problem in which a STA that has set a shared TXOP cannot transmit frames even after the shared TXOP ends.

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

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

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

[0322] In the above-described embodiment, the trigger frame that the STA that established the shared TXOP cannot transmit may be the remaining trigger frame other than the trigger frame intended only for the STA that has been scheduled to share the TXOP. Therefore, the STA that established the shared TXOP can transmit trigger frames only to the STA that has been scheduled to share the TXOP within the shared TXOP. For example, the STA that established the shared TXOP can transmit an MU-RTS frame to establish TXOP sharing to extend the shared TXOP. In this case, the STA that receives the MU-RTS frame to establish TXOP sharing can start frame exchange without transmitting a CTS frame. Specifically, if frame exchange is only permitted with the STA that established the TXOP sharing in TXOP sharing, the STA that receives the MU-RTS frame to establish TXOP sharing can start frame exchange without transmitting a CTS frame.

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

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

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

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

[0327] The method for ending TXOP sharing will be explained using FIG.

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

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

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

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

[0332] In addition, a STA can signal its capability for the SRS Control subfield. Specifically, a STA can signal whether it can receive the SRS Control subfield. A STA can also signal whether it can respond to frames including the SRS Control subfield. A STA cannot transmit the SRS Control subfield to a STA that has signaled that it does not support operations on the SRS Control subfield. A STA can transmit the SRS Control subfield to a STA that has signaled that it supports operations on the SRS Control subfield.

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

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

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

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

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

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

[0339] As described above, an SRS Control subfield may not be transmitted to a STA that has signaled that it does not support operations on the SRS Control subfield. When the SRS Control subfield signals the termination of TXOP sharing, a STA that has signaled that it does not support operations on the SRS Control subfield may not receive TXOP sharing termination signaling. Therefore, a scheduled STA for TXOP sharing may transmit an SRS Control subfield signaling the termination of TXOP sharing even to a STA that has signaled that it does not support operations on the SRS Control subfield. The SRS Control subfield signaling the termination of TXOP sharing may be an SRS Control subfield with a TXOP Termination subfield value of 1. A scheduled STA for TXOP sharing may not transmit an SRS Control subfield with a TXOP Termination subfield value of 0 to a STA that has signaled that it does not support operations on the SRS Control subfield. Furthermore, the restriction that an SRS Control subfield may not be transmitted to a STA that has signaled that it does not support operations on the SRS Control subfield may only apply when the SRS Control subfield is transmitted outside a shared TXOP.

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

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

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

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

[0344] According to one embodiment of the present invention, the modified MU-RTS frame does not have to be the first frame in a TXOP. For example, the TXOP holder may send another frame rather than the modified MU-RTS frame to obtain the TXOP. This allows a STA to set its NAV before setting its NAV based on the modified MU-RTS frame. That is, the STA can set its NAV based on a frame transmitted before the modified MU-RTS frame in the TXOP. The NAV timeout operation described above can be performed when the NAV is set based on an RTS frame or MU-RTS frame. However, by transmitting a frame before the modified MU-RTS frame in the TXOP, the occurrence of NAV setting based on an RTS frame or MU-RTS frame can be reduced. Furthermore, the duration information contained in the modified MU-RTS frame does not need to increase the TXOP.

[0345] FIG. 29 is a flowchart showing an example of the operation of the STA according to one embodiment of the present invention.

[0346] Referring to FIG. 29, a STA may receive a portion or all of a TXOP from the AP, and based on this, can transmit a PPDU within the shared TXOP.

[0347] Specifically, a STA may receive a trigger frame instructing uplink transmission from an AP (Access Point) (S29010). At this time, the trigger frame may be used to share a part or all of a transmission opportunity (TXOP) acquired by the AP with the STA, and when used for sharing a part or a part of a TXOP, it may be called a modified MU-RTS frame or an MU-RTS TXS trigger frame. At this time, the STA can recognize whether the received frame is a frame for sharing a TXOP from the type field of the trigger frame described above.

[0348] Then, the STA may transmit a PPDU to the AP and / or other STAs within the shared TXOP based on the trigger frame (S29020). The PPDU includes duration information indicating a TXOP for transmission of the PPDU, and the duration information may be set based on the shared TXOP.

[0349] The end point of the duration indicated by the duration information may be the same as or may end before the end point of the shared TXOP.

[0350] If a network allocation vector (NAV) is set by a frame transmitted by the AP in a TXOP, the PPDU is transmitted regardless of the set NAV in the shared TXOP.

[0351] Furthermore, if another STA sets a NAV and a NAV timeout period indicating the end time of the NAV within the shared TXOP based on the trigger frame, even if the NAV timeout period expires within the shared TXOP, the NAV set by the other STA within the shared TXOP may not be released due to the expiration of the NAV timeout period.

[0352] The trigger frame includes a subfield indicating whether the trigger frame shares the TXOP.

[0353] If the subfield indicates sharing of the TXOP, the value of the subfield indicates whether transmission and reception with the other STA is possible within the shared TXOP.

[0354] The trigger frame includes a type field indicating the type of the trigger frame, and the sharing of the part or all of the TXOP is set by the type of the trigger frame according to the type field.

[0355] The above description of the present invention is for illustrative purposes only, and those skilled in the art will understand that the present invention can be easily modified into other specific forms without changing the technical spirit or essential features of the present invention. Therefore, the above-described embodiments should be understood to be illustrative in all respects and not restrictive. For example, each component described as a single type may be implemented in a distributed form, and similarly, each component described as a distributed type may be implemented in a combined form.

[0356] The scope of the present invention is indicated by the claims set forth below rather than by the above detailed description, and all modifications and variations derived from the meaning and scope of the claims and their equivalents should be interpreted as being included within the scope of the present invention. [Explanation of symbols]

[0357] 100 Stations 110 processors 120 Communications Department 140 User Interface Section 150 display units 160 memory 210 processor 220 Communications Department 260 memory 300 servers

Claims

1. A station (STA) of a wireless communication system, a transceiver, and a processor configured to control the transceiver; The processor: Receive a trigger frame from an AP (Access Point), The trigger frame is used to share a specific time, which is a part or all of a transmission opportunity (TXOP) acquired by the AP, with the STA; Transmitting a frame including duration information to the AP and / or other STAs within the specific time period based on the trigger frame; When a network allocation vector (NAV) and a NAV timeout indicating the end of the NAV are set based on the trigger frame, the NAV is not released even after the NAV timeout expires within the specific time. It is configured as follows: STA.

2. The STA of claim 1, wherein, when an intra-BSS (Basic Service Set) NAV is set, the frame is transmitted within the specific time regardless of the intra-BSS NAV.

3. The STA according to claim 1 , wherein the duration information is set based on the specific time.

4. The STA of claim 1 , wherein the end time indicated by the duration information is not later than the end time of the specific time.

5. The processor: Transmitting a specific frame that is the last frame transmitted by the STA within the specific time period; When the specific frame is transmitted, The specific time is returned to the AP; The STA of claim 2 , further configured to perform transmission regardless of intra-BSS NAV until the specified time is returned.

6. The STA of claim 1 , wherein the trigger frame includes a specific subfield indicating whether or not the TXOP is shared by the trigger frame.

7. The STA of claim 6, wherein when the specific subfield indicates sharing of the TXOP, the value of the specific subfield indicates whether transmission and reception with the AP and / or the other STA is possible within the specific time.

8. the trigger frame includes a type field indicating a type of the trigger frame; The STA of claim 1 , wherein the specific time is set to be shared for some or all of the TXOP based on the type of the trigger frame indicated by the type field.

9. A method for a station (STA) to transmit a frame in a wireless communication system, the method comprising: receiving a trigger frame from an Access Point (AP), the trigger frame being used to share a specific time period, which is a part or all of a transmission opportunity (TXOP) acquired by the AP, with the STA; transmitting a frame including duration information to the AP and / or another STA within the specific time based on the trigger frame, transmitting a network allocation vector (NAV) and a NAV timeout indicating the end of the NAV, the NAV being not released even after the NAV timeout expires within the specific time period, if the NAV and a NAV timeout indicating the end of the NAV are set based on the trigger frame; Including, method.

10. The method of claim 9, wherein the frame is transmitted within the specific time period regardless of an intra-Basic Service Set (intra-BSS) NAV if the intra-BSS NAV is set.

11. The method of claim 9 , wherein the duration information is set based on the specific time period.

12. The method of claim 9 , wherein the end time indicated by the duration information is not later than the end time of the specific time.

13. The method comprises: transmitting a specific frame, which is the last frame transmitted by the STA within the specific time; When the specific frame is transmitted, The specific time is returned to the AP; The method of claim 10, wherein the STA performs transmission regardless of the intra-BSS NAV until the specific time is returned.

14. The method of claim 9 , wherein the trigger frame includes a specific subfield indicating whether the trigger frame shares the TXOP.

15. The method of claim 14, wherein when the specific subfield indicates sharing of the TXOP, the value of the specific subfield indicates whether transmission and reception with the AP and / or the other STAs is possible within the specific time.

16. the trigger frame includes a type field indicating a type of the trigger frame; The method of claim 9 , wherein the specific time is configured to be shared for some or all of the TXOP based on the type of the trigger frame indicated by the type field.

Images