Method for transmitting and receiving data by using transmission opportunity, and wireless communication terminal using same

Abstract

Disclosed are a method and apparatus for operation of a wireless communication terminal. Particularly, a first access point (AP) according to the present invention may transmit, to a second AP, an invite frame for a coordinated beamforming (Co-BF) operation within a transmission opportunity (TXOP) shared by the first AP. Thereafter, the first AP may receive a response frame from the second AP in response to the invite frame.

Description

Data transmission and reception method using transmission opportunity and wireless communication terminal using the same

[0001] The present invention relates to a method for acquiring a transmission opportunity (TXOP) and occupying a channel to improve the efficiency of a wireless LAN.

[0002]

[0003] With the recent expansion of mobile device adoption, Wireless LAN technology, capable of providing fast wireless internet services to these devices, is gaining significant attention. Based on short-range wireless communication technology, Wireless LAN enables mobile devices—such as smartphones, smart pads, laptop computers, portable multimedia players, and embedded devices—to connect to the internet wirelessly in homes, businesses, or specific service areas.

[0004] Since supporting early wireless LAN technology using the 2.4GHz frequency, IEEE (Institute of Electrical and Electronics Engineers) 802.11 has been commercializing or developing standards for various technologies. First, IEEE 802.11b uses the 2.4GHz band and supports a maximum communication speed of 11Mbps. IEEE 802.11a, which was commercialized after IEEE 802.11b, uses the 5GHz band instead of the 2.4GHz band, thereby reducing the impact of interference compared to the significantly congested 2.4GHz band, and improved communication speeds up to 54Mbps using OFDM (orthogonal frequency division multiplexing) technology. However, IEEE 802.11a has the disadvantage of a shorter communication range compared to IEEE 802.11b. IEEE 802.11g, like IEEE 802.11b, uses the 2.4GHz band frequency to achieve a maximum communication speed of 54Mbps and has received considerable attention for satisfying backward compatibility, and it also has an advantage over IEEE 802.11a in terms of communication distance.

[0005] In addition, IEEE 802.11n is a technical standard established to overcome the limitations on communication speed that have been pointed out as a vulnerability in wireless LANs. IEEE 802.11n aims to increase network speed and reliability, and to extend the operating range of wireless networks. More specifically, IEEE 802.11n supports High Throughput (HT) with a data processing speed of up to 540 Mbps or higher, and is based on MIMO (Multiple Inputs and Multiple Outputs) technology, which uses multiple antennas at both the transmitter and receiver ends to minimize transmission errors and optimize data speeds. Furthermore, this standard allows for the use of coding schemes that transmit multiple redundant copies to enhance data reliability.

[0006] As the adoption of wireless LANs has increased and applications utilizing them have diversified, a need has arisen for new wireless LAN systems capable of supporting Very High Throughput (VHT) higher than the data processing speeds supported by IEEE 802.11n. Among these, IEEE 802.11ac supports a wide bandwidth (80MHz to 160MHz) in the 5GHz frequency band. Although the IEEE 802.11ac standard is defined only in the 5GHz band, early 11ac chipsets will also support operation in the 2.4GHz band to ensure backward compatibility with existing 2.4GHz band products. Theoretically, according to this standard, multi-station wireless LAN speeds can reach a minimum of 1Gbps, and maximum single-link speeds can reach a minimum of 500Mbps. This is achieved by extending the wireless interface concepts adopted in 802.11n, such as a wider wireless frequency bandwidth (up to 160 MHz), more MIMO spatial streams (up to 8), multi-user MIMO, and high-density modulation (up to 256 QAM). Additionally, there is IEEE 802.11ad, which transmits data using the 60 GHz band instead of the existing 2.4 GHz / 5 GHz bands. IEEE 802.11ad is a transmission standard that provides speeds of up to 7 Gbps using beamforming technology, making it suitable for high-bitrate video streaming, such as large amounts of data or uncompressed HD video. However, the 60 GHz frequency band has the disadvantage of being difficult to penetrate through obstacles, limiting its use to only between devices in close proximity.

[0007] Meanwhile, as a wireless LAN standard following 802.11ac and 802.11ad, the IEEE 802.11ax (High Efficiency WLAN, HEW) standard is in the final stages of development to provide high-efficiency and high-performance wireless LAN communication technology in high-density environments where APs and terminals are densely packed. In an 802.11ax-based wireless LAN environment, high frequency-efficiency communication must be provided indoors and outdoors in the presence of high-density stations and APs (Access Points), and various technologies have been developed to implement this.

[0008] In addition, development of a new wireless LAN standard has begun to increase maximum transmission speeds to support new multimedia applications such as high-definition video and real-time games. The 7th generation wireless LAN standard, IEEE 802.11be (Extremely High Throughput, EHT), is currently under development with the goal of supporting transmission rates of up to 30Gbps in the 2.4 / 5 / 6 GHz bands through wider bandwidth, increased spatial streams, and multiple AP cooperation.

[0009] Recently, discussions have begun on Ultra High Reliability (UHR) wireless LAN communication technology as a wireless LAN standard following 802.11be to overcome the reliability issues that have been pointed out as a limitation of wireless LANs. The Ultra High Reliability wireless LAN standard is currently under development with the goal of supporting low latency and low jitter for wireless LAN traffic with a high probability (e.g., over 99.9999%).

[0010]

[0011] The present invention aims to provide an ultra-high reliability wireless LAN service for new multimedia applications by enhancing the wireless LAN channel occupancy method.

[0012] 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 skilled in the art to which this invention belongs from the description below.

[0013]

[0014] The first AP (access point) according to the present invention comprises a transmitting and receiving unit; and includes a processor, wherein the processor transmits an invite frame for a coordinated beamforming (Co-BF) operation to a second AP within a transmission opportunity (TXOP) shared by the first AP, wherein the invite frame comprises i) a specific field indicating whether an exchange of a first initial control frame (ICF) and a first initial control response (ICR) frame is performed between the first AP and the first non-AP STA before the first Co-BF transmission by the first AP to the first non-AP STA associated with the first AP during the shared TXOP, and ii) first station identifier (STA ID) information for identifying the first non-AP, and receives a response frame from the second AP in response to the invite frame, wherein if the second AP accepts the Co-BF operation, the response frame comprises i) the second associated with the second AP during the second TXOP It includes length information related to the second ICF and second ICR frames exchanged between the second AP and the second non-AP before the second Co-BF transmission to the non-AP STA, and ii) second STA ID information for identifying the second non-AP.

[0015] In addition, in the present invention, the second Co-BF transmission is performed based on whether the specific field indicates the exchange of the first ICF and the first ICR frame.

[0016] In addition, in the present invention, the processor transmits a trigger frame for the first Co-BF transmission and the second Co-BF transmission to the first non-AP STA and the second non-AP STA, wherein the trigger frame includes acknowledgment policy information related to an acknowledgment policy included in the second Co-BF transmission.

[0017] In addition, in the present invention, the response policy related to the response policy information is included in the MPDU (medium access control protocol data unit) transmitted through the second Co-BF transmission.

[0018] In addition, in the present invention, the response policy is one of No Ack or Block Ack.

[0019] Additionally, in the present invention, if the response policy indicated by the response policy information is not No Ack, the trigger frame further includes duration information related to the length of the response frame for the Co-BF transmission through the Co-BF operation.

[0020] In addition, in the present invention, the processor exchanges unavailable information with the second AP regarding an unavailable period during which the execution of a frame exchange procedure for the Co-BF operation is impossible.

[0021] In addition, in the present invention, the unavailable information includes at least one of the start time information of an unavailable interval, duration information, or period information, and the Co-BF operation is performed based on the unavailable information.

[0022] Additionally, the present invention comprises the step of transmitting an invite frame for a coordinated beamforming (Co-BF) operation to a second AP within a transmission opportunity (TXOP) shared by the first AP, wherein the invite frame comprises i) a specific field indicating whether, during the second TXOP, the first AP exchanges an initial control frame (ICF) and an initial control response (ICR) frame between the first AP and a first non-AP STA before transmitting a first Co-BF to a first non-AP STA associated with the first AP, and ii) first station identifier (STA ID) information for identifying the first non-AP; The method includes the step of receiving a response frame from the second AP in response to the invitation frame, wherein if the second AP accepts the Co-BF operation, the response frame includes i) length information related to the second ICF and second ICR frames exchanged between the second AP and the second non-AP before the second Co-BF transmission to the second non-AP STA associated with the second AP during the second TXOP, and ii) second STA ID information for identifying the second non-AP.

[0023]

[0024] One embodiment of the present invention provides a wireless communication method for efficiently managing TXOPs and a wireless communication terminal using the same.

[0025] According to one embodiment of the present invention, a station can share (or transfer) the transmission opportunity (TXOP) it has acquired to another station.

[0026] In addition, according to one embodiment of the present invention, a station can allocate a time interval within the TXOP it has acquired to another station.

[0027] The AP that acquired the TXOP can check whether other APs in a cooperative relationship are willing to participate in transmission using coordinated beamforming (hereinafter referred to as Co-BF).

[0028] According to one embodiment of the present invention, an AP that receives an inquiry from an AP that is a TXOP holder regarding its intention to participate in Co-BF transmission may instruct the AP that is the TXOP holder whether it has the intention to participate in Co-BF transmission.

[0029] According to one embodiment of the present invention, an AP wishing to participate in Co-BF transmission may provide information on the target device of the Co-BF transmission that it wishes to perform to an AP that is a TXOP holder.

[0030] The effects obtainable from the present invention are not limited to those mentioned above, and other unmentioned effects will be clearly understood by those skilled in the art from the description below.

[0031]

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

[0033] FIG. 2 shows a wireless LAN system according to another embodiment of the present invention.

[0034] FIG. 3 shows the configuration of a station according to one embodiment of the present invention.

[0035] FIG. 4 shows the configuration of an access point according to one embodiment of the present invention.

[0036] Figure 5 schematically illustrates the process of a station establishing a link with an access point.

[0037] Figure 6 shows an example of a CSMA (Carrier Sense Multiple Access) / CA (Collision Avoidance) method used in wireless LAN communication.

[0038] Figure 7 shows various standard generational PPDU (physical layer protocol data unit) formats according to an embodiment of the present invention.

[0039] FIG. 8 shows an EHT / UHR PPDU format according to an embodiment of the present invention.

[0040] FIG. 9 shows a transmission / TXOP protection method using an RTS frame and a CTS frame according to an embodiment of the present invention.

[0041] FIG. 10 shows a transmission / TXOP protection method using MU-RTS frames and CTS frames according to an embodiment of the present invention.

[0042] FIG. 11 shows an embodiment in which the transmission of traffic of other APs is delayed by the TXOP (transmission opportunity) of an AP according to an embodiment of the present invention.

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

[0044] FIG. 13 shows the format of a common information field of a trigger frame according to an embodiment of the present invention.

[0045] FIG. 14 shows the format of the user information field of a trigger frame according to an embodiment of the present invention.

[0046] FIG. 15 shows the format of the user information field of a MU-RTS TXS trigger frame according to an embodiment of the present invention.

[0047] FIG. 16 illustrates an example of a method for sharing a TXOP obtained by an AP with a STA according to an embodiment of the present invention.

[0048] FIG. 17 illustrates another example of a method for sharing a TXOP acquired by an AP with a STA according to one embodiment of the present invention.

[0049] FIG. 18 illustrates another example of a method for sharing a TXOP acquired by an AP with a STA according to one embodiment of the present invention.

[0050] FIG. 19 illustrates an example of a method in which an AP that has acquired a TXOP according to an embodiment of the present invention shares part or all of the TXOP with another AP.

[0051] FIG. 20 shows an example in which the Medium of the AP that shared the TXOP is occupied during a shared TXOP according to an embodiment of the present invention.

[0052] FIG. 21 illustrates an example of a case where channel access of a legacy AP is delayed due to TXOP sharing between APs according to an embodiment of the present invention.

[0053] FIG. 22 shows an example of a method in which a backoff counter for channel access of an AP that has received a shared TXOP is adjusted according to an embodiment of the present invention.

[0054] FIG. 23 shows an example of a frame exchange sequence method based on an initial frame transmitted by an AP, which is a TXOP holder, according to an embodiment of the present invention.

[0055] FIG. 24 shows an example of a format of a response frame for sharing TXOPs between APs according to an embodiment of the present invention.

[0056] FIG. 25 illustrates an example of a method for utilizing a random access resource unit (RA-RU) allocated to unspecified APs that do not perform M-AP coordination according to an embodiment of the present invention.

[0057] FIG. 26 shows the format of elements exchanged between APs for multiple AP cooperative puncturing according to one embodiment of the present invention, and the operating bandwidth and main channel setting state of the APs to which multiple AP cooperative puncturing is applied.

[0058] FIG. 27 shows an example of a frame exchange sequence with coordinated puncturing applied for AP 2 according to one embodiment of the present invention.

[0059] FIG. 28 shows another example of a frame exchange sequence with adjusted puncturing applied for AP 2 according to one embodiment of the present invention.

[0060] FIG. 29 shows an example of an element format transmitted by an AP performing a multi-AP cooperation operation according to an embodiment of the present invention to instruct the STAs of its BSS about information related to channel access restrictions.

[0061] FIG. 30 shows an example of a frame format used in a multi-AP coordination process according to an embodiment of the present invention.

[0062] FIG. 31 shows an example of a multi-AP coordination process between APs according to an embodiment of the present invention.

[0063] FIG. 32 shows an example of a multi-AP adjusted teardown frame format according to an embodiment of the present invention.

[0064] FIG. 33 shows an example of the format of an operation information field transmitted by an AP for changing a disabled subchannel of a BSS according to an embodiment of the present invention.

[0065] FIG. 34 illustrates an example of a method in which multiple AP adjustment puncturing is applied to a sub-channel other than the primary channel according to an embodiment of the present invention.

[0066] FIG. 35 shows an example of the positional relationship of puncturing channels between APs performing multiple AP coordination puncturing consultation according to an embodiment of the present invention and the coordination limitation thereof.

[0067] FIG. 36 shows an example of a PPC and APC designation method for 80 MHz, 160 MHz, and 320 MHz channels according to an embodiment of the present invention.

[0068] Figure 37 is a conceptual diagram showing the effect of transmission using Co-BF (coordinated beamforming, hereinafter referred to as Co-BF).

[0069] FIG. 38 illustrates a procedure in which two APs perform transmission using Co-BF according to an embodiment of the present invention.

[0070] FIG. 39 illustrates an example of the format of a Co-BF invite frame transmitted from an AP sharing a TXOP according to an embodiment of the present invention.

[0071] FIG. 40 illustrates an example of the format of a Co-BF response frame transmitted from an AP that has received a shared TXOP, according to an embodiment of the present invention.

[0072] FIG. 41 illustrates an example of the format of a Co-BF trigger frame transmitted from an AP sharing a TXOP according to an embodiment of the present invention.

[0073] FIG. 42 is a flowchart illustrating an example of a method for performing downlink transmission with an AP that has received a TXOP during a TXOP shared by an AP, according to an embodiment of the present invention.

[0074]

[0075] The terms used in this specification have been selected to be as widely used as possible, taking into account their functions in the present invention; however, these may vary depending on the intent, convention, or emergence of new technologies of those skilled in the art. In addition, in certain cases, terms have been arbitrarily selected by the applicant, and in such cases, their meanings will be described in the relevant description of the invention. Therefore, it should be noted that the terms used in this specification should be interpreted based on their actual meanings and the overall content of this specification, rather than merely their names.

[0076] Throughout the specification, when a configuration is described as being "connected" to another configuration, this includes not only cases where they are "directly connected," but also cases where they are "electrically connected" with other components interposed between them. Furthermore, when a configuration is described as "including" a specific component, this means that, unless specifically stated otherwise, it does not exclude other components but may include additional components. In addition, limitations such as "greater than or equal to" or "less than or equal to" based on a specific threshold value may be appropriately replaced with "greater than" or "less than," respectively, depending on the embodiment.

[0077] Hereinafter, in the present invention, fields and sub-fields may be used interchangeably.

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

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

[0080] As illustrated in FIG. 1, the infrastructure BSS (BSS1, BSS2) includes one or more stations (STA1, STA2, STA3, STA4, STA5), access points (AP-1, AP-2) that are stations providing distribution services, and a distribution system (DS) that connects multiple access points (AP-1, AP-2).

[0081] A Station (STA) is any device comprising a Medium Access Control (MAC) and a Physical Layer interface for a wireless medium that conforms to the specifications of the IEEE 802.11 standard, and in a broad sense includes both non-Access Point (non-AP) stations and Access Points (APs). Additionally, in this specification, the term "terminal" may be used to refer to a non-AP STA or an AP, or to refer to both. A station for wireless communication includes a processor and a communication unit, and may further include a user interface unit and a display unit, etc., depending on the embodiment. The processor generates frames to be transmitted over a wireless network or processes frames received over said wireless network, and may perform various other processing to control the station. Furthermore, the communication unit is functionally connected to said processor and transmits and receives frames over the wireless network for the station. In the present invention, the term "terminal" may be used to include user equipment (UE).

[0082] An Access Point (AP) is an entity that provides access to a Distribution System (DS) via a wireless medium for stations associated with it. In principle, communication between non-AP stations in an Infrastructure BSS is conducted via the AP, but direct communication between non-AP stations is possible if a direct link is established. Meanwhile, in the present invention, the term AP is used to include the Personal BSS Coordination Point (PCP), and in a broader sense, it may include concepts such as a centralized controller, a Base Station (BS), a Node-B, a Base Transceiver System (BTS), or a site controller. In the present invention, the AP may also be referred to as a base wireless communication terminal, and in a broad sense, the term base wireless communication terminal may be used to include the AP, base station, eNB (eNodeB), and transmission point (TP). In addition, the base wireless communication terminal may include various types of wireless communication terminals that allocate medium resources and perform scheduling in communication with multiple wireless communication terminals.

[0083] Multiple infrastructure BSSs can be interconnected through a distribution system (DS). At this time, multiple BSSs connected through the distribution system are called an Extended Service Set (ESS).

[0084] FIG. 2 illustrates an independent BSS, which is a wireless LAN system according to another embodiment of the present invention. In the embodiment of FIG. 2, parts that are identical or corresponding to the embodiment of FIG. 1 are omitted from redundant description.

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

[0086] FIG. 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 an embodiment of the present invention may include a processor (110), a communication unit (120), a user interface unit (140), a display unit (150), and a memory (160).

[0087] First, the communication unit (120) transmits and receives wireless signals such as wireless LAN packets and may be built into or externally provided in the station (100). According to an embodiment, the communication unit (120) may include at least one communication module using different frequency bands. For example, the communication unit (120) may include communication modules of different frequency bands such as 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz. According to one embodiment, the station (100) may be equipped with a communication module using a frequency band of 7.125 GHz or higher and a communication module using a frequency band of 7.125 GHz or lower. Each communication module may perform wireless communication with an AP or an external station according to the wireless LAN standard of the frequency band supported by the communication module. Depending on the performance and requirements of the station (100), the communication unit (120) may operate only one communication module at a time or operate multiple communication modules together simultaneously. When the station (100) includes a plurality of communication modules, each communication module may be provided in an independent form, or the plurality of modules may be integrated into a single chip. In an embodiment of the present invention, the communication unit (120) may represent an RF communication module that processes RF (Radio Frequency) signals.

[0088] Next, the user interface unit (140) includes various types of input / output means provided in the station (100). That is, the user interface unit (140) can receive user input using various input means, and the processor (110) can control the station (100) based on the received user input. In addition, the user interface unit (140) can perform output based on the commands of the processor (110) using various output means.

[0089] Next, the display unit (150) outputs an image to the display screen. The display unit (150) can output various display objects, such as content executed by the processor (110) or a user interface based on control commands of the processor (110). Additionally, the memory (160) stores a control program used in the station (100) and various data associated therewith. This control program may include a connection program necessary for the station (100) to establish a connection with an AP or an external station.

[0090] The processor (110) of the present invention can execute various commands or programs and process data within the station (100). In addition, the processor (110) can control each unit of the station (100) described above and control the transmission and reception of data between the units. According to an embodiment of the present invention, the processor (110) can execute a program for connection with an AP stored in memory (160) and receive a communication setting message transmitted by the AP. In addition, the processor (110) can read information regarding the priority conditions of the station (100) included in the communication setting message and request a connection to the AP based on the information regarding the priority conditions of the station (100). The processor (110) of the present invention may refer to the main control unit of the station (100), and, depending on the embodiment, may refer to a control unit for individually controlling a part of the station (100), such as a communication unit (120). That is, the processor (110) may be a modem or a modulator and / or demodulator that modulates and / or demodulates wireless signals transmitted and received from the communication unit (120). The processor (110) controls various operations of wireless signal transmission and reception of the station (100) according to an embodiment of the present invention. Specific embodiments thereof will be described later.

[0091] The station (100) illustrated in FIG. 3 is a block diagram according to an embodiment of the present invention, and the separated blocks represent the elements of the device, logically distinguished. Accordingly, the elements of the device described above may be mounted as a single chip or as multiple chips depending on the design of the device. For example, the processor (110) and the communication unit (120) may be implemented as a single integrated chip or as separate chips. In addition, in an embodiment of the present invention, some components of the station (100), such as the user interface unit (140) and the display unit (150), may be optionally provided in the station (100).

[0092] FIG. 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 an embodiment of the present invention may include a processor (210), a communication unit (220), and a memory (260). In FIG. 4, redundant descriptions of parts of the configuration of the AP (200) that are identical to or corresponding to the configuration of the station (100) of FIG. 3 are omitted.

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

[0094] Next, the memory (260) stores a control program used in the AP (200) and various data associated therewith. This control program may include a connection program that manages the connection of the station. Additionally, the processor (210) controls each unit of the AP (200) and can control the transmission and reception of data between the units. According to an embodiment of the present invention, the processor (210) executes a program for connection with a station stored in the memory (260) and can transmit a communication setting message for one or more stations. At this time, the communication setting message may include information regarding the connection priority conditions of each station. Additionally, the processor (210) performs connection settings according to the connection request of the station. According to one embodiment, the processor (210) may be a modem or a modulator and / or demodulator that modulates and demodulates wireless signals transmitted and received from the communication unit (220). The processor (210) controls various operations of wireless signal transmission and reception of the AP (200) according to an embodiment of the present invention. Specific embodiments thereof will be described later.

[0095] Figure 5 schematically illustrates the process of a station establishing a link with an access point.

[0096] Referring to FIG. 5, the link between STA (100) and AP (200) is established through three stages: scanning, authentication, and association. First, the scanning stage is a stage in which STA (100) obtains connection information of the BSS operated by AP (200). Methods for performing scanning include a passive scanning method, which obtains information by utilizing only beacon messages (S101) periodically transmitted by AP (200), and an active scanning method, in which STA (100) transmits a probe request to AP (S103) and receives a probe response from AP (S105) to obtain connection information.

[0097] STA (100), having successfully received wireless access information during the scanning phase, transmits an authentication request (S107a) and receives an authentication response from AP (200) (S107b) to perform an authentication step. After the authentication step is performed, STA (100) transmits an association request (S109a) and receives an association response from AP (200) (S109b) to perform an association step. In this specification, association basically refers to wireless association, but the present invention is not limited thereto, and association in a broad sense may include both wireless association and wired association.

[0098] Meanwhile, additionally, an 802.1X-based authentication step (S111) and an IP address acquisition step via DHCP (S113) may be performed. In FIG. 5, the authentication server (300) is a server that processes 802.1X-based authentication with the STA (100), and may exist by being physically coupled to the AP (200) or as a separate server.

[0099] Figure 6 shows an example of a CSMA (Carrier Sense Multiple Access) / CA (Collision Avoidance) method used in wireless LAN communication.

[0100] A terminal performing wireless LAN communication performs Carrier Sensing before transmitting data to check whether the channel is busy. If a wireless signal of a certain strength or higher is detected, the channel is determined to be busy, and the terminal delays access to that channel. This process is called Clear Channel Assessment (CCA), and the level determining whether such a signal is detected is called the CCA threshold. If a wireless signal of a strength greater than the CCA threshold is received by the terminal and targets the terminal, the terminal processes the received wireless signal. Meanwhile, if no wireless signal is detected on the channel, or if a wireless signal of a strength lower than the CCA threshold is detected, the channel is determined to be idle.

[0101] When it is determined that the channel is idle, each terminal with data to transmit performs a backoff procedure after an Inter Frame Space (IFS) time, such as Arbitration IFS (AIFS) or PCF IFS (PIFS), depending on the situation of each terminal. According to an embodiment, the AIFS may be used as a configuration to replace the existing DCF IFS (DIFS). Each terminal waits by decreasing the slot time by a random number determined for that terminal during the interval of the channel's idle state, and the terminal that has exhausted all slot times attempts to access the channel. The period during which each terminal performs the backoff procedure in this manner is called the contention window period. At this time, the random number may be referred to as the backoff counter. That is, the initial value of the backoff counter is set by an integer, which is a random number obtained by the terminal. If the terminal detects that the channel is idle during the slot time, the terminal may decrease the backoff counter by 1. Additionally, when the backoff counter reaches 0, the terminal may be allowed to perform channel access on the corresponding channel. Thus, transmission by the terminal may be allowed when the channel is idle during the AIFS time and the slot time of the backoff counter.

[0102] If a specific terminal successfully accesses the channel, the terminal can transmit data through the channel. However, if the terminal attempting access collides with another terminal, the colliding terminals are each assigned a new random number and perform a backoff procedure again. According to one embodiment, the random number newly assigned to each terminal may be determined within a range (2*CW) that is twice the range of the random number (contention window, CW) previously assigned to the terminal. Meanwhile, each terminal attempts access by performing a backoff procedure again in the next contention window period, at which time each terminal performs the backoff procedure starting from the slot time remaining from the previous contention window period. In this way, each terminal performing wireless LAN communication can avoid collisions with each other regarding a specific channel.

[0103] <Examples of Various PPDU Formats>

[0104] Figure 7 shows various standard generational PPDU (physical layer protocol data unit) formats according to an embodiment of the present invention.

[0105] More specifically, FIG. 7(a) illustrates an example of a legacy PPDU format based on 802.11a / g, FIG. 7(b) illustrates an example of an HE PPDU format based on 802.11ax, and FIG. 7(c) illustrates an example of a non-legacy PPDU (i.e., EHT PPDU) format based on 802.11be. Additionally, FIG. 7(d) shows the detailed field configuration of L-SIG and RL-SIG commonly used in the above PPDU formats.

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

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

[0108] Referring to FIG. 7(c), the preamble of the EHT PPDU additionally includes RL-SIG (Repeated Legacy Short Training field), U-SIG (Universal Signal field), EHT / UHR-SIG-A (Extremely High Throughput / Ultra High Reliability Signal A field), EHT / UHR-SIG-A (Extremely High Throughput / Ultra High Reliability Signal B field), EHT-STF (Extremely High Throughput Short Training field), and EHT-LTF (Extremely High Throughput Long Training field) in addition to the legacy preamble. In 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 the EHT preamble. The specific configuration of the non-legacy preamble may be modified according to the EHT PPDU format. For example, EHT-SIG-A and EHT-SIG-B can be used in only some of the EHT PPDU formats.

[0109] As such, PPDUs used in the UHR standard can have a format similar to that of PPDUs used in the EHT standard. This is because the EHT PPDU format defined in 802.11be includes the U-SIG field, which is agreed upon for common use by multiple wireless LAN generations. In this case, the value of the PHY Version Identifier field within the U-SIG field included in the EHT PPDU is 0, while the value of the PHY Version Identifier field within the U-SIG field included in the UHR PPDU can be a non-zero value, such as 1. The EHT PPDU includes the EHT-STF (Extremely High Throughput Short Training field) in the STF field and the EHT-LTF (Extremely High Throughput Long Training field) in the LTF field. The UHR PPDU includes the UHR-STF (Ultra High Reliability Short Training field) in the STF field and the UHR-LTF (Ultra High Reliability Long Training field) in the LTF field.

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

[0111] Referring to FIG. 7(d), the L-SIG includes the L_RATE field and the L_LENGTH field. The L_RATE field consists of 4 bits and indicates the MCS used for data transmission. Specifically, the L_RATE field represents a value among transmission speeds of 6 / 9 / 12 / 18 / 24 / 36 / 48 / 54 Mbps, which are a combination of modulation schemes such as BPSK / QPSK / 16-QAM / 64-QAM and buoyancy rates such as 1 / 2, 2 / 3, and 3 / 4. By combining the information from the L_RATE field and the L_LENGTH field, the total length of the corresponding PPDU can be indicated. In non-legacy PPDU formats, the L_RATE field is set to the minimum speed of 6 Mbps.

[0112] The L_LENGTH field is allocated a total of 12 bits in bytes, allowing it to signal up to 4095, and can represent the length of the corresponding PPDU in combination with the L_RATE field. In this case, legacy terminals and non-legacy terminals may interpret the L_LENGTH field in different ways.

[0113] First, the method by which legacy or non-legacy terminals interpret the length of the corresponding PPDU using the L_LENGTH field is as follows. If the value of the L_RATE field is set to indicate 6 Mbps, 3 bytes (i.e., 24 bits) can be transmitted during 4 µs, which is the duration of one symbol in a 64 FFT. Therefore, by adding the 3 bytes corresponding to the SVC and Tail fields to the L_LENGTH field value and dividing this by 3 bytes, which is the transmission amount of one symbol, the number of symbols based on the 64 FFT after L-SIG is obtained. By multiplying the obtained number of symbols by 4 µs, which is the duration of one symbol, and adding 20 µs, which is required for the transmission of L-STF, L-LTF, and L-SIG, the length of the corresponding PPDU, i.e., the receive time (RXTIME), is obtained. This can be expressed mathematically as Equation 1 below.

[0114]

[0115] At this time, represents the smallest natural number greater than or equal to x. Since the maximum value of the L_LENGTH field is 4095, the length of the PPDU can be set up to a maximum of 5.484ms. Non-legacy terminals transmitting the PPDU must set the L_LENGTH field as shown in Equation 2 below.

[0116]

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

[0118]

[0119] Referring to the above formulas, 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.

[0120] Referring to Fig. 7(e), the U-SIG (Universal SIG) field continues to exist in EHT / UHR PPDUs and subsequent generations of wireless LAN PPDUs, and serves to distinguish which generation the PPDU belongs to, including EHT / UHR. Additionally, the U-SIG field can facilitate spatial reuse of EHT / UHR and subsequent generations of wireless LANs. U-SIG is a 64FFT-based OFDM 2 symbol that can transmit a total of 52 bits of information. Of these, 43 bits, excluding the 9 bits for CRC / Tail, are broadly divided into the VI (Version Independent) field and the VD (Version Dependent) field.

[0121] The VI bits maintain the current bit configuration in the future, allowing current EHT / UHR terminals to obtain information about a PPDU through its VI fields even after subsequent generations of PPDUs are defined. To this end, the VI fields consist of PHY version, UL / DL, BSS Color, TXOP, and Reserved fields. The PHY version ID field is 3 bits long and serves to sequentially distinguish versions of EHT / UHR and subsequent generation wireless LAN standards. The PHY version ID field of an EHT (11be) PPDU has a value of 000b, while the PHY version ID field of a UHR PPDU has a value other than 000b. The UL / DL field distinguishes whether the PPDU is an uplink or downlink PPDU. The BSS Color refers to the BSS-specific identifier defined in 11ax and has a value of 6 bits or more. TXOP refers to the Transmit Opportunity Duration transmitted in the MAC header; by adding it to the PHY header, the length of the TXOP containing the corresponding PPDU can be inferred without the need to decode the MPDU, and it has a value of 7 bits or more.

[0122] The VD field of EHT contains signaling information useful only for PPDUs of version 11be, and can be composed of fields that are common to any PPDU format, such as PPDU format and BW, and fields that are defined differently for each PPDU format. PPDU format is a identifier that distinguishes EHT SU (Single User), EHT MU (Multiple User), EHT TB (Trigger-based), EHT ER (Extended Range) PPDUs, etc.

[0123] The BW field signals five basic PPDU BW options of 20, 40, 80, 160 (80+80), and 320 (160+160) MHz (BWs expressible in the form of 20*2 powers can be referred to as basic BWs), as well as various remaining PPDU BWs configured through Preamble Puncturing. Additionally, a signal can be transmitted in a punctured form of 80 MHz after being signaled at 320 MHz. Furthermore, the punctured and modified channel form can be signaled directly in the BW field, or by utilizing the BW field together with fields appearing after it (e.g., fields within the EHT-SIG field). If the BW field is set to 3 bits, a total of 8 BW signals are possible, so a maximum of only 3 puncturing modes can be signaled. If the BW field is 4 bits, a total of 16 BW signals are possible, so the puncturing mode can signal up to 11.

[0124] The VD field of the UHR is a field that indicates signaling information useful only to the UHR PPDU. However, the information indicated by each field included in the VD field of the UHR PPDU may be the same as or more extended than the information indicated by the field that performs the same role as the VD field of the EHT (11be). For example, the field indicating a puncturing pattern included in the VD field of the UHR PPDU may indicate a more diverse form of pattern than the field indicating a puncturing pattern included in the VD field of the EHT PPDU. Alternatively, the field indicating a puncturing pattern included in the VD field of the UHR PPDU may be interpreted in combination with the BW field. Through this, a more diverse form of puncturing pattern may be indicated.

[0125]

[0126] FIG. 8 shows an EHT / UHR PPDU format according to an embodiment of the present invention.

[0127] The EHT / UHR PPDU format can be indicated by the PPDU Format field of the U-SIG field of the PPDU. FIG. 8(a) shows an EHT / UHR SU PPDU according to an embodiment of the present invention. The EHT / UHR SU PPDU is a PPDU used for single-user transmission between an AP and a single station and may include an EHT-SIG-A field for additional signaling after U-SIG.

[0128] FIG. 8(b) shows an EHT / UHR Trigger-based PPDU according to an embodiment of the present invention. The EHT / UHR Trigger-based PPDU is an uplink PPDU used for transmission in response to a trigger frame and may not have a separate EHT / UHR-SIG-A field after U-SIG.

[0129] FIG. 8(c) shows an EHT / UHR MU PPDU according to an embodiment of the present invention. An EHT / UHR MU PPDU is a PPDU used for transmission to one or more terminals. The EHT / UHR MU PPDU format may include HE-SIG-B after the U-SIG field.

[0130] FIG. 8(d) shows an EHT / UHR ER SU PPDU according to an embodiment of the present invention. The EHT / UHR ER SU PPDU is used for single-user transmission to stations in an extended range. In the EHT / UHR ER SU PPDU format, U-SIG can be repeated in the time axis.

[0131] The EHT / UHR MU PPDU described through FIG. 8(c) can be used by an AP to perform downstream transmission to multiple stations. In this case, the EHT / UHR MU PPDU may include scheduling information for multiple stations to receive the PPDU simultaneously. In this case, the EHT / UHR MU PPDU may convey the AID information of the receiver or sender of the PPDU through the user-specific field of the EHT / UHR-SIG-B. A station that receives the EHT / UHR MU PPDU may perform a spatial reuse operation based on the AID information obtained from the preamble of the PPDU. More specifically, the resource unit allocation (RA) field of the EHT / UHR-SIG-B may include information regarding the resource unit (RU) partitioning form in a specific bandwidth (e.g., 20 MHz) in the frequency domain. Additionally, information on the station assigned to each partitioned resource unit may be transmitted through user-specific fields of EHT / UHR-SIG-B. User-specific fields may include one or more user fields corresponding to each partitioned resource unit.

[0132] Among the multiple divided resource units, the AID of the receiver or sender may be inserted into the user field corresponding to the resource unit where data transmission is performed. A pre-specified Null STA ID may be inserted into the user field corresponding to the remaining resource units where data transmission is not performed.

[0133] Two or more PPDUs described through FIG. 8 may be indicated by the same PPDU format. For example, the value of the U-SIG PPDU format subfield indicating an EHT / UHR SU PPDU and the value of the U-SIG PPDU format subfield indicating an EHT / UHR MU PPDU may be the same.

[0134] Some fields or parts of the information within the fields included in the PPDU format described above may be omitted. This may be referred to as compression mode or compressed mode.

[0135]

[0136] <Wi-Fi 단말의 채널 액세스 방법>

[0137] Since Wi-Fi terminals (APs, non-AP STAs, etc.) communicate using unlicensed bands, they check whether the channel they intend to transmit on is being used by another device before transmitting a frame. Carrier Sense Multiple Access (CSMA) is a channel access method in which a terminal intending to transmit a packet performs Carrier Sense to check whether the channel is being used by another device, and transmits only when it is determined that the channel is not being used by another device (i.e., is idle). Because a terminal using CSMA can perform an action of not attempting transmission when it is confirmed that another device is using the medium (channel) (when it is determined to be busy), transmissions that have already started can be protected from other devices.

[0138] However, multiple terminals that recognize that the medium has been occupied by another device experience a transmission collision by attempting to transmit packets simultaneously when it is confirmed that the media occupancy by the other device has ended (the medium changes to Idle). In other words, as multiple other terminals attempt to transmit packets at the same time as a specific terminal attempts to transmit a packet, the terminal required to receive the packet transmitted by the specific terminal is unable to properly receive and decode the packet due to interference caused by the transmissions performed by the other multiple terminals.

[0139] As described above, CSMA / CA (CSMA with collision avoidance) is a channel access mechanism that prevents multiple terminals from attempting packet transmission simultaneously upon detecting that the medium has changed to Idle. Terminals accessing the medium (channel) using CSMA / CA attempt transmission after waiting for a random amount of time when the observed state of the medium changes to Idle. This random amount of time may be an aslottime (typically 9 us) equal to a random number (random backoff counter) generated by each terminal attempting transmission. In other words, since terminals accessing the medium using CSMA / CA attempt transmission after waiting for different random amounts of time, they attempt transmission at different times, unlike when CSMA alone is used. At this time, if a specific terminal that has waited for the shortest random amount of time after the medium changes to Idle attempts transmission first, other terminals may stop the channel access procedure after realizing that the medium has been occupied (changed to busy) due to said specific terminal. At this time, the specific terminal may perform the operation of decreasing the backoff counter it maintains by 1 at every aslottime while the medium is kept in Idle, and attempt transmission when the backoff counter becomes 0, or when aslottime has passed after the backoff counter has become 0. At this time, the specific terminal that performed the transmission may generate a new random number (new backoff counter) after the transmission is finished, and attempt transmission when the new random number becomes 0 again, or after it becomes 0.

[0140] The CSMA / CA and random backoff procedures briefly explained above apply to both DCF (Distributed Coordination Function) and EDCAF (Enhanced Distributed Channel Access), which are the basic functions used by Wi-Fi terminals when attempting channel access. Since these are well-known and widely utilized methods for accessing unlicensed band channels, further detailed explanations will be omitted.

[0141]

[0142] The DCF and EDCAF utilized by the MAC of a Wi-Fi terminal evaluate the channel condition by considering not only the channel status (idle / busy status) confirmed by each terminal directly performing Physical Carrier Sense (CS), but also the results of Virtual CS. More specifically, even if the result of the Physical CS performed on the channel is idle, if the Virtual CS result is busy, the Wi-Fi terminal considers the channel status to be busy. In this case, the Virtual CS is a channel evaluation method that determines the channel as busy if the Network Allocation Vector (NAV) is not zero. The NAV may be a value maintained for future traffic predicted to occupy the medium. To explain in more detail, when a Wi-Fi MAC receives an RTS / CTS (request-to-send / clear-to-send) frame, it sets the NAV (NAV count) based on the duration information of the received frame, such as the value of the duration field, so that the NAV can be maintained as a non-zero value for the expected time during which the medium will be occupied after the RTS / CTS frame exchange. In other words, the value maintained as NAV decreases over time. If the NAV value of a specific MAC is 0, it can be interpreted as a state where future traffic perceived by the specific MAC no longer occupies the medium. If the NAV is 0, the MAC can determine the virtual CS result as Idle. In this case, the Wi-Fi MAC may set the NAV based on duration values ​​obtained from other received MAC frames, not just RTS / CTS frames.

[0143] The channel evaluation method (determine the state of the medium) that considers both the physical and virtual CS results, briefly explained above, is also a well-known Wi-Fi MAC function, so a detailed explanation is omitted.

[0144]

[0145] <EDCA와 TXOP>

[0146] EDCA provides a mechanism for managing traffic by differentiating it into four types of access categories (ACs) based on traffic characteristics. These four types of ACs are AC_VO (AC Voice), AC_VI (AC Video), AC_BE (AC Best Effort), and AC_BK (AC Background), and each AC can have different contention window (CW), transmit opportunity (TXOP), and AIFSN parameters. Simply put, EDCA is a mechanism that controls the transmission priority of traffic transmitted by utilizing each AC by differentiating the CW, TXOP, and AIFSN parameters for the four types of ACs. To this end, EDCA can map traffic (MSDU) that a MAC must service to one of the four ACs based on the traffic category (TC) or traffic stream (TS). At this time, the traffic mapped to one of the four ACs by EDCA is divided and managed into four queues for each AC. In this case, the four queues may be logically separated queues rather than physically separated queues.

[0147] AC_VO is an AC that can be used for traffic that is vulnerable to transmission delays, such as voice traffic, where the absolute amount of traffic is not large. It has relatively small CW and AIFSN parameter values ​​to increase the probability of being serviced preferentially over traffic from other ACs. The TXOP parameter of AC_VO is limited to a value relatively smaller than the TXOP parameter of other ACs, so only a shorter transmission time than other ACs is guaranteed.

[0148] AC_VI is an AC that is more robust to transmission delay than voice traffic, but can be used for traffic such as video that still requires low-latency transmission and needs to handle a large amount of traffic. AC_VI has CW and AIFSN parameter values ​​that are larger than AC_VO but smaller than other ACs, and instead, TXOP is about twice as long as AC_VI.

[0149] AC_BE is an AC that can be used for traffic robust to transmission delay, and most general traffic, excluding voice data and streaming video data, can be classified as AC_BE. AC_BE uses larger values ​​for the CW and AIFSN parameters than AC_VO and AC_VI. Additionally, AC_BE does not have a separate TXOP. Therefore, traffic corresponding to AC_BE cannot be used in a TXOP transmission sequence in which a PPDU is transmitted, an ACK is received, and a PPDU is transmitted again after SIFS.

[0150] AC_BK is an AC that is robust to transmission delay, similar to AC_BE, but can be used for traffic with a lower priority than BE traffic. AC_BK uses the same CW parameter values ​​as AC_BE, and uses larger AIFSN parameter values ​​than AC_BE. Additionally, traffic corresponding to AC_BK does not have a separate TXOP, just like AC_BE, so it cannot be used in a TXOP transmission sequence.

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

[0152] In addition, the default CW (CWmin, CWmax), AIFSN, and TXOP parameters for each of the four types of EDCA ACs described above are defined in the standard, and the parameter values ​​of each AC can be changed by the AP and different values ​​can be used for each BSS.

[0153]

[0154] When utilizing the EDCA mechanism, Wi-Fi traffic is stored in one of four queues corresponding to four ACs, and can be transmitted to a destination device only if the AC containing the traffic wins the channel access competition against another AC. In this case, during the channel access competition between ACs, each AC competes using the access parameters (CW[AC], AIFSN[AC]) assigned to it, and the channel access competition operation performed by each AC is the same as DCF. In this case, if a specific AC does not have any traffic to transmit in the queue, said specific AC may not participate in the competition.

[0155] However, as mentioned above, since the CW and AIFSN parameter values ​​utilized by each AC differ, the AC_VO with the smallest CW and AIFSN parameters has a high probability of winning the channel access competition against other ACs, and therefore, it is highly likely that the traffic of AC_VO will be served preferentially over the traffic of other ACs.

[0156] In addition, the EDCA mechanism stipulates internal competition rules, such as when an internal collision occurs between ACs, the AC with higher priority wins and increases the CW of the other AC that caused the collision, and rules for configuring PPDUs by including traffic from ACs other than the AC that won the competition (primary AC), but since these details are not significantly relevant to the proposal of the present invention, a detailed explanation is omitted.

[0157] As described above, EDCA provides the EDCA TXOP (EDCA Transmission Opportunity) function, along with the ability to operate differentiated ACs based on the type of traffic (frames, packets, etc.) to enhance QoS. EDCA TXOP refers to the time during which a specific AC's EDCAF (EDCA Function) can control the medium without interference from other devices during the TXOP duration when it acquires a channel access opportunity, that is, when it becomes a TXOP holder. At this time, the EDCA TXOP may be limited by a TXOP limit advertised by the AP. The TXOP holder must ensure that the transmission of their own transmission and the transmission of any response frames resulting from their transmission are completed within the TXOP limit.

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

[0159] At this time, traffic (packets, frames, etc.) of an AC other than the specific AC that is the TXOP holder may also be transmitted together within the TXOP acquired by the TXOP holder (specific AC) when certain conditions are satisfied. The transmission of traffic of an AC other than the TXOP holder within the TXOP may be an operation due to TXOP sharing between ACs, and details regarding the above specific conditions are omitted as they are not relevant to the present invention.

[0160]

[0161] As described above, the TXOP holder can perform continuous frame transmission within the TXOP without performing a separate channel access procedure. This operation can be achieved when other terminals understand and protect the TXOP segment acquired by the TXOP holder. That is, in order for the TXOP holder to acquire medium control authority over the EDCA TXOP segment, a procedure may be required to notify other terminals so that they can recognize the acquired TXOP segment.

[0162] To this end, a terminal (AC) that has become a TXOP holder or has started transmission after completing the channel access procedure may attempt to enable other terminals to recognize the TXOP period by transmitting an RTS frame. At this time, the RTS frame refers to a frame in which the Type subfield of the Frame Control field of the MAC frame header (the fourth bit (B3) and third bit (B2) of the Frame Control field) is set to 01b (Type = Control frame), and the Subtype subfield of the Frame Control field (the eighth bit (B7), seventh bit (B6), sixth bit (B5), and fifth bit (B4) of the Frame Control field) is set to 1011b. Another terminal that receives the RTS frame from the TXOP holder may set a NAV based on information related to the duration included in the RTS frame, for example, the value of the Duration field. The set NAV may be maintained as a non-zero value for the duration corresponding to the TXOP of the TXOP holder. However, the terminal designated as the destination device of the RTS frame must respond with a CTS frame instead of setting the NAV based on the information in the RTS frame. In this case, the destination device of the RTS frame transmitted to initiate the TXOP is the TXOP responder, and must transmit a CTS frame as a response to the RTS (after the RTS frame is received and SIFS). In this case, the Duration field of the responding CTS frame is set to a value calculated as: the value indicated in the Duration field of the received RTS frame - the CTS frame transmission time - SIFS. Terminals that receive the CTS frame may set the NAV based on information related to the duration included in the CTS frame (e.g., the value of the Duration field).

[0163] Accordingly, the NAV of the terminal that received the RTS frame from the TXOP holder and the terminal that received the CTS frame from the TXOP responder are set to 0 after the TXOP acquired by the TXOP holder is terminated. Through this, the Wi-Fi MAC mechanism can protect the TXOP holder and the TXOP responder from exchanging multiple frames during the TXOP without interference.

[0164] However, if the TXOP holder transmits an RTS frame as a non-HT duplicate PPDU across the primary 80 MHz band, but the CTS frame (non-HT duplicate PPDU) responded to by the TXOP responder is responded only in the primary 40 MHz band, the TXOP holder may use only the primary 40 MHz or a bandwidth less than the primary 40 MHz, e.g., primary 20 MHz, for frame exchange during the acquired TXOP. The CH_BANDWIDTH (a type of TXVECTOR parameter) of the PPDU transmitted by the TXOP holder must be set to a value equal to or smaller than the CH_BANDWIDTH_IN-NON_HT (a type of RXVECTOR parameter) of the received CTS frame. In this case, the RTS frame may be an RTS frame that allows the CTS frame to be responded to with a bandwidth smaller than the bandwidth in which the RTS frame was transmitted. The RTS frame may be an RTS frame transmitted with DYN_BANDWIDTH_IN_NON_HT (a type of TXVECTOR parameter) set to Dynamic. If the RTS frame is transmitted from the TXOP holder with DYN_BANDWIDTH_IN_NON_HT set to Static, the TXOP responder may respond with a CTS frame with the same BW as the BW at which the RTS frame was received.

[0165]

[0166] FIG. 9 shows a transmission / TXOP protection method using an RTS frame and a CTS frame according to an embodiment of the present invention.

[0167] Before transmitting the PPDU, the first station (STA1) transmits an RTS frame to the second station (STA2), which is the destination device of the PPDU, and the second station (STA2) responds with a CTS frame after SIFS, after acknowledging that the received RTS frame is an RTS frame with itself as the destination device.

[0168] STA1_Neighbor, a neighbor station (Neighbor STA) of the first station (STA1), receives an RTS frame transmitted by the first station (STA1) and sets the NAV based on the value indicated by the Duration field of the RTS frame. STA2_Neighbor, a neighbor station of the second station (STA2), receives a CTS frame transmitted by the second station (STA2) and sets the NAV based on the information indicated by the Duration field of the CTS frame. After receiving the RTS / CTS frames, STA1_Neighbor and STA2_Neighbor determine that the virtual CS is busy while the set NAV (counter) remains a non-zero value and perform actions such as not decreasing the backoff counter. Consequently, the neighbor terminal that receives the RTS / CTS frame does not attempt to transmit during the period in which the NAV remains a non-zero value. Therefore, the first station (STA1) and the second station (STA2) can be free from interference by surrounding terminals while exchanging PPDU and Ack frames.

[0169] Even if the first station (STA1) and STA2_Neighbor are in a hidden relationship where no signal is detected from each other's transmission, STA2_Neighbor can perform an operation that takes into account that the channel (channel, WM, Wireless medium) is in use while the first station (STA1) is transmitting a PPDU.

[0170]

[0171] <MU-RTS 트리거 프레임을 이용한 TXOP 보호>

[0172] In 11ax (6th generation Wi-Fi, Wi-Fi 6, HEW, High Efficiency WLAN), a MU-RTS Trigger / CTS frame exchange procedure is defined to add a feature that allows an AP to initiate a TXOP using a MU-RTS trigger frame (hereinafter referred to as MU-RTS, MU-RTS frame) and protect the TXOP frame exchange procedure. A MU-RTS frame is a type of trigger frame; upon receiving a MU-RTS frame, a station whose AID12 (the LSB 12 bits of the Association ID) is indicated in the User field included in the MU-RTS frame simultaneously responds with a CTS frame. When an AP protects a TXOP using a MU-RTS frame, multiple stations respond with CTS frames, thereby protecting the TXOP from the peripheral devices of each of the multiple stations that are the destination devices of a DL MU PPDU (Down-link multi-user PPDU). Additionally, MU-RTS frames can be used to protect an UL MU PPDU. More specifically, before requesting a Trigger-based PPDU (TB) from multiple stations via a trigger frame, the AP can transmit a MU-RTS frame to cause multiple stations responding to the TB PPDU to respond to a CTS frame. At this time, the CTS frames responded to by multiple stations induce the surrounding stations of each station to set up NAVs that protect the TB PPDU and the Ack frames (Ack, Block Ack, etc.) to be transmitted after the TB PPDU, thereby allowing legacy stations (STAs) that cannot recognize (interpret, decode) the trigger frame and the TB PPDU to not perform channel access during the packet switching sequence period (or TXOP) initiated by the trigger frame.

[0173]

[0174] FIG. 10 shows a transmission / TXOP protection method using MU-RTS frames and CTS frames according to an embodiment of the present invention.

[0175] In the embodiment of FIG. 10, prior to transmitting the MU PPDU, the AP transmits a MU-RTS frame to the first station (STA1) and the second station (STA2), which are the destination devices of the MU PPDU, and the first station (STA1) and the second station (STA2) receive the MU-RTS frame and, after SIFS, each respond to the MU-RTS frame with a CTS frame.

[0176]

[0177] After receiving the CTS frame transmitted by the first station (STA1), the neighboring station STA1_Neighbor sets the NAV based on the information indicated by the Duration field of the CTS frame. After receiving the CTS frame transmitted by the second station (STA2), the neighboring station STA2_Neighbor sets the NAV based on the information indicated by the Duration field of the CTS frame. While the NAV (counter) set by STA1_Neighbor and STA2_Neighbor remains a non-zero value after receiving the CTS frame, the Virtual CS (Virtual Carrier Sense) determines it to be busy and performs actions such as not decreasing the backoff counter. Therefore, the neighboring terminal that received the CTS frame does not attempt to transmit during the period in which the NAV remains a non-zero value. This allows the AP to transmit MU PPDU and the first station (STA1) and the second station (STA2) to transmit Ack frames without being interfered with by surrounding terminals.

[0178] The trigger frame described above is a frame type defined in 11ax, in which the Type (fourth bit (B3) and third bit (B2)) and Subtype (eighth bit (B7), seventh bit (B6), sixth bit (B5), and fifth bit (B4)) subfields of the Frame Control field are set to 01b and 0010b, respectively. The trigger frame is a frame of the Control Type with the Type subfield of the Frame Control field being 01b, and the Subtype value 0010 indicates that it is a Trigger frame type. In 11ax, trigger frames are defined to allow an AP to request response frames from multiple stations at once, and MU-RTS frames are used for an AP to request CTS frames from multiple stations (non-AP STAs). Other Trigger Types, excluding the MU-RTS frame, include the Basic Trigger frame requesting UL MU PPDU, the BRP Trigger frame requesting a Beamforming Report (Beamforming Report Poll Trigger frame), the MU-BAR Trigger frame (BlockAck request), the BSRP Trigger frame requesting a Buffer Status Report (Buffer Status Report Poll Trigger frame), the GCR MU-BAR Trigger frame, the BQRP (Bandwidth Query Report Poll) Trigger frame, and the NDP Feedback Report Poll Trigger frame. Since other Trigger Types, excluding the MU-RTS frame, are not related to the content of the present invention, a detailed description is omitted.

[0179] <Transmission delay problem occurring during the time the medium is occupied>

[0180] As mentioned above, in conventional Wi-Fi, the concept of TXOP was introduced to allow a STA (AP or non-AP STA) that has acquired channel access rights to continue its frame exchange sequence without being interrupted by other STAs during the transmission opportunity (TXOP), which is the time interval during which the rights were acquired. The STA's frame exchange sequence during the TXOP interval is protected through a Network Allocation Vector (NAV) that is maintained as a non-zero value during the time interval corresponding to the TXOP. In other words, TXOP protection is achieved through the setting of the NAV.

[0181] The NAV setting method considered in conventional Wi-Fi to guarantee the authority of TXOP holders appears to have aspects that make it difficult to achieve the low-latency transmission (transmission of low-latency traffic) targeted by UHR. To explain in more detail, the channel access procedure of an STA that needs to transmit low-latency traffic can be interrupted by the NAV set by a frame transmitted by another STA, resulting in a delay in the transmission of low-latency traffic. In other words, the conventional Wi-Fi channel access mechanism, which suspends the channel access procedure to protect the TXOPs of other STAs, can act as a factor that hinders the transmission of low-latency traffic, which must be completed within a short period of time. Furthermore, if a PPDU transmitted by a specific STA occupies the medium for a very long time—that is, if a specific STA transmits a large PPDU—channel access by other STAs is restricted during the time that the PPDU occupies the medium. If the channel access procedure of an STA that needs to transmit low-latency traffic is delayed by a long PPDU transmitted by another STA, the low-latency traffic may not be transmitted in a timely manner.

[0182] Therefore, in order to enhance support for the low-latency traffic targeted by UHR, methods must be introduced to resolve the channel access delay problem caused by the media being occupied by other STAs.

[0183] FIG. 11 shows an embodiment in which the transmission of traffic of other APs is delayed by the TXOP (transmission opportunity) of an AP according to an embodiment of the present invention.

[0184] Referring to FIG. 11, a TXOP for transmitting and receiving frames of AP 1 may be set due to the transmission of an RTS frame of AP 1. In this case, the NAV of AP 2 may be set by the RTS frame of AP 1, and the NAV of AP 3 may be set by the CTS frame of STA 1 for AP 1. In this case, the transmission and reception of frames of AP 2 and AP 3 may be restricted by the set NAV.

[0185] Specifically, in FIG. 11, after AP 1 obtains channel access rights through a channel access procedure, it can become a TXOP holder by transmitting an RTS frame to STA 1, which is an associated STA with AP 1, and receiving a CTS frame in response to the RTS frame from STA 1. In this case, AP 1 can transmit DL PPDUs to STA 1 during the set TXOP and receive an Ack frame in response.

[0186] During the time interval in which AP1 acquires the TXOP, AP2 and AP3 each have NAVs set by the RTS and CTS frames, respectively; therefore, the NAV values ​​do not reach 0 until AP1's TXOP ends. Consequently, although LL (Low Latency) traffic packets (traffic packets requiring low latency) are generated after AP2 receives the RTS frame, it cannot process the LL traffic because channel access is restricted until AP1's TXOP ends. Similarly, AP3 cannot process the LL traffic packets generated after receiving the CTS frame until AP1's TXOP ends.

[0187] <Multiple AP Cooperative Operations>

[0188] The reason the concept of TXOP was introduced in conventional Wi-Fi is to ensure that a STA that has acquired channel access rights can continue its frame exchange sequence for a certain period without being interrupted by other STAs. Through this, each STA can secure as much frame exchange time as it desires within a maximum time limit (TXOP limit) when it acquires channel access rights. This can be understood as a method that allows each STA to perform more energy-efficient operations by securing the minimum throughput obtainable through a single channel access procedure. However, in terms of supporting the low-latency transmission targeted by UHR, the phenomenon where other STAs are restricted from accessing the channel during a TXOP acquired by a specific STA can act as a problem that makes supporting low-latency transmission difficult. Therefore, in UHR, it is necessary to appropriately adjust the conventional TXOP acquisition and operation methods to ensure that low-latency transmission by each STA can be performed in a timely manner.

[0189] In the next-generation standard UHR, operations are being considered to enhance the service of each AP to its respective BSS through coordination among APs, or to enhance the service to STAs located at the edge of a specific AP's coverage that experience significant signal attenuation. In particular, among APs performing coordinated operations, methods are being sought to increase wireless LAN efficiency and improve stability through the sharing of wireless resources (frequency resources and / or time resources) and / or coordinated transmission (cooperative transmission to a single STA).

[0190] As an example of sharing wireless resources among APs, it is possible for a specific AP to allocate (share) some or all of the time and frequency resources of a TXOP acquired by it to another AP, and the other AP can use the allocated resources to perform services for STAs belonging to its BSS. This may be made possible by requirements and related information exchanged between the specific AP that acquired the TXOP and the other AP. More specifically, the other AP may notify the specific AP in advance of information regarding the time at which it must perform transmission and the amount of necessary wireless resources (frequency BW or RU (resource unit), etc.), and when the specific AP acquires the TXOP, it may allocate (share) the wireless resources it acquired to the other AP based on the information previously provided by the other AP.

[0191] That is, an AP operating a BSS can acquire a TXOP for a certain period of time through a channel access procedure. In this case, at least one AP operating a different BSS from the AP that acquired the TXOP (the first AP) may notify the first AP of information such as the time of traffic transmission and reception, the type of traffic (e.g., traffic ID, etc.), and the amount of required radio resources (frequency resources and / or time resources) (e.g., required frequency band and / or time). This information may be received before the first AP acquires the TXOP. Additionally, this information may be transmitted to each other before a specific AP acquires the TXOP. If there are two or more APs, the first AP may select an AP among the two or more APs to share part or all of the acquired TXOP based on the characteristics of the traffic transmitted from the two or more APs (e.g., traffic urgency (or priority), delay bound, amount of required radio resources, traffic identifier (ID) and / or access category (AC)). Afterward, AP 1 may share some or all of the TXOP it has acquired with a selected AP (the second AP), and the second AP may exchange traffic through the shared TXOP. If the traffic exchange of the second AP is completed before the end of the shared TXOP, the second AP may return the shared TXOP to the first AP.

[0192] At this time, a specific AP that has acquired the TXOP (the TXOP holder) may be called a Sharing AP, and another AP that has been allocated (shared) wireless resources from the specific AP may be called a Shared AP.

[0193] The process of APs exchanging information regarding wireless resources they require from one another, as described above, can be understood as a multi-AP coordination process. Furthermore, the action of a specific AP allocating (sharing) wireless resources it has acquired in consideration of the requirements of other APs, and the action of the other AP performing transmission using these resources, can be understood as a multi-AP coordinated operation.

[0194] <AP간의 TXOP 공유 절차>

[0195] As described above, APs supporting the multi-AP cooperation procedure can reduce the period during which they can access the channel by sharing the wireless resources they have secured with other APs and receiving resources from the other APs. The procedure of sharing the time interval of the TXOP acquired by the Sharing AP with the Shared AP can be understood as a TDMA (Time Division Medium Access) procedure between APs.

[0196] Sharing time resources (e.g., TXOP) among APs in this way can be called Coordinated TDMA (C-TDMA), and the C-TDMA procedure can be performed in a manner similar to the TXOP Sharing procedure defined in 11be.

[0197] Specifically, the APs operate different BSSs. In this case, a specific AP (the first AP) among the APs can acquire a TXOP (for example, by acquiring channel access rights). The first AP can share a second TXOP, which is part or all of the acquired TXOP (the first TXOP), with a specific AP (the second AP) among at least one AP operating a different BSS. At this time, the second TXOP may be included in the first TXOP. For example, the start time of the second TXOP may be after the start time of the first TXOP, and the end time of the second TXOP may be the same as or earlier than the end time of the first TXOP. The first AP may transmit a frame (for example, an initial frame or a trigger frame, etc.) to notify at least one AP to share the second TXOP, which is part or all of the first TXOP it acquired. At this time, APs may transmit and receive to each other the characteristics of the traffic to be transmitted and received (e.g., traffic urgency (or priority), delay bound, amount of required wireless resources, traffic identifier (ID) and / or access category (AC) at least one) before transmitting the trigger frame. The trigger frame for the second TXOP sharing may include information related to the size of the second TXOP and a duration field. The duration field may be set based on the SIFS plus the length of time required for the transmission of the TB PPDU transmitted in response to the trigger frame.

[0198] If at least one AP desires to share the second TXOP based on a received trigger frame, it may transmit a triggered-based physical layer protocol data unit (TB PPDU) to the first AP based on the trigger frame. At this time, the at least one AP may choose whether to receive the second TXOP based on the information of the second TXOP. The TB PPDU may include at least one of the traffic ID and AC of the traffic that the AP transmitting the TB PPDU will transmit and receive during the second TXOP. Subsequently, the first AP transmits a response frame as a response to the TB PPDU to a specific AP (the second AP) among the at least one AP that will share the second TXOP. If there are two or more APs that wish to share the second TXOP, the first AP may select the second AP to share the second TXOP based on the urgency of the traffic that the two or more APs intend to transmit during the second TXOP (e.g., whether the traffic is low-latency traffic, priority, AC, etc.). Afterwards, the second AP can transmit and receive traffic during the second shared TXOP.

[0199] If the transmission and reception of traffic is completed before the second TXOP shared by the second AP ends, the second AP may return the TXOP shared by the first AP before the second TXOP ends. Subsequently, when the second AP performs a new channel access procedure, it may receive a penalty for the channel access procedure. For example, after returning the second TXOP, the second AP may perform channel access using MU EDCA (multi-user enhanced distributed channel access) parameters. Alternatively, when the second AP selects a new back-off counter to perform new channel access within a contention window, it may compare the back-off counter before receiving the second TXOP with the new back-off counter and use the larger value to perform new channel access.

[0200] The TXOP sharing procedure defined in 11be is described as follows.

[0201] 1. The AP initiates a procedure to allocate a portion of the time included in the TXOP it has acquired to a non-AP STA associated with it. In this case, the AP transmits a MU-RTS TXS trigger frame, which includes the User Information field (or user info field) of the non-AP STA to which the TXOP will be allocated. The AID12 of the User Information field may be set to a value related to the non-AP STA's AID. The User Information field includes an Allocation Duration subfield, and the AP's TXOP is shared with the non-AP STA for the time specified by the Allocation Duration subfield. At this time, the Allocation Duration subfield may specify the time in units of 16 us.

[0202] Additionally, the AP indicates whether only the transmission of UL PPDU is allowed or whether the transmission of P2P PPDU is also allowed during the shared time interval (Shared TXOP) through the Triggered TXOP Sharing Mode subfield included in the MU-RTS TXS trigger frame. Specifically, the AP may allow only the transmission of UL PPDU by indicating the Triggered TXOP Sharing Mode subfield as 1, or allow both the transmission of UL PPDU and / or P2P PPDU (PPDU including MPDU that does not have the AP as the destination device) by indicating the Triggered TXOP Sharing Mode subfield as 2.

[0203] 2. A Non-AP STA whose user information field is specified via a MU-RTS TXS trigger frame responds to a CTS frame and, for the time specified via the allocated duration subfield, transmits a PPDU of the type allowed for transmission via the triggered TXOP sharing mode subfield. For example, 1) if the triggered TXOP sharing mode subfield of the received MU-RTS TXS trigger frame is 1, the Non-AP STA transmits a PPDU (non-TB PPDU, a PPDU that is not a Trigger Based PPDU (i.e., UL SU PPDU)) with the AP as the destination device for the allocated time. However, 2) if the triggered TXOP sharing mode subfield of the received MU-RTS TXS trigger frame is 2, the Non-AP STA transmits a PPDU (non-TB PPDU) with the AP as the destination device or another STA (e.g., a P2P peer STA) as the destination device for the allocated time. A non-AP STA that has received an EHT Capabilities element from an AP in which the triggered TXOP sharing mode subfield of the received MU-RTS TXS trigger frame is 2 and the TXOP Return Support In TXOP Sharing Mode 2 subfield is set to 1 can return the shared TXOP to the AP by transmitting QoS Data or a QoS Null frame (included in the HE variant HT Control field) in which the RDG / More PPDU subfield is set to 0.

[0204] A non-AP STA allocated time via a MU-RTS TXS trigger frame may ignore the Intra-BSS NAV until the allocated time expires or it returns a TXOP. That is, the non-AP STA can transmit non-TB PPDUs during the Shared TXOP (time allocated by the MU-RTS TXS trigger frame) even if its Intra-BSS NAV is not zero. A non-AP STA allocated time via a MU-RTS TXS trigger frame may transmit non-TB PPDUs during the Shared TXOP with a BW equal to or smaller than the BW of the CTS frame it transmitted in response to the MU-RTS TXS trigger frame. In this case, the BW of the CTS frame refers to the TXVECTOR parameter CH_BANDWIDTH_IN_NON_HT value used when transmitting the CTS frame.

[0205] 3. An AP that has shared a TXOP with a non-AP STA by transmitting a MU-RTS TXS trigger frame can reclaim the TXOP and transmit the next PPDU when the time allocated to the non-AP STA is about to expire or when an explicit instruction to return the TXOP is executed by the non-AP STA. Additionally, the AP can transmit a response frame (PPDU containing the response frame) if an explicit request for a response frame transmission is made by the non-AP STA. In this case, 1) an AP that has transmitted a MU-RTS TXS trigger frame with the triggered TXOP sharing mode subfield set to 1 can reclaim the Shared TXOP by transmitting the next PPDU when the medium at the TxPIFS slot boundary is determined to be idle (confirmed as idle by the CS mechanism) after the frame (PPDU) transmitted by the non-AP STA to which it has assigned the TXOP or the response frame (PPDU) transmitted by itself to the non-AP STA. That is, a Shared TXOP allocated via a MU-RTS TXS trigger frame with the triggered TXOP sharing mode subfield set to 1 can be reclaimed by the AP when the medium is identified as idle during PIFS. 2) An AP that transmits a MU-RTS TXS trigger frame with the triggered TXOP sharing mode subfield set to 2 can reclaim the Shared TXOP if it receives a CAS control field (CAS Control field) with the RDG / More PPDU subfield set to 0 from a non-AP STA.

[0206] When a Shared TXOP assigned to a non-AP STA expires, the AP may transmit the next PPDU after PIFS from the expiration time. When the expiration of a Shared TXOP assigned to a non-AP STA is imminent, the AP may transmit its next PPDU after PIFS if the response frame (PPDU) it transmitted to the non-AP STA or the frame (PPDU) transmitted by the non-AP STA has ended. The meaning of the time when expiration is imminent is that only a time less than PIFS remains from the expiration of the Shared TXOP.

[0207] As described above, the TXOP sharing procedure using the MU-RTS TXS trigger frame defined in 11be allows the AP to allocate a portion of the time interval included in the TXOP it has acquired to a non-AP STA, thereby enabling the non-AP STA to transmit a UL PPDU instead of a TB PPDU, or to enable the non-AP STA to perform transmission to another STA.

[0208] The TXOP sharing procedure between APs can also be performed in the same or similar manner as the TXOP sharing procedure defined in 11be. That is, the first AP may allocate a portion of the time interval included in the TXOP it has acquired to the second AP, and to do so, the first AP may transmit a frame of a specific format to the second AP. The frame of the specific format may have a configuration that includes an identifier for the second AP (e.g., the second AP's MAC address or Coordination ID (an ID related to the coordination performed by the first AP and the second AP)) and a value related to the time allocated to the second AP. Specifically, the frame of the specific format may be a variant of a trigger frame. In this case, the frame of the specific format may be a MU-RTS TXS trigger frame.

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

[0210] A trigger frame consists of a MAC header including a Frame Control field, a Common information field (or Common info field), a User Information List field (or User Info List field), a Padding field, and an FCS (Frame Check Sequence) field.

[0211] The frame control field includes a type subfield and a subtype subfield, and the trigger frame has the two subfields set to 01 and 0010, respectively.

[0212] Common information fields include a Trigger Type subfield for indicating the type of trigger frame, a UL Length subfield for indicating the length of the UL transmission being responded to, and other details are explained in detail through an embodiment of FIG. 12.

[0213] The user information list field includes zero or one or more user information fields containing information for indicating the destination device of the trigger frame. In this case, in addition to the information indicating the destination device, the user information field includes parameter information (UL DCM, UL MCS, etc.) that the destination device must utilize when transmitting a response frame after receiving the trigger frame, depending on the type of the trigger frame. Detailed information regarding the user information field is explained in detail through an example of the user information field described below.

[0214] A padding field is added for the purpose of providing time for the destination devices of the trigger frame to prepare a response frame (e.g., UL TB PPDU, CTS frame, etc.) after receiving the trigger frame, and the AP transmitting the trigger frame can adjust the length of the padding field considering the performance of the destination devices. Additionally, the length of the padding field may be added or adjusted to align the end time of the PPDU containing the trigger frame with the PPDU transmitted together on another Link, but a detailed explanation is omitted as this is not relevant to the content that the present invention aims to provide.

[0215] The FCS field contains a 32-bit Cyclic Redundancy Code (CRC) and is a value calculated by including the MAC header and the Frame Body field. Since the function and setting method of the FCS field in a trigger frame are the same as the function and setting method of the FCS field included in a conventional MAC frame, a separate explanation is omitted.

[0216] FIG. 13 shows the format of a common information field of a trigger frame according to an embodiment of the present invention.

[0217] The trigger type subfield (4-bit) is used to indicate the type or variant of the trigger frame, and if the trigger type subfield is 0, it indicates Basic; 1 indicates BFRP (Beamforming Report Poll); 2 indicates MU-BAR; 3 indicates MU-RTS; 4 indicates BSRP (Buffer Status Report Poll); 5 indicates GCR MU-BAR; 6 indicates BQRP (Bandwidth Query Report Poll); and 7 indicates NFRP (NDP Feedback Report Poll).

[0218] The UL length subfield indicates the value that must be set in the L-SIG length field of the TB PPDU that is responded to through the trigger frame.

[0219] The More TF subfield is used to indicate whether there are more trigger frames to be transmitted after the corresponding trigger frame.

[0220] The CS Required subfield indicates whether the destination device of the trigger frame must perform CS (Physical & Virtual CS, ED & NAV) when transmitting a response frame, and the STA transmitting the response frame after receiving a trigger frame in which the CS Required subfield is indicated as 1 must perform CS.

[0221] The UL BW subfield indicates the BW value that STAs responding to the TB PPDU after receiving a trigger frame must indicate to the Preamble (e.g., HE-SIG-A or U-SIG).

[0222] The GI And HE / EHT / UHR-LTF type subfield indicates the GI (Guard interval) and HE / EHT / UHR-LTF values ​​of the TB PPDU to be responded to. The bits corresponding to the GI And HE / EHT / UHR LTF Type subfield are used in the triggered TXOP shared mode subfield when the format of the trigger frame is MU-RTS, and details regarding the triggered TXOP shared mode subfield are explained in more detail through an embodiment of FIG. 16.

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

[0224] The UL STBC subfield indicates whether STBC encoding should be applied to the TB PPDU being responded to, and is set to 1 if STBC encoding should be applied. However, the UL STBC subfield of the trigger frame responding with the EHT TB PPDU is reserved.

[0225] The LDPC Extra Symbol Segment subfield indicates whether the LDPC extra symbol segment should appear in the TB PPDU being responded to, and if the LDPC Extra Symbol Segment subfield is indicated as 1, the LDPC extra symbol segment should appear in the TB PPDU.

[0226] The AP Tx Power subfield indicates a value related to the transmit power of the AP used when transmitting the trigger frame. The STA can perform Power Control when responding to a response frame based on the value indicated in the AP Tx Power subfield.

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

[0228] The UL Spatial Reuse subfield consists of four spatial reuse subfields and indicates the values ​​to be set in the spatial reuse fields (HE-SIG-A) of the HE TB PPDU to be responded to.

[0229] The Doppler subfield indicates whether the TB PPDU to be responded to includes a midamble. However, the Doppler subfield may be reserved for the trigger frame that responds the EHT TB PPDU. In this case, the meaning that the subfield is reserved may be that the STA responding the EHT TB PPDU after receiving the trigger frame operates without considering the existence and setting value of the said subfield.

[0230] The HE / EHT P160 subfield indicates whether the HE TB PPDU or the EHT TB PPDU is responded to the channel corresponding to P160 MHz of the TB PPDU that is responded to the corresponding trigger frame.

[0231] The EHT Special user information field Flag subfield indicates whether, among the user information fields, the user information field designated by the AID12 subfield as 2007 (Special user information field for EHT) appears. At this time, the user information field designated by the AID12 subfield as 2007 contains information related to the value that must be indicated in the Preamble of the EHT TB PPDU.

[0232] The UHR Special User Information Field Flag subfield indicates whether, among the UHR Info fields, the user information field (Special User Information Field for UHR) indicated by the AID12 subfield 2006 (or 2008) appears. In this case, the user information field indicated by the AID12 subfield 2006 (or 2008) contains information related to the value that must be indicated in the preamble of the UHR TB PPDU.

[0233] The Trigger Dependent Common Info subfield is a field that appears only when the type of trigger frame indicated by the trigger type field is a Basic trigger frame or an NFRP trigger frame.

[0234] The EHT / UHR P160 subfield indicates whether the EHT TB PPDU or the UHR TB PPDU is responded to the channel corresponding to the P160 MHz of the TB PPDU that responds to the corresponding trigger frame. At this time, the EHT / UHR P160 subfield can be set to 0 or 1 only when the HE / EHT P160 subfield is indicated as 0, and when the HE / EHT P160 subfield is indicated as 1, it is always indicated as a specific value (e.g., 0 or 1). This means that when the HE / EHT P160 subfield indicates that the HE PPDU appears in the Primary 160 MHz band (i.e., is set to 1), the information indicated by the EHT / UHR P160 subfield is ignored, and it becomes a Reserved subfield set to a pre-set value (e.g., 0 or 1).

[0235] FIG. 14 shows the format of the user information field of a trigger frame according to an embodiment of the present invention.

[0236] The AID12 subfield indicates information regarding which STA the corresponding user information field is for. That is, a STA in which the AID12 subfield of a specific user information field is indicated with a value identical to its own AID can recognize that the corresponding trigger frame includes itself as a destination device. In this case, the AID12 subfield of the UHR variant user information field can be set to 1 to 2005 (1 to 2006 for the EHT variant user information field, and 1 to 2007 for the HE variant user information field) when indicating one associated STA.

[0237] At this time, the AID12 subfield can be set to 0 when assigning one or more RA-RUs (Random Access RUs) to associated STAs. That is, STAs associated with the AP may attempt to transmit TB PPDU using RA-RUs if, in the received trigger frame, there is no user information field of AID12 where their AID is indicated, and there is a user information field where AID12 is indicated as 0.

[0238] In this case, the AID12 subfield can be set to 2045, 2044, or 2043 when assigning one or more RA-RUs to unassociated STAs. That is, STAs not associated with an AP may attempt to send a TB PPDU using an RA-RU if a user information field where AID12 is indicated as 2045 or 2044 exists in the received trigger frame. In this case, the STA responding with the TB PPDU via the RA-RU may respond with an HE TB PPDU if AID12 is indicated as 2045, an EHT TB PPDU if AID12 is indicated as 2044, and a UHR TB PPDU if AID12 is indicated as 2043.

[0239] In this case, the AID12 subfield can be set to a preset value such as 4095 or 4094, and if the AID12 subfield is set to a preset value, it means that the padding field has started from that AID12 subfield. That is, if the AID12 subfield of the trigger frame is set to a value (preset) that indicates the start of the padding field, the STA recognizes that the padding field has started and may not attempt to parse the rest of the MAC frame.

[0240] At this time, the user information field where the AID12 subfield is indicated as 2046 may include information about an unallocated RU. More specifically, when the AID12 subfield of a specific user information field is indicated as 2046, the RU indicated by the RU Allocation subfield included in the specific user information field may be an unallocated RU.

[0241] The RU Allocation subfield of trigger frames other than MU-RTS trigger frames indicates the size and location information of the RU (Resource Unit) / MRU (Multiple Resource Unit) allocated to the destination device (STA indicated via the AID12 subfield) in the corresponding user information field. However, the RU Allocation subfield of MU-RTS trigger frames is used to indicate the channel on which the destination device in the corresponding user information field must respond to the CTS frame. More specifically, the RU Allocation subfield of the MU-RTS frame (of the user information field) indicates whether the destination STA must respond to the CTS only on the Primary 20 MHz channel or on the Primary 40 MHz / Primary 80 MHz / Primary 160 MHz / 80 + 80 MHz / Primary 320 MHz (if transmitted by an EHT AP) channel when responding to the CTS frame. At this time, the above MRU refers to an RU formed by combining two or more RUs, and 52+26, 106+26, 484+242, 996+484, 996+484+242, 2x996+484, 3x996, 3x996+484, 4x996-tone size MRUs, etc. were defined in 11be.

[0242] The UL FEC Coding Type subfield indicates the code type of the TB PPDU to be responded to, and if the UL FEC Coding Type subfield is 0, it indicates BCC (binary convolution coding), and if it is 1, it indicates LDPC (low density parity check).

[0243] The UL EHT-MCS subfield indicates the EHT-MCS to be applied to the TB PPDU being responded to.

[0244] The SS Allocation / RA-RU Information subfield is used as the RA-RU Information subfield when the AID12 subfield is not a value indicating that RA-RU has been allocated, i.e., when it is indicated as 0, 2044, or 2045, and can be used as the SS Allocation subfield when the AID12 subfield is indicated as a value other than 0, 2044, or 2045. When used as the SS Allocation subfield, the 6-bits corresponding to the SS Allocation subfield can be used as the Starting Spatial Stream subfield 4-bits and the Number Of Spatial Streams subfield 2-bits.

[0245] The UL Target Receive Power subfield indicates the predicted signal power value at which the TB PPDU to be responded will be received at the AP's antenna side. Therefore, when the STA responds to a TB PPDU, it may need to adjust the transmission power of the TB PPDU according to the value of the UL Target Receive Power subfield so that its TB PPDU can be received at the power predicted by the AP.

[0246] The PS160 subfield is used in conjunction with the RU Allocation subfield and indicates information regarding the location and size of the RU / MRU (Multiple-RU) allocated through the corresponding user information field.

[0247] Since the Trigger Dependent User Info (sub)field does not appear in the MU-RTS trigger frame, a detailed explanation is omitted.

[0248] FIG. 15 shows the format of the user information field of a MU-RTS TXS trigger frame according to an embodiment of the present invention.

[0249] The user information fields included in MU-RTS TXS trigger frames have a simpler configuration than the user information fields included in general trigger frames (e.g., Basic trigger frames and BSRP (Buffer Status Report Poll) trigger frames). The reason the user information fields included in MU-RTS TXS trigger frames can have a simpler configuration is that the format and transmission method of the frame that STAs responding to the MU-RTS trigger frame are fixed (i.e., responding with a CTS frame, applying the same MCS, using one Spatial Stream, etc.). Therefore, the user information fields included in MU-RTS TXS trigger frames do not utilize fields such as UL HE-MCS, UL FEC Coding Type, UL DCM, SS Allocation / RA-RU Information, and UL Target Receive Power, and many fields included in the common information fields of trigger frames are also not utilized.

[0250] As illustrated in FIG. 15, the MU-RTS TXS trigger frame includes an AID12 subfield, a RU allocation subfield, and an allocation duration subfield, and additionally includes a PS160 subfield. The AID12 subfield is configured in the same or similar manner as the AID12 subfield of a general trigger frame and serves to indicate the STA that receives the TXOP from the MU-RTS TXS trigger frame. When the MU-RTS TXS trigger frame is utilized for TXOP sharing between APs, the AP that is the TXOP holder (Sharing AP) can indicate the other AP that will receive the TXOP (Shared AP) through the corresponding subfield. That is, when the TXOP Sharing Mode (see FIG. 16) of the MU-RTS TXS trigger frame is indicated as a value related to AP-to-AP TXOP sharing, some or all of the bits corresponding to the AID12 subfield can be set to a value that specifies the target Shared AP. Alternatively, when the MU-RTS TXS trigger frame indicates that the TXOP Sharing Mode (see FIG. 16) is a value related to AP-to-AP TXOP sharing, the AID12 subfield is set to a specific value (e.g., 2006) that is not assigned to the associated STAs, and the value specifying the target Shared AP may be indicated through all or part of the bits corresponding to the Reserved subfield (B29 to FIG. 38) of the user information field. This may be an indication method considered to prevent non-AP STAs that cannot recognize the AP-to-AP TXOP sharing procedure from responding to the MU-RTS TXS trigger frame transmitted for the purpose of TXOP sharing between APs.

[0251] The Allocation Duration subfield of the User Information field indicates information regarding the length of time allocated to the STA (non-AP STA or another AP) that receives the MU-RTS TXS trigger frame. The unit of the indicated time is 16 us.

[0252] FIG. 16 illustrates an example of a method for sharing a TXOP obtained by an AP with a STA according to an embodiment of the present invention.

[0253] Referring to FIG. 16(a), the MU-RTS TXS trigger frame may have a configuration that includes a TXOP Sharing Mode subfield in the common information field. In this case, among the subfields of the common information field, the configuration of other subfields not shown in FIG. 15(a) may be the same as the configuration of a general trigger frame (see FIG. 13). The B20 and B21 bits used as the TXOP Sharing Mode subfield correspond to the bits corresponding to the GI And HE / EHT / UHR-LTF Type subfield in the general trigger frame, and are bits used as the TXOP Sharing Mode subfield in the MU-RTS TXS trigger frame.

[0254] Referring to Fig. 16(b), the value of the TXOP shared mode subfield can be used to indicate four types related to the type of the corresponding MU RTS trigger frame.

[0255] First, if the TXOP shared mode subfield is indicated as 0, it may mean that the corresponding trigger frame is a general MU-RTS trigger frame (not a MU-RTS trigger frame for TXOP time interval allocation) rather than a MU-RTS TXS trigger frame. That is, a non-AP STA that receives a frame indicated as a MU-RTS trigger type can recognize that the corresponding MU-RTS trigger frame is a general MU-RTS trigger frame if the value indicated by the B20 to B21 bits corresponding to the TXOP shared mode subfield is 00 (0).

[0256] Secondly, if the TXOP shared mode subfield is indicated as 1, the corresponding trigger frame is a MU-RTS TXS trigger frame, and it may mean that only the transmission of UL PPDU is allowed during the Shared TXOP. That is, the non-AP STA can recognize that if the value indicated by the B20 to B21 bits corresponding to the TXOP shared mode subfield is 01 (1), the corresponding MU-RTS trigger frame is a MU-RTS TXS trigger frame and only UL PPDU must be transmitted during the Shared TXOP.

[0257] Thirdly, if the TXOP shared mode subfield is indicated as 2, it may mean that the corresponding trigger frame is a MU-RTS TXS trigger frame and that transmission of P2P PPDU is also allowed during the Shared TXOP. That is, the non-AP STA can recognize that if the value indicated by the B20 to B21 bits corresponding to the TXOP shared mode subfield is 10 (2), the corresponding MU-RTS trigger frame is a MU-RTS TXS trigger frame and that UL PPDU and P2P PPDU can be transmitted during the Shared TXOP.

[0258] Fourth, when the TXOP sharing mode subfield is indicated as 3, the corresponding trigger frame is a MU-RTS TXS trigger frame, and the corresponding MU-RTS TXS trigger frame is used for TXOP sharing between APs. The trigger frame used to perform TXOP sharing between APs includes an indicator for the Shared AP (the AP that will receive the TXOP), and specifically, a part of the Coordination ID performed between the two APs or the MAC address of the Shared AP may be used as an indicator for the Shared AP. Therefore, an AP that receives a MU-RTS TXS trigger frame transmitted by another AP can confirm that the TXOP sharing mode subfield is set to 3 and perform an operation to check the user information field included in the trigger frame to determine whether TXOP sharing is being performed to it. An AP that identifies information identifying itself in the user information field of a trigger frame transmitted by another AP can perform an action recognizing that a TXOP has been allocated to it for a period of time corresponding to the allocation duration included in the user information field, for the range indicated by the RU allocation subfield included in the user information field. That is, the AP can proceed with a frame exchange sequence with its non-AP STAs during the Shared TXOP.

[0259] <AP간의 TXOP 공유 절차 및 동작 제한>

[0260] When the TXOP sharing procedure between APs is performed, a portion of the time corresponding to the TXOP of the Sharing AP, which is the AP that acquired the TXOP, is allocated to the Shared AP, and the Shared AP can use the shared time to perform services for the non-AP STAs of the BSS it operates.

[0261] When the TXOP sharing procedure between APs is performed, various restrictions must be considered more than when an AP shares a TXOP with its associated non-AP STA, because the relationship between the AP that is the TXOP holder and the non-AP STA that is the service target is different.

[0262] To facilitate understanding of the TXOP sharing procedure and operation restrictions between APs provided in the present invention, an example of the TXOP sharing procedure defined in 11be is first described.

[0263] FIG. 17 illustrates another example of a method for sharing a TXOP acquired by an AP with a STA according to one embodiment of the present invention.

[0264] Referring to FIG. 17, the AP can allocate all or part of the TXOP it acquired through the MU-RTS trigger frame as a Shared TXOP to a non-AP STA for the transmission of UL PPDU.

[0265] Specifically, the AP can acquire a TXOP (acquiring a TXOP by transmitting a CTS-to-self frame in FIG. 17) and become a TXOP holder, and then transmit a MU-RTS TXS trigger frame. The AP can assign a Shared TXOP to STA1 by setting the AID12 subfield of the user information field included in the MU-RTS TXS trigger frame to a value corresponding to the AID LSB 12 bit of STA1. Additionally, the AP can instruct STA1 to use the Shared TXOP to transmit a UL PPDU by setting the TXOP Sharing Mode subfield included in the common information field of the MU-RTS TXS trigger frame to 1.

[0266] STA1, upon receiving a MU-RTS TXS trigger frame, can recognize that the AP has allocated a Shared TXOP to it after confirming that a value related to its AID is indicated in the user information field. STA1 can identify the duration of the Shared TXOP allocated to it based on the value indicated in the UL length subfield of the MU-RTS TXS trigger frame. Additionally, STA1 can recognize that it must transmit a UL PPDU during the Shared TXOP by confirming that the TXOP Sharing mode subfield of the MU-RTS TXS trigger frame is indicated as 1.

[0267] In response to a MU-RTS TXS trigger frame, STA1 may respond with a CTS frame after SIFS (after SIFS where the PHY-RXEND.indication primitive of the MU-RTS TXS trigger frame occurs). STA1 may transmit the CTS frame and then begin transmitting the UL PPDU after SIFS (after SIFS where the CTS frame PHY-TXEND.confirm primitive occurs). At this time, STA1 may need to transmit the UL PPDU using all or some of the 20 MHz subchannels through which it transmitted the CTS frame. At this time, when STA1 responds with a CTS frame after receiving the MU-RTS TXS trigger frame, it may need to respond with the CTS frame only to the subchannels included in the type of RU / MRU that can be utilized when transmitting the UL PPDU.

[0268] Additionally, STA1 can transmit UL PPDU while ignoring the AP's NAV during the time interval for which it is allocated a Shared TXOP (from the time the MU-RTS TXS trigger frame is received until the time specified by the UL length subfield has elapsed). That is, if the CCA results of all subchannels to which the PPDU is to be transmitted are IDLE and only the NAV set by the AP is not 0, STA1 can transmit the PPDU while ignoring the non-zero NAV.

[0269] STA1 may transmit one or more than one UL PPDU within a Shared TXOP. However, STA1 may manage the transmission of UL PPDUs and UL PPDU response frames so that the UL PPDUs it transmits and the frames expected to be responded to the UL PPDUs (e.g., BlockAck frames from the AP) can be terminated within the Shared TXOP.

[0270] When the Shared TXOP assigned to STA1 is terminated, AP can resume transmission of PPDU (not a response frame) as the TXOP holder.

[0271] FIG. 18 illustrates another example of a method for sharing a TXOP acquired by an AP with a STA according to one embodiment of the present invention.

[0272] Referring to FIG. 18, the AP can share some or all of the TXOPs it has acquired with the STA, and the STA can transmit and receive P2P PPDUs with other STAs through the shared TXOPs.

[0273] Specifically, the AP can acquire a TXOP (acquiring a TXOP by transmitting a CTS-to-self frame in FIG. 18) and become a TXOP holder, and then transmit a MU-RTS TXS trigger frame. The AP can assign a Shared TXOP to STA1 by indicating the AID12 subfield of the user information field included in the MU-RTS TXS trigger frame as a value corresponding to the AID LSB 12 bit of STA1. Additionally, the AP can instruct STA1 to use the Shared TXOP to transmit a UL PPDU or P2P PPDU by indicating the TXOP sharing mode subfield included in the common information field of the MU-RTS TXS trigger frame as 2.

[0274] STA1, upon receiving a MU-RTS TXS trigger frame, can recognize that the AP has allocated a Shared TXOP to it after confirming that a value related to its AID is indicated in the user information field. STA1 can identify the duration of the Shared TXOP allocated to it based on the value indicated in the UL length subfield of the MU-RTS TXS trigger frame. Additionally, STA1 can recognize that the transmission of P2P PPDU as well as UL PPDU is allowed during the Shared TXOP by confirming that the TXOP sharing mode subfield of the MU-RTS TXS trigger frame is indicated as 2. Therefore, a non-AP STA can transmit UL PPDU or P2P PPDU while ignoring the NAV set by the frame transmitted by the AP during the Shared TXOP.

[0275] In response to a MU-RTS TXS trigger frame, STA1 may respond with a CTS frame after SIFS (after SIFS where the PHY-RXEND.indication primitive is generated by the MU-RTS TXS trigger frame). In the example of FIG. 18, STA1 may intend to transmit a P2P PPDU after transmitting the CTS frame.

[0276] STA1 may attempt to perform non-HT Protection with STA2 to protect transmission and reception with STA2, the destination device of the P2P PPDU. For this purpose, STA1 may send an RTS frame to STA2 after responding to the AP with a CTS frame.

[0277] After receiving the RTS frame transmitted by STA1, STA2 can respond with a CTS frame, thereby completing MAC protection (achieved by NAV settings of neighboring STAs) before transmitting / receiving P2P PPDU.

[0278] Subsequently, STA1 may transmit one or more than one UL / P2P PPDU within the Shared TXOP. However, STA1 may manage the transmission of UL / P2P PPDUs and response frames for PPDUs so that the PPDUs it has transmitted and the frames expected to be responded to the PPDUs (e.g., BlockAck frames to be responded to from AP or STA2) can be terminated within the Shared TXOP.

[0279] When the Shared TXOP assigned to STA1 is terminated, AP can resume transmission of PPDU (not a response frame) as the TXOP holder.

[0280] As described in the embodiment of FIGS. 17 and 18 above, the AP can share a TXOP with a non-AP STA, and the non-AP STA that receives the shared TXOP transmits a UL PPDU or P2P PPDU based on the specified type during an allocated time interval. At this time, the entire TXOP of the AP is protected by a NAV set by the Duration / ID field of the frame transmitted by the AP, and other STAs that received the frame transmitted by the AP do not access the channel even when the Shared TXOP is in progress because the already set NAV has not expired. However, the non-AP STA may ignore the NAV set by the frame transmitted by the AP and transmit the PPDUs.

[0281] Similarly, APs may share all or part of the TXOP they have acquired with other APs, as described above. For example, a specific AP (the first AP) among the APs may acquire a TXOP (for example, by acquiring channel access rights). The first AP may share a second TXOP, which is part or all of the acquired TXOP (the first TXOP), with a specific AP (the second AP) among at least one AP operating another BSS. In this case, the second TXOP may be included in the first TXOP. For example, the start time of the second TXOP may be after the start time of the first TXOP, and the end time of the second TXOP may be the same as or earlier than the end time of the first TXOP. The first AP may transmit a frame (for example, an initial frame or a trigger frame, etc.) to notify at least one AP of the second TXOP, which is part or all of the first TXOP it has acquired, in order to share it. If at least one AP wants to share the second TXOP based on a received trigger frame, it may transmit a TB PPDU (triggered based physical layer protocol data unit) to the first AP based on the trigger frame. At this time, at least one AP may choose whether to receive the second TXOP based on the information of the second TXOP. Subsequently, the first AP transmits a response frame as a response to the TB PPDU to a specific AP (second AP) among the at least one AP that will share the second TXOP. Subsequently, the second AP may transmit and receive traffic during the shared second TXOP.

[0282] When TXOP sharing between APs is performed, the Shared AP may utilize the UL MU frame exchange sequence by transmitting DL PPDUs to non-AP STAs belonging to its BSS or by transmitting trigger frames during the allocated time interval. However, among the non-AP STAs associated with the Shared AP, the non-AP STA that has received a frame transmitted by the Sharing AP has a non-zero Inter-BSS NAV (or Basic NAV), and therefore, when the Shared AP transmits a trigger frame to the said non-AP STA, the said non-AP STA has a problem in that it cannot respond with a TB PPDU due to the non-zero NAV.

[0283] If a non-AP STA is a UHR STA and is capable of understanding that the other AP has allocated a TXOP to the AP associated with it, it may be able to ignore the NAV set based on the frame transmitted by the other AP and respond with a TB PPDU; however, HE / EHT non-AP STAs cannot ignore the other AP's NAV and respond with a TB PPDU. In other words, when TXOP sharing is performed between APs, limitations related to NAV may arise in the Shared AP's operation using the Shared TXOP, and unless a solution is provided for Legacy STAs that do not understand the TXOP sharing procedure performed between APs, the usability of the Shared TXOP may be significantly lower than that of a self-acquired TXOP (e.g., a TXOP acquired through the EDCA procedure).

[0284] Accordingly, an AP intending to share a TXOP with another AP can enable the other AP and its associated STAs to perform frame exchange during the Shared TXOP by setting the time indicated by the Duration / ID field of the frame it transmits to expire based on the time when the Shared TXOP (time allocated to the other AP) begins. That is, the Sharing AP can adjust the Duration / ID field of the frame transmitted prior to the Shared TXOP based on the time when the Shared TXOP begins. In this case, the NAV of the STAs that received the frame transmitted by the Sharing AP expires while the Shared TXOP is in progress, and thus the frame exchange sequence between the AP allocated the Shared TXOP and the non-AP STAs can be performed without NAV issues set by the Sharing AP. That is, a first AP that shares all or part of a TXOP (first TXOP) it has acquired can adjust the Duration / ID field of a frame transmitted before the start time of the shared TXOP (second TXOP) based on the start time of the second TXOP. For example, the time indicated by the Duration / ID field can be set to be before the start time of the second TXOP. Additionally, the duration field included in the trigger frame transmitted for the sharing of the second TXOP can be set to a value obtained by adding the length of time required for the transmission of a response frame to the trigger frame to SIFS.

[0285] FIG. 19 illustrates an example of a method in which an AP that has acquired a TXOP according to an embodiment of the present invention shares part or all of the TXOP with another AP.

[0286] Referring to FIG. 19, the Sharing AP shares a portion of the time interval included in the TXOP it acquired with the Shared AP, and the Shared AP can perform a frame exchange sequence with a non-AP STA associated with it during the Shared TXOP.

[0287] Specifically, a Sharing AP intending to share a TXOP sets the Duration / ID field of the frames it transmits based on the expected end time of the CTS frame from which a response is expected when it transmits a MU-RTS TXS trigger frame to the Shared AP. In the example of FIG. 19, the AP sets the Duration / ID field of the MU-RTS TXS trigger frame and the frames transmitted prior to the MU-RTS TXS trigger frame to indicate the end time of the CTS frame from which the Shared AP is expected to respond. For example, the Duration / ID field of the MU-RTS TXS trigger frame and the frames transmitted prior to the MU-RTS TXS trigger frame can be set to a value obtained by adding the length of time required to transmit the CTS frame, which is the response frame to the trigger frame, to SIFS.

[0288] Therefore, the NAV (Intra-BSS NAV) of the Shared AP and non-AP STA that received frames transmitted by the Sharing AP expires when the Shared AP completes the transmission of the CTS frame.

[0289] The MU-RTS TXS trigger frame transmitted by the Sharing AP contains information indicating that it was transmitted for AP-to-AP TXOP sharing (e.g., indicated via the Triggered TXOP sharing mode) and includes a user information field for the Shared AP. Upon receiving the MU-RTS TXS trigger frame, the Shared AP obtains information about the time allocated to it and responds with a CTS frame.

[0290] At this time, the Duration / ID field of the CTS frame transmitted by the Shared AP is set based on the allocation time information indicated through the MU-RTS TXS trigger frame (more specifically, the information indicated through the allocation duration subfield of the user information field included in the MU-RTS TXS trigger frame). At this time, the specific method for setting the Duration / ID field of the CTS frame based on the indicated allocation time information is to set the time indicated by the Duration / ID field of the CTS frame to indicate the expiration time of the indicated allocation time or a time prior to the expiration time. In the example of FIG. 19, the Shared AP set the Duration / ID field of the CTS frame to indicate a time close to the end time of the Shared TXOP in order to maximize the utilization of the time allocated to it (Shared TXOP).

[0291] During a Shared TXOP, the Shared AP can send a DL PPDU to a non-AP STA or request a response for a TB PPDU by sending a trigger frame. The non-AP STA can respond with a TB PPDU even if the CS required of the trigger frame sent by the AP is set to 1 because the NAV by the Sharing AP has expired.

[0292] The Shared AP terminated the frame exchange sequence at the time when the Shared TXOP was ending, and the Sharing AP received the frame from the Shared AP (the BlockAck frame transmitted by the Shared AP in Fig. 19) when the Shared TXOP was nearing its end, and retrieved the TXOP after PIFS from the time the frame ended. At this time, the Sharing AP may transmit a Short Control frame for the purpose of retrieving the TXOP, and the Short Control frame serves the function of setting the NAV for the remaining TXOP. In the example of Fig. 19, the Sharing AP transmits a CTS-to-self frame, and the Duration / ID field of the CTS-to-self frame is set to a value indicating the end time of the remaining TXOP.

[0293] As described in the aforementioned Fig. 19, the Sharing AP can set the Duration / ID field of the frame it transmits based on the time when the Shared TXOP starts rather than the time when the TXOP ends, in order to allow the Shared AP to perform frame exchange with the STAs of its BSS (the Shared AP's BSS) without NAV issues during the Shared TXOP.

[0294] However, if the Sharing AP operates such that the NAV set by the frame it transmits is terminated based on the Shared TXOP, other STAs that are hidden from the Sharing AP interpret the medium situation as the Sharing AP's TXOP being terminated when the Shared TXOP starts, and therefore attempt to access the channel during the Shared TXOP. That is, if the Sharing AP adjusts the Duration / ID field of the frame it transmits for the purpose of supporting the frame switching operation of the Sharing AP, other STAs that are hidden from the Sharing AP can occupy the Sharing AP's medium during the Shared TXOP.

[0295] A Shared TXOP assigned by a Sharing AP to a Shared AP may have a minimum time length. For example, the minimum time length of a Shared TXOP may be 1 ms. The minimum time of a Shared TXOP is considered to prevent the problem that if an excessively short Shared TXOP is assigned to a Shared AP, the actions that the Shared AP can perform during the Shared TXOP are limited.

[0296] Accordingly, the length of the Shared TXOP allocated by the Sharing AP to the Shared AP can be determined by the sum of the time interval indicated by the Allocation Duration subfield of the MU-RTS TXS trigger frame transmitted by the Sharing AP to the Shared AP plus the minimum time length. That is, if the Sharing AP intends to allocate the time corresponding to the minimum time as the Shared TXOP, the Allocation Duration subfield of the MU-RTS TXS trigger frame can be set to 0.

[0297] Specifically, when a Sharing AP shares part or all of a TXOP with a Shared AP, a minimum time for the Shared TXOP may be set so that the operation of the Shared AP is not restricted during the shared Shared TXOP. That is, the Sharing AP may share the TXOP with the Shared AP for a duration longer than the minimum time. The minimum time length of the Shared TXOP may be a pre-specified value defined by a standard, or a value determined by an agreement or instruction procedure performed in advance between the Shared AP and the Sharing AP. For example, the First AP may instruct the Second AP to set a specific value for the minimum Shared TXOP length to be allocated to it, and in this case, when the Second AP shares the TXOP it has acquired with the First AP, it may be required to allocate a Shared TXOP corresponding to a duration longer than the specific value.

[0298] FIG. 20 shows an example in which the Medium of the AP that shared the TXOP is occupied during a shared TXOP according to an embodiment of the present invention.

[0299] Referring to FIG. 20, the Sharing AP shares the Shared TXOP with the Shared AP. The specific procedure for sharing the Shared TXOP is the same as that of the embodiment in FIG. 19, so it is omitted.

[0300] To ensure that the Shared AP can smoothly use the Shared TXOP, the Sharing AP adjusts the Duration / ID field of the frame transmitted before the start of the Shared TXOP to end with the start of the Shared TXOP. As a result, the NAV of the Shared AP and the Hidden STA expires after the Shared TXOP starts, and after determining that the Sharing AP's TXOP has ended, they attempt to access the channel.

[0301] Frames transmitted by a Shared AP and a Hidden STA can be successfully received by a Sharing AP, and the Sharing AP that receives the frame sets its NAV based on the Duration / ID field of the received frame. Although not shown in FIG. 20, among the non-AP STAs associated with the Sharing AP, the non-AP STA that receives the frame sets its NAV (Inter-BSS NAV) in the same way as the AP.

[0302] At the time when the Shared TXOP is terminated, the Sharing AP's TXOP recovery procedure cannot be performed due to interference caused by the NAV set by the Hidden STA or transmissions performed by the Hidden STA. As a result, the Sharing AP is unable to utilize its remaining TXOPs after the Shared TXOP is terminated due to the influence of the Shared AP and the Hidden STA.

[0303] The problem described through the embodiment of FIG. 20 above is a problem that can always occur in a situation where there are Shared APs and hidden STAs among the adjacent STAs of a Sharing AP, and setting the NAV so that the hidden STA cannot perform channel access during a Shared TXOP may result in an excessively wide area of ​​NAV being set by the Sharing AP / Shared AP, which can lead to a decrease in overall network efficiency.

[0304] Therefore, a Sharing AP must operate with the awareness that its medium may be occupied by other STAs while a Shared TXOP is in progress, and one possible course of action is to process all of its queued traffic before sharing the Shared TXOP. In other words, considering the possibility that it may fail to retrieve its TXOP, the Sharing AP may decide to transmit all MPDUs in its transmission queue before allocating the Shared TXOP. However, such a response depends on the AP's scheduling decisions and may not be an action mandated by the standard.

[0305] Additionally, some exception behaviors may be introduced to increase the likelihood that the Sharing AP will recover its own TXOP at the time of the Shared TXOP's termination.

[0306] First, the Sharing AP may decide not to set the NAV based on a frame transmitted by another STA, even if such frame is received while its own TXOP is in progress. That is, the Sharing AP may not set the NAV when it receives a frame transmitted by another STA during the time interval (Shared TXOP) allocated to the Shared AP. In other words, in the example of FIG. 20 described above, the Sharing AP can maintain the medium state determination based on the virtual CS (carrier sensing) mechanism idle by not setting the NAV when it receives a CTS-to-self frame transmitted by the Hidden STA. Through this, the Sharing AP can determine whether the TXOP can be recovered by considering only the results of the physical CS (e.g., Energy detection) when the Shared TXOP has ended.

[0307] For example, if the first AP that has set the TXOP shares part or all of its TXOP with the second AP through the method described above, it may not set the NAV based on the received frame even if it receives a frame transmitted from another STA during the shared second TXOP. That is, even if the first AP that has set the TXOP shares all or part of the TXOP, it may not set the NAV due to the reception of a frame transmitted from another STA caused by the sharing of the TXOP during the TXOP it has set.

[0308] Secondly, when the Sharing AP performs CCA for TXOP recovery, it can determine the Medium state by using a threshold higher than the CCA threshold used for channel access (i.e., EDCA). That is, a Sharing AP determining the Medium state at the time the Shared TXOP ends can determine whether the medium is idle or busy by applying a CCA threshold (e.g., a value higher than -62 dBm) higher than the CCA threshold used for EDCA (e.g., -62 dBm) (determining the medium as busy if a signal with an intensity higher than the threshold is detected), and attempt TXOP recovery for the channel confirmed as idle. In other words, even if a signal is detected that should have determined the medium as busy during EDCA, the Sharing AP can determine the medium as idle and perform channel access when recovering the TXOP. This may be an exception permitted only during the process in which the Sharing AP recovers its remaining TXOP after the Shared TXOP.

[0309] Meanwhile, even if the Sharing AP successfully recovers the existing TXOP after the Shared TXOP has ended, the Sharing AP's associated non-AP STAs may remain in a state where NAV was set during the Shared TXOP. That is, when the Sharing AP transmits a trigger frame after recovering the TXOP, the non-AP STAs may determine the medium state as busy (virtual CS result) and fail to respond to the TB PPDU. Therefore, when the Sharing AP transmits a trigger frame using the TXOP recovered after the Shared TXOP, it may need to set the CS Required subfield of each user information field to 0 so that the non-AP STAs respond to the TB PPDU without NAV issues.

[0310] Alternatively, a Sharing AP that has recovered its own TXOP after a Shared TXOP may instruct non-AP STAs associated with it to reset the Inter-BSS NAV set during the Shared TXOP by broadcasting a frame of a specific format. That is, after the Shared TXOP assigned by its AP to another AP has ended, a non-AP STA that receives the frame of the specific format transmitted by the AP may reset the Inter-BSS NAV.

[0311] <AP간의 TXOP Sharing을 위한 MU-RTS TXS 트리거 프레임 및 응답 프레임의 전송 규칙>

[0312] As described in the embodiment of FIG. 10 above, in conventional Wi-Fi standards, an AP utilizes a MU-RTS trigger frame for the purpose of performing NAV Protection with a plurality of non-AP STAs. In this case, the AP already has a plan for the DL MU PPDU to be transmitted to the non-AP STAs, and can additionally adjust the BW of the DL PPDU to be actually transmitted according to the form of the CTS frame in which the non-AP STAs respond.

[0313] For example, an AP may plan to transmit a DL OFDMA MU PPDU by allocating a 242-tone size RU (Resource Unit) located in the Primary 20 MHz subchannel to STA1, a 242-tone size RU located in the Secondary 20 MHz subchannel to STA2, and a 484-tone size RU located in the Secondary 40 MHz subchannel to STA3. In this case, the AP may request STA1 to respond with a CTS frame to the Primary 20 MHz channel, STA2 to respond with a CTS frame to the Primary 40 MHz channel, and STA3 to respond with a CTS frame to the Primary 80 MHz channel via a MU-RTS trigger frame. If an AP receives a CTS frame in the Primary 40 MHz band, the AP can determine that the Secondary 40 MHz band allocated to STA3 is BUSY on the STA3 side, and thus decide to transmit a 40 MHz DL OFDMA MU PPDU (targeting STA1 and STA2). In this way, when the AP requests a CTS frame response from multiple non-AP STAs via a MU-RTS trigger frame, useful information is obtained for the AP to determine the transmission method of the next PPDU when each of the multiple non-AP STAs responds with a CTS frame of the specified BW. For this reason, MU-RTS trigger frames transmitted for NAV Protection in conventional Wi-Fi standards force the receiving device to respond only with a CTS frame of the specified BW via the MU-RTS trigger frame.That is, a non-AP STA that receives a MU-RTS trigger frame responds to a CTS frame of the BW indicated by the MU-RTS trigger frame, or does not respond to a CTS frame if a response to a CTS frame of the BW indicated is impossible (i.e., if there is a subchannel identified as busy within the BW indicated).

[0314] However, the MU-RTS TXS trigger frame (a type of MU-RTS frame) used for TXOP sharing between APs performs the next PPDU transmission by the Shared AP, which is the device responding to the CTS frame; therefore, the Sharing AP does not perform additional operations based on the BW information of the responded CTS frame. Furthermore, in a situation where the BW of the target device to which it intends to transmit the DL PPDU is limited, the Shared AP has no reason to acquire a Shared TXOP by responding to a CTS frame for a bandwidth wider than the said BW. For example, if the Shared AP responds to the MU-RTS TXS trigger frame with an 80 MHz CTS frame while planning to transmit to a 20 MHz PPDU non-AP STA, it results in unfairly blocking channel access for STAs operating in the remaining 60 MHz band, and consequently leads to an unfair operation that lowers the yield of the entire network.

[0315] Accordingly, an AP that receives a MU-RTS TXS trigger frame from another AP may be allowed to respond with a CTS frame using only some of the subchannels included in the BW indicated by the MU-RTS TXS trigger frame. In this case, the BW may be indicated by the RU Allocation subfield included in the user information field for the AP, the BW subfield included in the user information field, or the UL BW field included in the common information field of the MU-RTS TXS trigger frame. At this time, when the AP selects a subchannel to respond to a CTS frame, it may choose to use all or part of the remaining subchannels for the CTS frame response, excluding the Disabled subchannel of the Sharing AP (a subchannel prohibited from use in the BSS operated by the Sharing AP, i.e., a subchannel to which Preamble Puncturing is always applied), the Disabled subchannel of the Shared AP (a subchannel prohibited from use in the BSS operated by the Shared AP, i.e., a subchannel to which Preamble Puncturing is always applied), and the subchannel determined to be Busy by the CCA result. That is, the AP responding to a CTS frame after receiving a MU-RTS TXS trigger frame may respond to the CTS frame in a form that excludes additional subchannels other than the subchannels restricted by other rules (rules related to Disabled subchannels and CCA results).

[0316] That is, when a first AP that has acquired a TXOP transmits a trigger frame to share a second TXOP, which is all or part of the first TXOP that it acquired, the second AP that receives the second TXOP through the methods described above may transmit a response frame to the trigger frame using only a portion of the specific bandwidth indicated by the trigger frame. The specific bandwidth may be indicated through a bandwidth field included in the trigger frame. The bandwidth field may be included in the RU allocation subfield or user information field included in the user information field corresponding to the second AP included in the trigger frame. Alternatively, the bandwidth field may be included in the common information field of a MU-RTS TXS frame. When the second AP transmits a response frame using only a portion of the specific bandwidth, it may receive the second TXOP for a portion of the bandwidth rather than the specific bandwidth, and may transmit and receive frames using that portion of the bandwidth during the second TXOP.

[0317] For example, the Sharing AP can allocate a TXOP for the 160 MHz BW band to the Shared AP via a MU-RTS TXS trigger frame, and the Shared AP may arbitrarily respond with a CTS frame for the 80 MHz BW band. In this case, the reason the Shared AP responds with a CTS frame for the 80 MHz BW band may be that the Secondary 80 MHz band is determined to be busy, or that there is no intention to use the Secondary 80 MHz band during the Shared TXOP. In this case, the Shared AP and the non-AP STA associated with the Shared AP perform frame exchange through the 80 MHz band for which the CTS frame was responded during the Shared TXOP.

[0318] Meanwhile, when TXOP sharing is performed between APs, the location of the primary channel of the BSS operated by the Sharing AP and the Shared AP may differ. That is, the subchannel used as the primary channel by the Sharing AP may not be the primary channel of the Shared AP, and the subchannel used as the primary channel by the Shared AP may not be the primary channel of the Sharing AP. This is a phenomenon of primary channel mismatch between APs that did not occur when an AP shares TXOPs with a non-AP STA, and when this mismatch occurs, a problem of limited interaction between APs may arise.

[0319] As a specific example of the problem, when a Sharing AP transmits a frame to a Shared AP to share a TXOP, it is possible that the Shared AP identifies the Sharing AP's Primary channel as being busy. In this case, the Shared AP, upon receiving the frame, cannot send a response frame by occupying the Sharing AP's Primary channel. Consequently, the Sharing AP determines that the TXOP sharing procedure has failed because it does not receive the Shared AP's response frame on its Primary channel. If the Shared AP transmits the response frame only through a subchannel identified as idle, a problem arises where unnecessary NAVs are set for the STAs operating on the subchannel to which the response frame was transmitted.

[0320] Accordingly, an AP that receives a frame for TXOP sharing (i.e., a MU-RTS TXS trigger frame) from another AP must transmit a response frame to said frame only if the other AP's primary channel, identified during SIFS (or PIFS) after said TXOP sharing frame, is determined to be IDLE. At this time, said AP must also check whether its own BSS's primary channel is IDLE. That is, an AP that receives a MU-RTS TXS trigger frame from another AP must respond with a CTS frame only if both the other AP's primary channel and its own primary channel are determined to be IDLE.

[0321] To this end, each AP that intends to utilize the TXOP sharing procedure between APs must transmit its Primary channel information to the counterpart AP, and each AP must perform an action based on the identified Primary channel location of the counterpart AP. At this time, the method by which Primary channel information between APs is exchanged may be by using frames exchanged during a preliminary consultation procedure for TXOP sharing between APs (e.g., a Multi-AP coordination procedure). At this time, the method by which a specific AP performs an action based on the counterpart AP's Primary channel location may be to determine whether to transmit a response frame based on whether the counterpart AP's Primary channel is identified as IDLE when the counterpart AP transmits a frame for TXOP sharing (e.g., a MU-RTS frame or a BSRP trigger frame) to itself. More specifically, the specific AP transmits a response frame when the subchannel corresponding to the counterpart AP's Primary channel is identified as IDLE, and does not transmit a response frame when it is identified as Busy.

[0322] Similarly, a Sharing AP may also need to select a Shared AP by considering whether the band in which it acquired the TXOP occupies the other Primary 20 MHz subchannel. More specifically, a Sharing AP may need to select only APs of OBSS that use one of the 20 MHz subchannels included in the band in which it acquired the TXOP as the Primary 20 MHz subchannel as the TXOP sharing target device. This is because the AP that is the TXOP holder can only transmit frames for TXOP sharing through the subchannel occupied by the TXOP it acquired, and only APs that use one of the subchannels through which the TXOP sharing frame is transmitted as the Primary 20 MHz subchannel can receive the frame. Therefore, a Sharing AP that intends to share the TXOP it acquired with other APs must select only APs of OBSS that use one of the subchannels through which it transmits the TXOP sharing frame as the Primary 20 MHz subchannel as the target AP (Shared AP). That is, the AP that can be addressed through the frame for TXOP sharing may be limited to the AP of the BSS that uses one of the subchannels through which the frame for TXOP sharing is transmitted as the Primary 20 MHz subchannel.

[0323] <Shared TXOP과 관련한 채널 액세스 관리 방법>

[0324] When the aforementioned TXOP sharing procedure between APs is utilized, the Shared AP can perform frame exchange with the non-AP STAs of its BSS without performing its own channel access procedure. Considering that conventional APs could only perform frame exchange after performing their own channel access (e.g., EDCA), this can be seen as the Shared AP, which is a UHR AP, having obtained more frame exchange opportunities than conventional APs.

[0325] In Wi-Fi 6, which defined the response procedure for Basic trigger frames and TB PPDUs, the MU EDCA parameter was introduced to ensure equity between HE non-AP STAs that transmit TB PPDUs in response to Basic trigger frames transmitted by APs and conventional Wi-Fi non-AP STAs that do not have the opportunity to transmit TB PPDUs. In Wi-Fi 7, the equity issue was resolved by applying the MU EDCA parameter to non-AP STAs that transmit UL PPDUs by sharing TXOPs from APs.

[0326] Similarly, when TXOP sharing between APs is performed, there may be a method to consider the use of the MU EDCA parameter by the Shared AP if it has successfully transmitted at least one MPDU during the Shared TXOP. That is, the Shared AP allocated the Shared TXOP may apply the MU EDCA parameter when it has successfully transmitted at least one Data MPDU or successfully received at least one Data MPDU during the Shared TXOP. In this case, the time at which the Shared AP applies the MU EDCA parameter may be when the Shared TXOP allocated to it ends (when the allocated time expires or after it has transmitted the TXOP Return frame to the Sharing AP (the end time of the TXOP Return frame)).

[0327] For example, a first AP that has acquired a first TXOP may share a second TOXP, which is part or all of the first TXOP, with a second AP through the method described above. If the transmission and reception of traffic is completed before the second TXOP shared by the second AP ends, the second AP may return the TXOP shared by the first AP before the second TXOP ends. Subsequently, if the second AP performs a new channel access procedure, it may receive a penalty for the channel access procedure. For example, after returning the second TXOP, the second AP may perform channel access using MU EDCA (multi-user enhanced distributed channel access) parameters.

[0328] However, while non-AP STAs that have difficulty accessing their own channels due to the application of the MU EDCA parameter can be continuously managed by an AP that understands the requirements of the non-AP STA, Shared APs cannot expect continuous management from Sharing APs. This is because the relationship between a Shared AP and a Sharing AP is that of equal target devices performing coordination, and is not a service provider-service target device relationship like that between an AP and a non-AP STA.

[0329] Therefore, even if a Shared AP has successfully performed a frame exchange sequence using a Shared TXOP, it may be considered unfair to apply a penalty by lowering the Shared AP's channel access probability (i.e., by applying the MU-EDCA parameter). Furthermore, if a Shared AP transmits a trigger frame using a Shared TXOP, both the non-AP STA and the Shared AP that received the trigger frame and responded with a TB PPDU will have the MU-EDCA parameter applied, which could lead to an overall performance degradation of the entire BSS operated by the Shared AP. This result is inconsistent with the original intent of utilizing the medium more efficiently through coordination between APs; therefore, it is more reasonable to consider that the Shared AP should not be subject to restrictions related to the MU-EDCA parameter even if it has successfully transmitted or received an MPDU using a Shared TXOP.

[0330] However, if a Shared AP that has performed frame exchange via a Shared TXOP is allowed to continue the channel access procedure without coordination for additional channel access procedures, the Shared AP may reoccupy the medium too early after the TXOP assigned to the Shared TXOP (the Sharing AP's TXOP) has ended, and equity issues may arise with other APs that do not support TXOP sharing procedures between APs (e.g., Legacy (non-HT / HE / EHT, etc.) APs). Therefore, the introduction of additional channel access rules that must be applied when the AP assigned to the Shared TXOP performs channel access after the Sharing AP's TXOP has ended should be considered.

[0331] According to one embodiment of the present invention, a Shared AP allocated a Shared TXOP can create a new backoff counter using the existing Contention Window (CW) when the Shared TXOP is terminated.

[0332] For example, a first AP that has acquired a first TXOP may share a second TOXP, which is part or all of the first TXOP, with a second AP through the method described above. If the transmission and reception of traffic is completed before the second TXOP shared by the second AP ends, the second AP may return the TXOP shared with the first AP before the second TXOP ends. When the second AP selects a new back-off counter within a contention window to perform a new channel connection, it may compare the back-off counter before receiving the second TXOP with the new back-off counter and use the larger value to perform the new channel connection.

[0333] The specific method for managing backoff counters is as follows.

[0334] 1. During the Shared TXOP, the Shared AP creates a new backoff counter for the Access Category (AC) that has successfully transmitted / received at least one MPDU. That is, if the QoS Data frame of a specific AC included in the DL PPDU transmitted by the Shared AP is successfully transmitted, the Shared AP creates a new backoff counter for said specific AC when the Shared TXOP ends. Whether the QoS Data frame of a specific AC is successfully transmitted follows the method of 1) to 2), depending on whether the frame requests an ack.

[0335] 1) When a QoS Data frame requests an Ack (BlockAck) frame, the successful reception of the QoS Data frame can be confirmed through the reception of the corresponding Ack (BlockAck) frame.

[0336] 2) If a QoS Data frame does not request an Ack (BlockAck) frame, the QoS Data frame can always be considered successfully transmitted.

[0337] The Shared AP creates a new backoff counter for the specific AC using the existing Contention Window of the specific AC. That is, the Shared AP creates a new backoff counter when the Shared TXOP ends, but does not change the Contention Window.

[0338] Additionally, if the Shared AP successfully receives at least one of the frames of TB PPDU received in response to the trigger frame it transmitted, it creates a new backoff counter when the Shared TXOP ends. 1) The Shared AP may create a new backoff counter for only one of the ACs of the frames it successfully received. That is, if the Shared AP successfully receives MPDU1 (AC_VO) and MPDU2 (AC_VI), the Shared AP creates a new backoff counter for either AC_VO or AC_VI. Or, 2) the Shared AP may create a new backoff counter for all the ACs of the MPDUs it successfully received. That is, if the Shared AP successfully receives MPDU1 (AC_VO) and MPDU2 (AC_VI), the Shared AP creates a new backoff counter for both AC_VO and AC_VI (each).

[0339] At this time, the Shared AP creates a new backoff counter using the existing contention window of each AC.

[0340] 2. The Shared AP adds the newly created backoff counter to the existing backoff counter and uses it for channel access. For example, if the existing backoff counter of AC_VO was 2 and the newly created backoff counter was 5, the Shared AP sets the backoff counter of AC_VO to 7 (existing value + newly created value) and performs the channel access procedure of AC_VO.

[0341] In the manner described above, when the Shared TXOP is terminated, the Shared AP may attempt channel access after adjusting the backoff counter to a value greater than the existing backoff counter (or the same value if the newly created backoff counter is 0), and as a result, the channel access capability of the Shared AP that acquired the Shared TXOP may be reduced to some extent. If the completion time of the Shared AP's backoff procedure is delayed due to the added backoff counter, an AP that does not support TXOP sharing may use that delay period to complete the channel access procedure first and then perform transmission, thereby balancing the channel access cycle between APs that support the TXOP sharing procedure and APs that do not.

[0342] Of course, it is also possible to adjust the channel access capability of a Shared AP in a way different from that considered in the present invention. Therefore, rather than a specific backoff counter management method, the main idea of ​​the present invention can be understood as adjusting the channel access capability between a Shared AP and other APs by adjusting the completion time of the Shared AP's backoff procedure to be later than after the Shared TXOP.

[0343] As an example of the other method mentioned above, it is also possible for the Shared AP to generate a new backoff counter when the Shared TXOP is completed, and to adopt the larger value between the existing backoff counter and the new backoff counter to use as the new backoff counter.

[0344] As another example, the Shared AP can be configured to discard the existing backoff counter and perform channel access using a newly created backoff counter when the Shared TXOP is completed. This method takes into account that the existing backoff counter is likely to have decreased in value due to counting down during the previous channel access period, and therefore the newly created backoff counter is likely to be larger than the existing backoff counter.

[0345] In addition, the timing of generating a new backoff counter itself can also be changed. In the embodiments of the present invention described above, it is considered that the Shared AP generates a new backoff counter when the Shared TXOP ends, but the Shared AP may be allowed to generate a new backoff counter when the TXOP containing the Shared TXOP (the Shared AP's TXOP) ends. In this case, since the Shared AP's backoff counter does not decrease until the Shared AP's TXOP ends, it does not cause a difference in the channel access operation of the Shared AP compared to generating a new backoff counter when the Shared TXOP ends.

[0346] Similarly, the timing for generating a new backoff counter can be adjusted to the time when a QoS Data frame is transmitted or received. That is, the Shared AP can generate a new backoff counter when it determines that the QoS Data frame it transmitted has been successfully transmitted, or when it successfully receives at least one frame from the TB PPDU that responded to the trigger frame it transmitted. However, even in this case, since the Shared AP's backoff counter does not decrease until the Sharing AP's TXOP ends, it does not cause a difference in the Shared AP's channel access operation compared to generating a new backoff counter when the Shared TXOP ends.

[0347] FIG. 21 illustrates an example of a case where channel access of a legacy AP is delayed due to TXOP sharing between APs according to an embodiment of the present invention.

[0348] Referring to Fig. 21, channel access of legacy APs may be delayed due to TXOP sharing performed between UHR APs.

[0349] Referring to Fig. 21, for example, UHR AP1, UHR AP2, and Legacy AP are performing channel access, and the situation begins with UHR AP1 occupying the medium by transmitting a CTS-to-self frame after completing the backoff procedure first.

[0350] UHR AP1 sends a MU-RTS TXS trigger frame allocating a portion of the time of the TXOP it acquired to UHR AP2, and UHR AP2 responds with a CTS frame and performs frame exchange during the Shared TXOP. After the Shared TXOP ends, UHR AP1 performs frame exchange with the STAs of its BSS.

[0351] After the TXOP of UHR AP1 is terminated, UHR AP1, UHR AP2, and Legacy AP resume channel access, and UHR AP2, which had the smallest remaining backoff counter, terminates the backoff procedure first and occupies the medium by transmitting a CTS-to-self frame.

[0352] While the Legacy AP was unable to perform any frame exchanges during the TXOP of UHR AP1 and UHR AP2, UHR AP2 performs frame exchanges using the Shared TXOP during UHR AP1's TXOP, and succeeds in channel access immediately after UHR AP1's TXOP ends, thereby performing frame exchanges again. In other words, UHR APs that support TXOP sharing obtain more channel access opportunities than Legacy APs.

[0353] FIG. 22 shows an example of a method in which a backoff counter for channel access of an AP that has received a shared TXOP is adjusted according to an embodiment of the present invention.

[0354] As shown in FIG. 22, UHR AP1, UHR AP2, and Legacy AP are performing channel access, and after UHR AP1 completes the backoff procedure first, it can occupy the medium by transmitting a CTS-to-self frame.

[0355] In this case, UHR AP1 sends a MU-RTS TXS trigger frame allocating a portion of the time of the TXOP it acquired to UHR AP2, and UHR AP2 responds with a CTS frame and performs frame exchange during the Shared TXOP. After the Shared TXOP ends, UHR AP1 performs frame exchange with the STAs of its BSS.

[0356] At this time, UHR AP2 creates a new backoff counter when the Shared TXOP ends, and in the example of FIG. 22, the new backoff counter is 5. UHR AP2 sets the new backoff counter value to 6, which is the sum of the newly created backoff counter (5) and the existing backoff counter (1 in FIG. 22).

[0357] After the TXOP of UHR AP1 is terminated, UHR AP1, UHR AP2, and Legacy AP resume channel access. At this time, the backoff counter of AP2, which had the smallest backoff counter value at the time AP1's TXOP was initiated, has been changed to an increased state. Accordingly, Legacy AP, which has the smallest backoff counter value, completes the backoff procedure before UHR AP1 and UHR AP2 and occupies the medium by transmitting a CTS-to-self frame.

[0358] <TXOP Sharing을 위한 초기 프레임의 활용>

[0359] Through the aforementioned embodiments of the present invention, it has been shown that a TXOP can be shared between a non-AP STA and an Associated AP, or that a Sharing AP can share a TXOP with a Shared AP.

[0360] In order for TXOP sharing (a type of C-TDMA) between APs to be performed, prior consultation for the use of C-TDMA (Coordinated Time Division Multiple Access) between APs may be performed, and since the method and procedure for prior consultation for the use of C-TDMA are not related to the C-TDMA execution method intended to be provided in this invention, a detailed explanation is omitted.

[0361] An AP that has performed consultation regarding C-TDMA execution may perform actions considering the possibility that the counterpart AP with which it consulted may attempt TXOP sharing to it when the counterpart AP acquires a TXOP. For example, the AP may perform an action of waiting for the reception of a frame for TXOP sharing during the TXOP acquired by the counterpart AP with which it consulted regarding C-TDMA. Although this is an action that must fundamentally be performed to execute C-TDMA, attempting to wait for the reception of a frame for TXOP sharing when it is unclear whether the counterpart AP will attempt TXOP sharing can lead to inefficient results. As a simple example, a second AP that has performed C-TDMA consultation with a first AP is unable to perform power saving or attempt channel access for spatial reuse due to the process of waiting for the reception of a frame for TXOP sharing that might be received from the first AP. On the other hand, a third AP that has not performed C-TDMA-related consultation with the first AP can perform Power Save or utilize Spatial Reuse to access the channel while the first AP's TXOP is in progress. If the first AP does not perform TXOP sharing with the second AP while its TXOP is in progress, the receiving waiting operation for the frame for TXOP sharing performed by the second AP will result in unnecessary loss for the second AP.

[0362] To minimize such inefficiencies, it may be considered to allow the AP that acquired the TXOP to indicate whether it intends to attempt TXOP sharing within the acquired TXOP. As a simple example, the AP that acquired the TXOP can transmit a frame indicating whether it intends to perform TXOP sharing within the TXOP. In this case, the APs of the OBSS that receive the frame can decide to wait for the reception of a frame for TXOP sharing only when the AP holding the TXOP indicates that it intends to perform TXOP sharing.

[0363] For example, a first AP that has acquired a first TXOP may transmit to at least one AP a frame (e.g., a trigger frame) containing a subfield indicating whether to share a second TXOP, which is part or all of the first TXOP. For example, the first AP may transmit by setting the value of the subfield indicating whether to share the second TXOP to '1'. In this case, the first AP may indicate an intention to share the second TXOP. However, if the first AP sets the value of the subfield indicating whether to share the second TXOP to '0', the first AP may indicate that the second TXOP is not shared.

[0364] Additionally, the AP that has acquired the TXOP can indicate whether it intends to perform TXOP sharing within the TXOP, along with information about the AP that is the target of the TXOP sharing. That is, the AP that has acquired the TXOP can announce in advance that it will share the TXOP with a specific AP during the TXOP. In this case, an AP that confirms that it will be shared with the TXOP through a frame transmitted by the AP that is the TXOP holder may decide to wait for the reception of a frame for TXOP sharing, while an AP that is not designated as the target AP for TXOP sharing may make a different decision, such as performing an alternative action (such as power saving and actions via Spatial Reuse). In summary, the AP that is the TXOP holder can indicate whether it intends to attempt TXOP sharing within the TXOP it has acquired and information about the target device for TXOP sharing, and the AP of the OBSS that receives the frame can decide whether to wait for the reception of a frame for TXOP sharing based on the indicated information. At this time, the AP that is the TXOP holder can help the other APs perform the aforementioned decision (waiting for reception of a frame for TXOP sharing or attempting an alternative operation) as quickly as possible by indicating the information (whether to perform TXOP sharing and a target device indicator) in the initial frame transmitted from the TXOP it has acquired. With this purpose in mind, an AP that has conducted a consultation regarding C-TDMA with the other AP may be recommended / compulsory to indicate the information through the initial frame transmitted from the TXOP it has acquired.

[0365] In addition, it is possible for the AP that is the TXOP holder to have no particular preference for the target AP to share the TXOP with, even though it intends to perform TXOP sharing. In this case, instead of checking with each AP that has entered into a C-TDMA agreement whether a Shared TXOP is needed, the AP that is the TXOP holder can determine the target AP to perform TXOP sharing by receiving a request from an AP that needs a Shared TXOP. More specifically, the AP that is the TXOP holder can allocate RU(s) targeting unspecified APs through an initial frame (trigger frame) that it transmits, and the AP that wishes to receive the Shared TXOP can indicate that it wishes to receive the Shared TXOP by responding with a TB PPDU using one of the said RU(s). At this time, the RU(s) assigned to the aforementioned unspecified AP are a type of RA-RUs (Random Access RUs) and can be assigned through a user information field in which the AID12 subfield is set to a pre-specified value. At this time, the AP that intends to respond with a TB PPDU through the RU(s) assigned to the aforementioned unspecified AP must select whether to access the RU and which RU to access using an OFDMA-based random access method. The OFDMA-based random access procedure refers to a channel access method using an OBO (OFDMA random access backoff) counter and can be performed following a method identical or similar to the operation of a non-AP STA performing UORA (UL OFDMA-based random access) on an RA-RU. At this time, since the OFDMA-based random access method performed by the AP is identical or similar to the method defined in 11ax, a detailed explanation is omitted.However, the difference is that the OBO counter generated by the AP for use in the OFDMA-based random access procedure is generated using a value indicated by the received initial frame. More specifically, when a value x is indicated for generating the OBO counter through an initial frame transmitted by the AP, which is the TXOP holder, the AP accessing the RU(s) allocated to an unspecified AP generates one natural number included in the range from 0 to x as the OBO counter. At this time, if the generated OBO counter has a value less than the number of RA-RU(s) allocated to the unspecified AP, the AP may randomly select one of the RA-RUs and respond with a TB PPDU. At this time, the OBO counter used by the AP is discarded after determining whether to respond to the TB PPDU, and is generated again (based on the value indicated by the received initial frame) after receiving the next initial frame.

[0366] On the other hand, even an AP that has performed C-TDMA-related consultation may not always wish to receive TXOPs from the other AP. As a simple example, an AP with no queueing traffic may decide not to receive TXOPs from the other AP because it has no reason to perform transmissions. In this case, the AP that does not wish to receive TXOPs may instruct the other AP of its decision by not responding to a frame for TXOP sharing transmitted by the other AP that is the TXOP holder, or by responding with a frame indicating that it has no intention of participating in the TXOP sharing procedure. A TXOP holder who has not received a response to a frame for TXOP sharing transmitted by the other AP, or who has received a frame indicating that it has no intention of participating in the TXOP sharing procedure, may make decisions such as attempting TXOP sharing with another AP or continuing the frame exchange sequence with the STAs of its BSS. However, in this case, there is a problem in that the process of the AP, which is the TXOP holder, transmitting a frame for TXOP sharing and the process of receiving a response frame act as unnecessary overhead.

[0367] Therefore, an AP that has performed a consultation regarding C-TDMA can help prevent the other AP from unnecessarily transmitting frames for TXOP sharing by indicating whether it has a need (intention) to be allocated a Shared TXOP through the TXOP sharing procedure. However, the need for each AP to be allocated a Shared TXOP may change in real time (e.g., depending on the queue state), and therefore, it may need to be indicated / interpreted as an intention for the corresponding TXOP segment at the start of each TXOP.

[0368] To explain more specifically, an AP that wishes to receive a shared TXOP may instruct the AP that holds the TXOP whether it has a need (intention) to receive and use the shared TXOP during the relevant TXOP. In this case, the AP that holds the TXOP may attempt to share the TXOP with the other AP within the TXOP it has acquired. An AP that does not wish to receive a shared TXOP may instruct the AP that holds the TXOP that it has no need to receive and use the shared TXOP during the relevant TXOP. In this case, the AP that holds the TXOP may not send a frame for TXOP sharing to the AP that instructed it has no need to receive and use the shared TXOP within the TXOP it has acquired.

[0369] To this end, if an AP that is a TXOP holder indicates its intention to perform TXOP sharing through an initial frame it transmits, the AP that has consulted with the AP that is the TXOP holder for C-TDMA may use a response frame to the initial frame to indicate whether it needs to receive and use the shared TXOP. That is, if an AP that is a TXOP holder transmits an initial frame to a counterpart AP and indicates its intention to perform TXOP sharing, the counterpart AP may indicate through a response frame whether it has an intention to receive and use the shared TXOP.

[0370] That is, a first AP that intends to acquire and share a TXOP may transmit an initial frame to at least one AP that includes a subfield indicating whether to share part or all of the acquired TXOP. The at least one AP that receives the initial frame transmits a frame that includes a subfield indicating whether to share the TXOP acquired by the first AP as a response to the initial frame. After receiving a frame that includes a subfield indicating whether to share the TXOP from at least one AP, the first AP may share the TXOP by selecting one of the at least one AP that transmitted a frame that includes a subfield set to a value indicating that the TXOP is shared.

[0371] Meanwhile, the AP that is the TXOP holder may have conducted consultations regarding C-TDMA with multiple APs individually, and in this case, the AP must perform the aforementioned procedure to verify the necessity of the Shared TXOP with the multiple APs. Therefore, the AP that is the TXOP holder can receive a response from the multiple APs regarding whether they intend to utilize the Shared TXOP by transmitting an initial frame with the multiple APs as destination devices. To this end, the AP that is the TXOP holder can utilize the aforementioned initial frame as a trigger frame of a specific format (a type of control frame) and use the trigger frame to request a response PPDU from the multiple APs. At this time, the PPDU transmitted by the multiple APs may be a TB PPDU (Trigger-based PPDU). More specifically, the AP that is the TXOP holder transmits a trigger frame using the initial frame of the TXOP it has acquired, and the trigger frame requests a TB PPDU response from one or more APs. That is, the trigger frame may have a configuration that includes a user information field for each of the one or more APs. At this time, the trigger frame transmitted by the AP that is the TXOP holder can be interpreted as indicating to the AP to which a response to the TB PPDU is requested that the AP that is the TXOP holder has an intention to perform TXOP sharing. That is, an AP that has received a trigger frame from a counterpart AP and has confirmed that the trigger frame is requesting its own TB PPDU response can recognize that the counterpart AP has an intention to perform TXOP sharing to it. At this time, the target AP to which a response to the TB PPDU is requested through the trigger frame can be limited to the AP that has performed C-TDMA related consultation with the AP transmitting the trigger frame.An AP that receives a request for a TB PPDU response (via a trigger frame) from an AP that is a TXOP holder can indicate whether it intends to receive and use the Shared TXOP or not. In this case, the indication can be performed using the value of a specific subfield of the frame included in the TB PPDU. For example, an AP responding with the TB PPDU can indicate that it has no intention of receiving and using the Shared TXOP by setting the value of the specific subfield to 0. In this case, an AP responding with the TB PPDU can indicate that it has an intention of receiving and using the Shared TXOP by setting the value of the specific subfield to a non-zero value. In this case, an AP that has no intention of receiving and using the Shared TXOP can implicitly indicate that it has no intention of receiving and using the Shared TXOP by not performing a TB PPDU response to the received trigger frame. That is, if the AP that is the TXOP holder does not receive a TB PPDU response from a specific AP for the initial frame it transmitted, the AP may interpret that the specific AP has no intention of receiving and using the Shared TXOP. In this case, the value of the specific subfield can be additionally utilized to indicate a value related to the length of the Shared TXOP to be received. That is, an AP that wishes to receive a relatively long Shared TXOP can set the specific subfield to a value greater than the value set by an AP that wishes to receive a relatively short Shared TXOP. Based on the values ​​indicated by each AP through the specific subfield, the AP that is the TXOP holder can adjust the order in which TXOP sharing is performed for each AP and / or the length of the TXOP allocated through TXOP sharing.At this time, the information indicated through the specific subfield above may be the queueing traffic (buffer status) of the AP responding to the TB PPDU or the length of the shared TXOP that is desired to be shared.

[0372] Additionally, an AP that responds with a TB PPDU after receiving a trigger frame from a counterpart AP can indicate information regarding the urgency of the traffic it intends to transmit during the Shared TXOP (e.g., whether it is low-latency traffic and / or delay-bound information, etc.) through the TB PPDU (more specifically, through the frame included in the TB PPDU). In this case, the AP that is the TXOP holder can use the information indicated by multiple APs that responded with the TB PPDU to prioritize the TXOP sharing procedure for the AP considered to be the most urgent.

[0373] For example, if a first AP that has acquired a first TXOP wishes to share a second TXOP, which is part or all of the first TXOP, with at least one AP, the first AP may notify the at least one AP of the sharing of the second TXOP by transmitting a specific frame (e.g., an initial frame or a trigger frame). In this case, the specific frame may include duration information of the second TXOP being shared. Subsequently, the first AP may receive a PPDU (or TB PPDU) from at least one AP in response to the specific frame. The PPDU (or TB PPDU) may or may not include a subfield indicating whether to receive the sharing of the second TXOP. Additionally, if at least one AP wishes to share the second TXOP, the PPDU (or TB PPDU) may include characteristics of the traffic to be transmitted and received during the second TXOP (e.g., the urgency (or priority) of the traffic, the delay bound, the amount of wireless resources required, the traffic identifier (ID) and / or access category (AC) at least one).

[0374] If there are two or more APs that wish to share the second TXOP, the first AP may select the second AP to share the second TXOP based on the characteristics of the traffic included in the PPDU (or TB PPDU). For example, the first AP may select the second AP based on the urgency of the traffic among the characteristics of the traffic. That is, the first AP may select the AP that has the traffic that is judged to need to be transmitted most quickly as the second AP.

[0375] According to one embodiment of the present invention, when an AP that is a TXOP holder receives a TB PPDU as a response to an initial frame transmitted by itself, it must transmit a response frame to other APs. At this time, the response frame may be considered as a response to the TB PPDU or as a response to a frame included in the TB PPDU. At this time, if the AP that is a TXOP holder successfully receives a TB PPDU that is a response to the initial frame transmitted by itself, it must transmit a response frame for the TB PPDU after SIFS from the end time of the TB PPDU.

[0376] The response frame transmitted by the AP that is the TXOP holder serves to help other APs determine whether the AP that is the TXOP holder has successfully received the TB PPDU that they transmitted. That is, an AP that receives a response frame after responding to the initial frame transmitted by the AP that is the TXOP holder with a TB PPDU can confirm that the AP that is the TXOP holder has successfully received the TB PPDU that they responded to (i.e., the instruction regarding participation in their TXOP sharing procedure responded to via the TB PPDU). If the response frame for the TB PPDU that they responded to is not received from the AP that is the TXOP holder, or if the said response frame is not successfully received, the AP that transmitted the TB PPDU may decide to perform an alternative action considering that the TXOP sharing procedure for itself will not be performed within the corresponding TXOP.

[0377] Additionally, the response frame transmitted by the AP that is the TXOP holder can further perform the function of specifying the AP that is the target of the TXOP sharing procedure to be performed within the TXOP. In other words, after receiving the TB PPDU transmitted from the other APs, the AP that is the TXOP holder can specify the target AP to share the Shared TXOP through the response frame. For example, after transmitting an initial frame and receiving TB PPDU responses from the first, second, and third APs, the TXOP holder AP can indicate to the one AP that it intends to share the Shared TXOP by transmitting a response frame indicating one of the three APs. If the AP that is the TXOP holder instructs the first AP that it intends to share the Shared TXOP, the first AP may decide that the Shared TXOP waits for sharing while the AP that is the TXOP holder is operating the TXOP, and the second and third APs may decide to perform an alternative operation (channel access using Power save or Spatial reuse, or NPCA operation) while the AP that is the TXOP holder is operating the TXOP. In this case, the NPCA operation refers to a procedure for performing a channel access operation through a secondary subchannel not occupied by the OBSS (one of the subchannels excluding the Primary 20 MHz subchannel) during the time that the OBSS occupies the band including its Primary 20 MHz subchannel. Since the NPCA operation is not related to the main concept of the present invention, a detailed description is omitted.

[0378] When an AP that is a TXOP holder sends a response frame after receiving a TB PPDU sent by other APs, it may respond using the non-HT (duplicated) PPDU format. The reason for sending the response frame using the non-HT (duplicated) PPDU format is that the channels on which each AP needs to receive the response frame operates may be different, and to support the successful reception of the response frame regardless of which 20 MHz subchannel the other AP receives the PPDU through.

[0379] Alternatively, when an AP that is a TXOP holder transmits a TB PPDU transmitted by other APs and then transmits a response frame, it is possible to respond using the DL MU PPDU format. In this case, the DL MU PPDU has a configuration that allocates a RU corresponding to the band to which each AP responded with the TB PPDU to each AP. That is, an AP that transmitted a TB PPDU to an AP that is a TXOP holder through a specific RU can receive a response frame for the TB PPDU it responded to through the said specific RU.

[0380] The frame type of the response frame transmitted by the AP that is the TXOP holder may be a Multi-STA BlockAck frame. A Multi-STA BlockAck frame has a configuration that includes response portions (Per AID TID Info fields) for multiple STAs (including the counterpart AP) within a single frame. Therefore, each STA receiving a Multi-STA BlockAck frame can verify whether it has successfully received the frame it transmitted through the Per AID TID Info field, which indicates its own AID, among the fields included in the Multi-STA BlockAck frame. If there is only one AP that responded with the TB PPDU, the AP that is the TXOP holder can respond with an Ack frame as a response to the received TB PPDU. When the Ack frame is responded to, the intention to perform TXOP sharing is transmitted from the AP that is the TXOP holder to the counterpart AP (the receiving AP).

[0381] APs that have transmitted TB PPDUs can verify whether the TB PPDU they transmitted has been successfully received by the TXOP holder AP through the Per AID TID Info field corresponding to their own AID included in the Multi-STA BlockAck frame transmitted by the TXOP holder AP. At this time, each AP uses the AID assigned when performing Multi-AP Coordination with the TXOP holder AP as its own AID. That is, during the process of performing Multi-AP Coordination, APs designate each other's AIDs and can determine whether the target device of the frame transmitted by the other is themselves by comparing the corresponding AID with the value of the AID12 (or AID11) field indicated by the received frame. Since the process of performing Multi-AP Coordination is not significantly related to the main concept of the present invention, a detailed description is omitted, but it is stated that the two APs pre-designate and use AID values ​​that designate each other.

[0382] The Multi-STA BlockAck frame, which is an acknowledgment frame transmitted by the AP that is the TXOP holder, includes a Per AID TID Info field corresponding to the counterpart AP. At this time, the AID TID Info subfield of the Per AID TID Info field has a configuration including an AID11 subfield, an Ack Type subfield, and a TID subfield, and the AID assigned (assigned) to the counterpart AP in the Per AID TID Info field corresponding to the counterpart AP is indicated by the AID11 subfield (included in the AID TID Info subfield).

[0383] The Ack Type subfield (included in the AID TID Info subfield) of the Per AID TID Info field corresponding to the counterpart AP is always set to 1, indicating that the BlockAck Starting Sequence Control and Block Ack Bitmap subfields are not included in the Per AID TID Info subfield. That is, among the Per AID TID Info fields included in the response frame transmitted by the AP that is the TXOP holder, the Per AID TID Info field corresponding to the counterpart AP has a configuration that does not include any subfields other than the AID TID Info subfield.

[0384] In addition, the AID TID Info subfield of the Per AID TID Info field corresponding to the counterpart AP may use the TID subfield (B12-B15) for a purpose different from the conventional use. Specifically, the TID subfield may not be used as a TID indicator, but may be utilized to indicate whether TXOP sharing is performed and the order of execution. For example, the bits corresponding to the TID subfield (B12-B15 of the AID TID Info subfield) may be replaced and used as a Sharing Order subfield. The Sharing Order subfield may be set to 0 to indicate that the AP that is the TXOP holder will not perform TXOP sharing with the AP corresponding to the AID TID Info subfield. The Sharing Order subfield may be set to a value from 1 to 7 to indicate that the AP that is the TXOP holder plans to perform TXOP sharing for the AP corresponding to the AID TID Info subfield as the 1st to 7th time. For example, an AP that is a TXOP holder can, after receiving TB PPDU from the first AP and the second AP, transmit an AID TID Info subfield with the Sharing Order subfield set to 1 to the first AP through a response frame (transmitting an AID TID Info subfield corresponding to the AID of the first AP) and an AID TID Info subfield with the Sharing Order subfield set to 2 to the second AP (transmitting an AID TID Info subfield corresponding to the AID of the second AP) to indicate that it plans to perform TXOP Sharing to the first AP and perform a second TXOP sharing to the second AP.At this time, the configuration of the Sharing Order subfield is for illustrative purposes only, and it is possible to configure one bit among B12 to B15 to indicate whether TXOP sharing is performed and the remaining three bits to indicate the TXOP sharing order, or to configure it to indicate only whether TXOP sharing is performed (where only one bit is used to indicate whether TXOP sharing is performed, and the remaining three bits are not assigned a separate function or are used for other purposes (other than indicating the TXOP sharing order)). Accordingly, it is stated that the new function provided by the present invention is not limited by a specific format.

[0385] In this way, when the intention to perform TXOP sharing and the intention to utilize the shared TXOP between the AP that is the TXOP holder and the other AP are indicated through the initial frame (a trigger frame transmitted by the AP that is the TXOP holder) and the TB PPDU response (a PPDU responded by the other AP), the AP that is the TXOP holder can perform a procedure to share its TXOP based on the information indicated through the responded TB PPDU. At this time, the AP that is the TXOP holder may additionally instruct each AP whether to perform TXOP sharing and the order in which to perform TXOP sharing through a response frame transmitted after receiving the TB PPDU. The AP that is the TXOP holder may transmit a frame for TXOP sharing (e.g., the MU-RTS TXS trigger frame described above) only to the AP that indicated it would perform TXOP sharing through the response frame it transmitted, among the APs that performed the TB PPDU response to the initial frame. More specifically, the AP that is the TXOP holder can send a frame for TXOP sharing only to the AP that has performed a TB PPDU response to the initial frame and has indicated through the TB PPDU that it intends to share and use the Shared TXOP.

[0386] In the embodiments described above, it was mentioned that it is possible for an AP that is a TXOP holder and an AP that has previously performed C-TDMA-related consultation with the TXOP holder to mutually indicate their intention to perform TXOP sharing and their intention to utilize the shared TXOP by exchanging initial frame / TB PPDUs. Thus, the reason the relationship between the two APs performing TXOP sharing is limited to APs that have established C-TDMA-related consultation may be to restrict TXOP sharing to a relationship where the possibility of mutual cooperation between APs has been verified in advance. However, even for APs that have not yet performed C-TDMA-related consultation, the possibility of performing consultation with each other remains open, and the coordination process between the two APs should be allowed to proceed agilely as needed.

[0387] According to one embodiment of the present invention, a TXOP sharing procedure may be utilized between APs that have not yet performed C-TDMA-related consultation. At this time, the two APs utilizing the TXOP sharing procedure may perform a Multi-AP coordination procedure using the procedure. At this time, the Multi-AP coordination procedure may include performing C-TDMA-related consultation.

[0388] At this time, the TXOP sharing procedure performed between APs that have not performed C-TDMA related consultation can be initiated by allocating an RA-RU through an initial frame transmitted by the AP that is the TXOP holder. The following is a brief description of the procedure for performing TXOP sharing between APs that have not performed C-TDMA related consultation.

[0389] 1. First, the AP that is the TXOP holder allocates an RU for an unspecified AP through the initial frame (trigger frame) it transmits.

[0390] In this case, the RU may be a new type of RA-RU (random access RU) that is not an RA-RU for associated STAs or an RA-RU for unassociated STAs. In this case, the RA-RU may be classified as an RA-RU for coordinated and / or uncoordinated APs. An RA-RU for uncoordinated APs refers to an RA-RU that can be accessed by an AP that has not yet performed coordination with the AP that is the TXOP holder. An RA-RU for coordinated APs refers to an RA-RU that can be accessed by an AP that has performed C-TDMA-related consultation with the AP that is the TXOP holder. An RA-RU for uncoordinated APs and an RA-RU for coordinated APs may be distinguished based on the value indicated by the AID12 subfield of the user information field that assigns each RU. For example, the RU indicated by the user information field where the AID12 subfield is 2043 is an RA-RU for Coordinated APs, and the RU indicated by the user information field where the AID12 subfield is 2044 is an RA-RU for Uncoordinated APs.

[0391] An AP (an AP of the OBSS) connecting to a RU must attempt access using an OFDMA-based random access mechanism. OFDMA-based random access refers to a channel access method using an OCW (OFDMA contention window) and can be performed following the same or similar method as the operation of a non-AP STA performing UORA (UL OFDMA-based random access) on an RA-RU. However, there is a difference in that the OBO counter generated by the AP for use in the OFDMA-based random access procedure is generated using a value indicated by a received initial frame. More specifically, if a value x is indicated for generating the OBO counter through an initial frame transmitted by the AP that is the TXOP holder, the AP accessing the RU(s) allocated to an unspecified AP generates one natural number included in the range from 0 to x as the OBO counter. An AP whose generated OBO counter has a value less than the number of RA-RU(s) allocated to an unspecified AP may randomly select one of the RA-RUs and respond with a TB PPDU. At this time, the OBO counter used by the AP is discarded after determining whether to respond to the TB PPDU, and is regenerated (based on the value indicated by the received initial frame) after receiving the next initial frame.

[0392] 2. Subsequently, an AP that receives an initial frame transmitted by a counterpart AP that has not performed C-TDMA related coordination transmits a response PPDU (TB PPDU) through the RA-RUs for the (uncoordinated) AP assigned through the received initial frame. The response PPDU includes a frame requesting the initiation of a Multi-AP Coordination procedure.

[0393] 3. A TXOP holder AP that receives a frame requesting the initiation of a Multi-AP Coordination procedure in response to an initial frame it transmitted performs a MAP coordination procedure with the counterpart AP that requested the initiation of the Multi-AP Coordination procedure while its TXOP is in progress.

[0394] An AP that is a TXOP holder can initiate the coordination procedure by sending a Multi-AP Coordination Request frame to an AP that has sent a frame requesting the initiation of the Multi-AP Coordination procedure via a TB PPDU. The Multi-AP Coordination procedure can be performed through a frame exchange sequence including a Multi-AP Coordination Request frame, a Multi-AP Coordination Response frame, and a Multi-AP Coordination Confirm frame (Ack frame). The two APs performing the Multi-AP Coordination procedure exchange information regarding the types of Multi-AP Coordination operations they can support, and proceed with a series of procedures such as reaching an agreement on the functions to be coordinated between the two APs and determining parameters that must be pre-agreed upon for each function. The types of Multi-AP Coordination operations may include C-TDMA, Coordinated Spatial Reuse (C-SR), and Coordinated Restricted TWT (Co-rTWT). Other functions and specific coordination procedures, excluding C-TDMA which is the subject of Multi-AP Coordination, are not significantly related to the C-TDMA (TXOP sharing performed between APs) execution method intended to be provided in this invention, so a detailed explanation is omitted.

[0395] In the example described above, if the initial frame transmitted by the AP that is the TXOP holder is a trigger frame requesting a response to the TB PPDU, the counterpart APs that receive the initial frame from the AP that is the TXOP holder may need to interpret the RU Allocation subfield included in the trigger frame based on the operating channel of the BSS operated by the AP that is the TXOP holder. At this time, interpreting the RU Allocation subfield based on the operating channel of the BSS operated by the AP that is the TXOP holder means that the RU Allocation subfield must be interpreted in such a way that the STA of the BSS operated by the AP that is the TXO holder obtains the same interpretation result as the RU Allocation subfield. For example, if the RU Allocation subfield included in the initial frame is set to a value indicating a 242-tone size RU located in the lowest frequency range within the operating BW, the counterpart APs receiving the initial frame must interpret the RU indicated by the RU Allocation subfield as indicating a 242-tone size RU located in the lowest frequency range among the frequency ranges included in the operating channel (bandwidth) of the BSS operated by the TXOP holder AP, and must not interpret it as indicating a 242-tone size RU located in the lowest frequency range among the frequency ranges included in the operating channel (bandwidth) of the BSS they operate. To this end, information regarding the operating channel of the BSS each AP operates may be exchanged between APs, and such information may be exchanged during the process of performing Multi-AP Coordination or indicated through the initial frame.At this time, the reason why information related to the operating channel is indicated through the initial frame may be to help interpret the RU Allocation subfield of an AP that has not yet performed Multi-AP Coordination. That is, it is possible to include information related to the operating channel of the BSS operated by the AP that is the TXOP holder only in the initial frame containing RA-RUs for the uncoordinated AP. At this time, the information related to the operating channel may be information including at least one of the operating channel set, operating BW, and location information of the primary 20 MHz subchannel.

[0396] FIG. 23 shows an example of a frame exchange sequence method based on an initial frame transmitted by an AP, which is a TXOP holder, according to an embodiment of the present invention.

[0397] Referring to FIG. 23, UHR AP1 intends to perform a TXOP sharing procedure within the TXOP it has acquired, and to this end, it transmits an initial frame (trigger frame) after completing a backoff procedure. AP1, the TXOP holder, transmits the initial frame with a user information field corresponding to AP2 to check whether AP2 intends to participate in the TXOP sharing procedure. Additionally, AP1, the TXOP holder, additionally includes a user information field corresponding to an unspecified AP in the initial frame to check if there is an AP among other APs excluding AP2 that wishes to participate in the TXOP sharing procedure. At this time, the user information field corresponding to AP2 is set to an AID12 subfield value that is set to a value specifying the AID of AP2, and the user information field corresponding to the unspecified AP is set to an AID subfield value corresponding to the unspecified AP (a pre-specified RA-RUs indicator value for the AP).

[0398] After receiving the initial frame transmitted by AP1, UHR AP2 can recognize that AP1 has requested a TB PPDU response from it. Since AP2 has no intention of participating in the TXOP sharing procedure initiated by AP1, it responds with a TB PPDU frame indicating that it has no intention of participating in the TXOP sharing procedure.

[0399] After receiving the initial frame transmitted by AP1, UHR AP3 confirms through the initial frame that there is a RU assigned to an unspecified AP. At this time, the existence of a RU assigned to the unspecified AP means that a response regarding participation in the TXOP sharing procedure has been requested from the unspecified AP. Accordingly, UHR AP3, which has the intention to participate in the TXOP sharing procedure initiated by AP1, responds with a TB PPDU through the RU assigned to the unspecified AP and conveys to AP1 an instruction that it wishes to participate in the TXOP sharing procedure.

[0400] AP1, having received TB PPDUs from AP2 and AP3, transmits a response frame for the purpose of indicating whether the frames received via the TB PPDUs were successfully received and the plan to operate the TXOP sharing procedure. The response frame indicates to AP2 that it has successfully received the TB PPDU transmitted by AP2 and that it will not initiate the TXOP sharing procedure with AP2. The response frame indicates to AP3 that it has successfully received the TB PPDU and that it plans to initiate the TXOP sharing procedure with AP3.

[0401] Afterwards, AP1 performs a frame exchange procedure with the STAs of the BSS it operates, and then initiates the TXOP sharing procedure to AP3 by transmitting a frame for TXOP sharing (MU-RTS TXS trigger frame) to AP3.

[0402] FIG. 24 shows an example of a format of a response frame for sharing TXOPs between APs according to an embodiment of the present invention.

[0403] The response frame is a BlockAck frame of the Multi-STA BlockAck type. The BA Info field of the Multi-STA BlockAck frame may have a configuration in which the Per AID TID Info subfield is repeated, as shown in FIG. 24 (a). The response frame transmitted by the AP, which is the TXOP holder, after transmitting an initial frame and receiving a TB PPDU from the counterpart AP, includes a Per AID TID Info subfield corresponding to the counterpart AP. At this time, the Per AID TID Info subfield corresponding to the counterpart AP has a configuration in which it includes only the AID TID Info subfield, as shown in FIG. 24 (b), and does not include the Block Ack Starting Sequence Control subfield or the Block Ack Bitmap subfield. At this time, the AID TID Info subfield included in the Per AID TID Info subfield corresponding to the counterpart AP indicates a value corresponding to the AID of the counterpart AP through the AID11 subfield. As shown in FIG. 24 (c), the bit (B11) corresponding to the Ack Type subfield in the AID TID Info subfield corresponding to the counterpart AP is always set to 1. The Sharing Order subfield is set to 0 to indicate that the TXOP sharing procedure is not scheduled to be performed for the AP corresponding to the AID TID Info subfield, and can be set to a non-zero value to indicate that the TXOP sharing procedure is scheduled to be performed and to indicate the order in which it will be performed. The specific method for setting and interpreting the Sharing Order subfield is omitted as it has been described in the above-described embodiment.

[0404] FIG. 25 illustrates an example of a method for utilizing a random access resource unit (RA-RU) allocated to unspecified APs that do not perform M-AP coordination according to an embodiment of the present invention.

[0405] Referring to Fig. 25, UHR AP1 and UHR AP2 are in an uncoordinated relationship, having not yet performed Multi-AP Coordination. When UHR AP1 completes its channel access procedure, it transmits an initial frame allocating RA-RUs to the uncoordinated APs. Upon receiving the initial frame transmitted by AP1, AP2 recognizes that AP1, which is not coordinated with it, has allocated RA-RUs to the uncoordinated APs, and responds with a TB PPDU via the RA-RU. AP2 transmits a frame to AP1 requesting the initiation of the M-AP Coordination procedure via the TB PPDU. After receiving the frame transmitted by AP2, AP1 transmits an M-AP Request frame to AP2 to perform M-AP Coordination with AP2. When the M-AP coordination procedure between AP1 and AP2 is completed, AP1 and AP2 transition to a state where M-AP coordination is complete, i.e., a coordinated relationship.

[0406] In the example of FIG. 25, it is assumed that AP1 transmits a MAP Request frame immediately after receiving a frame requesting M-AP Coordination from AP2, but AP1 and AP2 can perform M-AP Coordination by performing a separate frame exchange sequence at a point when AP1's TXOP has progressed further or after AP1's TXOP has ended. That is, the main function to be provided is that if the initial frame transmitted by the AP that is the TXOP holder assigns an RA-RU to the uncoordinated AP, a request to initiate M-AP coordination between APs can be exchanged through the RA-RU, and the specific timing of M-AP Coordination execution can be changed at any time.

[0407] <Shared TXOP 참여 여부 결정 돕기 위한 시그널링 방법>

[0408] Through the embodiments described above, it has been shown that an AP that is a TXOP holder can indicate its intention to perform TXOP sharing through an initial frame it transmits, specify the AP that is the target of TXOP sharing, or allocate RA-RUs to an unspecified AP. An AP that receives an initial frame from an AP that is a TXOP holder can indicate its intention to participate in the TXOP sharing procedure by responding to the AP that is a TXOP holder whether or not to perform an operation utilizing the Shared TXOP. At this time, it is an obvious and reasonable action for an AP that must decide whether to participate in the TXOP sharing procedure to decide whether to participate in the TXOP sharing or to perform an alternative operation without participating in the TXOP sharing procedure based on which of the benefits obtained by participating in the TXOP sharing procedure and the benefits obtained by performing an alternative operation without participating in the TXOP sharing procedure is greater. However, an AP that receives an initial frame indicating only the intention of the AP, which is the TXOP holder, to perform TXOP sharing cannot gauge the level of expected gain that can be obtained when participating in the TXOP sharing procedure performed by the AP that transmitted the initial frame, and therefore it is difficult to make a rational choice based on the comparison described above.

[0409] Therefore, the AP that is the TXOP holder can include additional information regarding the length of the Shared TXOP that the TXOP sharing procedure it intends to perform is targeting in the initial frame it transmits, so that the other AP can refer to this when deciding whether to participate in the TXOP sharing procedure.

[0410] For example, as in the method described above, APs operate different BSSs. In this case, a specific AP (the first AP) among the APs can acquire a TXOP (for example, by acquiring channel access rights). The first AP can share a second TXOP, which is part or all of the acquired TXOP (the first TXOP), with a specific AP (the second AP) among at least one AP operating a different BSS. At this time, the second TXOP may be included in the first TXOP. For example, the start time of the second TXOP may be after the start time of the first TXOP, and the end time of the second TXOP may be the same as or before the end time of the first TXOP. The first AP may transmit a frame (for example, an initial frame or a trigger frame, etc.) to notify at least one AP of the second TXOP, which is part or all of the first TXOP it acquired, in order to share it. At this time, the frame may include information related to the length of the second TXOP.

[0411] At least one AP that receives the frame can recognize the length of the second TXOP through information related to the length of the second TXOP included in the frame, and can determine whether to participate in the procedure for sharing the second TXOP based on the recognized length of the second TXOP. For example, a specific AP among at least one AP may not participate in the procedure for sharing the second TXOP if the length of the second TXOP is shorter than the duration for transmitting and receiving the frame. Conversely, a specific AP among at least one AP may participate in the procedure for sharing the second TXOP if the length of the second TXOP is equal to or longer than the duration for transmitting and receiving the frame.

[0412] According to one embodiment of the present invention, an AP that is a TXOP holder may indicate information regarding the length of the Shared TXOP it intends to allocate during the corresponding TXOP through an initial frame it transmits. In this case, an AP that determines that the length of the Shared TXOP indicated through the initial frame is sufficiently long may decide to participate in the TXOP sharing procedure (i.e., respond with a TB PPDU indicating an intention to utilize the Shared TXOP). At this time, the AP that receives the initial frame may decide whether to participate in the TXOP sharing procedure by comprehensively using the length of the Shared TXOP indicated through the initial frame and the information of the BW through which the initial frame was transmitted. Since the specific method of decision can be determined according to the internal logic of each AP, specific rules regarding the method of decision are omitted in the present invention.

[0413] Additionally, the TXOP holder may specify the minimum length of the Shared TXOP to be allocated through TXOP sharing by specifying the minimum (guaranteed) length of the Shared TXOP. The TXOP holder AP that specified the minimum Shared TXOP length must allocate a time interval longer than the length specified as the minimum Shared TXOP length to the counterpart AP as the Shared TXOP.

[0414] Additionally, the TXOP holder may provide additional information regarding restrictions on the types of traffic that can be transmitted through the Shared TXOP (e.g., TID (Traffic ID) or AC (Access Category)). If information regarding restrictions on the types of traffic that can be transmitted during the Shared TXOP is provided via the initial frame, the counterpart APs can decide whether to participate in the TXOP sharing procedure based on whether the traffic they intend to transmit is permissible within the Shared TXOP. As a simple example, an AP intending to transmit AC_BE traffic may decide not to participate in the TXOP sharing procedure if it confirms via the initial frame transmitted by the TXOP holder AP that the types of ACs that can be transmitted during the Shared TXOP are restricted to AC_VI. In this case, the information regarding traffic type restrictions provided via the initial frame may indicate whether traffic for each AC or TID can be transmitted individually, or it may indicate that there are no separate traffic type restrictions. At this time, a TXOP holder who has indicated through an initial frame that the transmission of a specific traffic type (specific AC or specific TID) is not restricted must set the traffic restriction rule of the Shared TXOP allocated within the TXOP in a way that does not restrict the said specific traffic type.

[0415] <Shared AP에게 할당된 TXOP의 반환 절차>

[0416] As explained above, the AP that acquired the TXOP (Sharing AP) can allocate a portion of the time interval (Shared TXOP) included in the acquired TXOP to the Shared AP, and the Shared AP can use the Shared TXOP to communicate with member STAs belonging to its BSS. The Shared AP that has performed frame exchange using the Shared TXOP must return the management authority of the TXOP to the Sharing AP before or when the Shared TXOP allocated to it ends. In this case, the meaning of the Shared AP returning the TXOP to the Sharing AP is that the management authority of the frame exchange sequence performed during the TXOP is returned to the Sharing AP (i.e., a TXOP return is performed). That is, if the Shared TXOP allocated to the Shared AP ends, or if the management authority of the TXOP is returned to the Sharing AP before the Shared TXOP ends, the Sharing AP regains management authority over the entire frame exchange sequence performed within the TXOP as the TXOP holder for the duration that its TXOP is maintained.

[0417] This TXOP return procedure can be performed automatically when the Shared TXOP assigned by the Sharing AP to the Shared AP is terminated, or it can be performed through a TXOP Return frame transmitted by the Shared AP.

[0418] The method by which the TXOP return procedure is automatically executed when a Shared TXOP is terminated means that the Sharing AP exercises management authority over the TXOP from the moment the Shared TXOP is terminated, even if no separate instruction is executed between the Shared AP and the Sharing AP when the Shared TXOP is terminated. In this case, the Shared AP must not perform any transmissions not requested by the Sharing AP from the moment the Shared TXOP assigned to it is terminated.

[0419] The method by which the TXOP return procedure is performed via a TXOP Return frame transmitted by the Shared AP may be performed by the Shared AP transmitting a frame of a pre-specified format with the Sharing AP as the destination device. In this case, the Sharing AP that receives the frame of the pre-specified format may recognize that the Shared AP has instructed it to perform a TXOP return. At this time, the Shared AP may also transmit a TXOP Return frame before the Shared TXOP assigned to it by the Sharing AP is terminated, in which case the Shared TXOP is considered to have terminated early. In this case, the TXOP Return frame may refer to a frame containing an A-Control subfield specified in the MAC header. Specifically, the TXOP Return frame may refer to a frame containing an A-Control subfield that includes CAS (Command and status) control information. In this case, the CAS control information included in the TXOP Return frame transmitted by the Shared AP to the Sharing AP includes information instructing a Shared TXOP return. At this time, the A-Control subfield refers to the subfield indicated by the bits corresponding to B2 to B31 when B0 and B1 of the HT Control field of the MAC header of the frame are each set to 1.

[0420] When a Shared TXOP that it shared with a Shared AP is terminated, the Sharing AP may intend to recover administrative authority over the remaining TXOP, or it may not intend to recover administrative authority over the remaining TXOP. If the Sharing AP has a plan for a subsequent action to be performed after the point at which the Shared TXOP is terminated, it may intend to recover administrative authority over the remaining TXOP, and if it does not have a plan for a subsequent action, it may not intend to recover administrative authority over the remaining TXOP.

[0421] Therefore, the Sharing AP can instruct the Shared AP to send or not send the TXOP Return frame to itself when the Shared TXOP is terminated by instructing the Shared AP whether it intends to regain management authority over the remaining TXOPs after the Shared TXOP is terminated. That is, the Sharing AP can instruct the Shared AP whether to send the TXOP Return frame when the Shared TXOP is terminated, and the Shared AP must decide whether to send the TXOP Return frame according to the instructed method.

[0422] A Sharing AP can perform instructions to transmit a TXOP Return frame through a frame transmitted to allocate a Shared TXOP to a Shared AP. That is, a Sharing AP can include an indicator related to the request for transmission of a TXOP Return frame in the MU-RTS TXS Trigger frame transmitted to allocate a Shared TXOP to a Shared AP. In this case, the TXOP Return frame transmission request indicator included in the MU-RTS TXS Trigger frame has a size of 1 bit and can be indicated by a specific value (e.g., 1) to indicate that the transmission of a TXOP Return frame is requested, or by another value (e.g., 0) to indicate that the transmission of a TXOP Return frame is not requested. Thus, while a method of explicitly indicating whether the transmission of a TXOP Return frame is requested can be utilized, it is also possible for the request for transmission of a TXOP Return frame to be implicitly indicated.

[0423] An implicit method for the Sharing AP to instruct the Shared AP on whether to request the transmission of a TXOP Return frame can be performed by utilizing whether the end time of the Shared TXOP allocated to the Shared AP is the same as the end time of the Sharing AP's TXOP. The specific method by which this implicit instruction is performed is such that when the end / expiration time of the Shared TXOP has a time interval greater than a certain time (a kind of threshold) from the end time of the Sharing AP's TXOP, the transmission of the TXOP Return frame is interpreted as being requested, and when the end / expiration time of the Shared TXOP has a time interval less than the end time of the Sharing AP's TXOP, the transmission of the TXOP Return frame is interpreted as not being requested. That is, if the remaining TXOP of the Sharing AP remaining from the time the Shared TXOP ends / expires is longer than a pre-specified time, the transmission of the TXOP Return frame is implicitly requested, and if the remaining TXOP is shorter than the pre-specified time, the transmission of the TXOP Return frame is implicitly indicated as not being requested. Therefore, the Shared AP can determine whether to transmit a TXOP Return frame by comparing the time when the Shared TXOP assigned to it ends with the time when the Sharing AP's TXOP ends. This is an implicit instruction method for a TXOP Return frame request that utilizes the fact that the Sharing AP, which plans to operate using the remaining TXOP after the Shared TXOP has ended, adjusts the time when the Shared TXOP ends to end earlier than the time when its own TXOP ends.

[0424] <Shared TXOP의 연장>

[0425] A situation may arise where a Shared AP, which has been allocated a Shared TXOP from a Sharing AP and is performing frame exchange, is unable to complete its planned operations before the Shared TXOP expires. For example, if a frame transmitted by the Shared AP within the Shared TXOP is not successfully received by the receiving device, the Shared AP may attempt to retransmit the frame. The time taken for this retransmission process acts as a variable that prevents the Shared AP from completing its originally planned operations within the Shared TXOP, and consequently, may result in the loss of the expected gains the Shared AP intended to obtain through the Shared TXOP. Frame exchange by the Shared AP that is interrupted due to the termination of the Shared TXOP may only resume after the Shared AP directly acquires a TXOP or is allocated a new Shared TXOP, and there may be cases where the interruption time of the frame exchange becomes longer than a certain level.

[0426] To prevent such problems, it may be considered to allow the Shared AP to utilize the Shared TXOP for a longer time interval than the time allocated to it. However, since the time interval containing the Shared TXOP is a time interval included within the Sharing AP's TXOP and is a time over which the Sharing AP has management authority, the Shared AP cannot be allowed to indiscriminately extend the use of the Shared TXOP. In other words, the Shared AP can use the Shared TXOP for a longer period than the time allocated to it only if the extension of the Shared TXOP is permitted by the Sharing AP. In this case, the Sharing AP can indicate whether the extension of the Shared TXOP is permitted through an indicator included in the MU-RTS TXS Trigger frame transmitted to the Shared AP.

[0427] A Sharing AP may utilize an extended Shared TXOP interval only if at least one of the following conditions 1 through 4 is satisfied. An extended Shared TXOP interval refers to the interval maintained after the expiration of the Shared TXOP interval explicitly allocated by the Sharing AP. For example, if a Sharing AP allocates a Shared TXOP for 1ms, and the Shared AP uses the Shared TXOP for 2ms, the remaining Shared TXOP after the initial 1ms allocated by the Sharing AP is an extended Shared TXOP.

[0428] 1. Retransmission of frames previously transmitted within a Shared TXOP

[0429] A Shared AP can perform transmission in an extended Shared TXOP interval only when retransmitting a frame transmitted within the time interval allocated by a Sharing AP.

[0430] 2. Sending a response PPDU for the PPDU received during a Shared TXOP

[0431] An AP that receives a TB PPDU during a Shared TXOP may use the extended Shared TXOP to send an acknowledgment frame (e.g., a Multi-STA BlockAck frame). In this case, an additional restriction may be applied that the acknowledgment frame cannot be aggregated with other frames (e.g., QoS data frames).

[0432] 3. Low-latency traffic transmission

[0433] A Shared AP may use an extended Shared TXOP only when it intends to transmit low-latency traffic. That is, during the extended Shared TXOP interval, only the transmission of frames classified as low-latency traffic is allowed.

[0434] 4. When performing a transmission under conditions identical to the following conditions allowed to exceed the TXOP limit in the 802.11 standard

[0435] - Retransmission of a Single MPDU that does not belong to an A-MPDU, where the size of the retransmitted MPDU is the same as the size of the originally transmitted MPDU.

[0436] - If an MSDU or MMPDU is split into 16 fragments, transmission of the fragments.

[0437] - Transmission of the 16th dynamic fragment of MSDU or MMPDU

[0438] - The first transmission of an MSDU or MMPDU that does not belong to an A-MPDU containing only one MPDU, containing a first dynamic fragment of the same size as the minimum fragment size specified by the receiving STA.

[0439] - A-MPDU transmission consisting of the initial transmission of a single MPDU that does not contain MSDU and is not an individually unaddressed management frame

[0440] - Transfer of group-addressed MPDUs that do not belong to an A-MPDU containing only one MPDU

[0441] - NDP Announcement frame and Sound NDP transmission.

[0442] As previously mentioned, even if the Shared AP satisfies any one of conditions 1 through 4 above, if the Sharing AP does not allow the extension of the Shared TXOP, the Shared AP is not permitted to utilize the extended Shared TXOP. This is because the Sharing AP has full management authority over the Sharing AP's TXOP interval. Therefore, a Shared AP that has used the Shared TXOP for a longer period than the Shared TXOP allocated by the Sharing AP—that is, has used the extended Shared TXOP—must transmit a TXOP Return frame to the Sharing AP immediately upon the termination of the frame exchange using the extended Shared TXOP. At this time, transmitting the TXOP Return frame immediately means transmitting the TXOP Return frame after SIFS from the time of termination of the last PPDU transmitted using the extended Shared TXOP. However, if the time at which the extended Shared TXOP terminates is after the Sharing AP's TXOP interval, the Shared AP may not transmit the TXOP Return frame.

[0443] However, if the Shared TXOP allocated to the Shared AP terminates with a difference of less than a certain time from the Sharing AP's TXOP (i.e., if the aforementioned implicit TXOP return frame non-transmission is instructed), the Shared AP may use the extended Shared TXOP regardless of whether the Sharing AP has allowed the use of the extended Shared TXOP. That is, the Shared AP may arbitrarily operate the extended Shared TXOP when it is not necessary to return the TXOP to the Sharing AP. In this case, the types of traffic that can be transmitted through the arbitrarily extended Shared TXOP are also limited according to conditions 1 to 4 described above.

[0444] FIG. 26 shows the format of elements exchanged between APs for multiple AP cooperative puncturing according to one embodiment of the present invention, and the operating bandwidth and main channel setting state of the APs to which multiple AP cooperative puncturing is applied.

[0445] The names of the sub-fields described below in the present invention are for convenience of explanation and are not limited thereto, and other names may be used. Accordingly, even if the names of the sub-fields differ from one another, they may be considered as the same sub-fields in the embodiments of the present invention if the purpose and function of transmission are identical.

[0446] FIG. 26(a) illustrates the element format exchanged between APs to perform multiple AP cooperative puncturing.

[0447] The Adjusted Puncture Required subfield is a subfield that indicates whether the AP transmitting the element requests the AP receiving the element to support the adjusted puncturing operation. That is, when the first AP transmits the element to the second AP, it may transmit an element with the Adjusted Puncture Required subfield set to 1 to request the second AP to apply adjusted puncturing to the band including its main channel.

[0448] In addition, the Required subfield for adjusted puncturing may additionally indicate information regarding the support conditions for adjusted puncturing. For example, the Required subfield for adjusted puncturing may have different meanings, such as indicating 0 to mean that no support is required, indicating 1 to mean that support for adjusted puncturing is required based on R-TWT SP, and indicating 2 to mean that support for adjusted puncturing is always required.

[0449] In the above example, if a specific AP transmits an element with a corresponding subfield indicated as 1, other APs may need to apply adjusted puncturing when acquiring a TXOP that is expected to overlap with the R-TWT SP of said specific AP. In this case, the element with the corresponding subfield indicated as 1 has a configuration that includes a TWT element.

[0450] In the above example, if a specific AP transmits an element with a subfield set to 2, other APs may always need to apply adjusted puncturing until they receive an element with a subfield set to 0 or 1 from the said specific AP.

[0451] In the above example, if the corresponding subfield is set to a value (e.g., 0) indicating that support for adjusted puncturing is not required, the remaining subfields described below may be reserved or omitted. That is, the subfields described below may be included in the element or interpreted according to their original meaning (not reserved) only when the corresponding subfield is set to a value requiring support for adjusted puncturing.

[0452] The Main Channel Info (Information) subfield indicates information related to the main channel location of the AP transmitting the element. The Main Channel Info subfield can be configured in the same way as the Channel Number field, which is interpreted by the Global operating classes table.

[0453] The Minimum BW Info (Information) subfield contains information regarding the minimum BW that the AP transmitting the element requests from the AP receiving the element. More specifically, the Minimum BW Info subfield indicates the BW size of the band containing the Primary 20 MHz channel to be secured through coordinated puncturing operations. For example, if the AP transmitting the element wishes to secure only the Primary 20 MHz band, it may set the Minimum BW Info subfield to a value representing the 20 MHz band. In this case, the AP receiving the element can support the securing of the Primary 20 MHz channel by transmitting a PPDU that does not occupy the Primary 20 MHz band of the AP transmitting the element. As another example, if the AP transmitting the element wishes to secure the Primary 80 MHz band, it may set the Minimum BW Info subfield to a value representing the 80 MHz band. In this case, the AP that receives the element can support securing the 80 MHz band by transmitting a PPDU that does not occupy the Primary 80 MHz band (an 80 MHz band including a Primary 20 MHz subchannel) of the AP that transmitted the element.

[0454] When a TWT element is included in an element exchanged between APs to perform multi-AP cooperative puncturing, said TWT element indicates information related to the R-TWT SP operating in the BSS of the AP transmitting said element. Another AP that receives an element exchanged between APs to perform multi-AP cooperative puncturing from a specific AP may perform coordinated puncturing by taking into account the R-TWT SP of said specific AP if the element contains a TWT element. In this case, the TWT element may be included in said element only when the coordinated puncturing Required subfield is indicated by a specific value.

[0455] FIG. 26(b) illustrates the Operating BW and Primary subchannel settings of AP1 and AP2 in a relationship capable of performing multiple AP cooperative puncturing.

[0456] Referring to FIG. 26(b), AP1 and AP2 each have an operating bandwidth corresponding to 320 MHz. The primary 160 MHz band of AP1 and the primary 160 MHz band of AP2 are identical, while the primary 80 MHz band of AP1 and the primary 80 MHz band of AP2 are different. In this case, if AP2 instructs AP1 to a value corresponding to the 80 MHz band through the Minimum BW Info subfield (see FIG. 26(a)), AP1 can perform an operation that does not occupy the band (AP1's secondary 80 MHz) that overlaps with AP2's primary 80 MHz band by applying adjusted puncturing when acquiring the TXOP. Through this, even during the time interval when AP1 acquired the TXOP, AP2 can access the frequency resources of the primary 80 MHz and secondary 160 MHz bands after performing the channel access procedure through the primary 20 MHz subchannel.

[0457] FIG. 27 shows an example of a frame exchange sequence with coordinated puncturing applied for AP 2 according to one embodiment of the present invention.

[0458] AP1 and AP2 in FIG. 27 are APs having the same Operating BW and main channel settings as AP1 and AP2 shown in FIG. 26(b).

[0459] AP2 transmits a coordination request frame to AP1 through its primary 160 MHz band. At this time, the coordination request frame is a frame having a configuration including the element shown in FIG. 26(a), through which AP2 requests AP1 to apply a coordinated puncturing to its primary 80 MHz band, and after receiving the coordination request frame from AP2, AP1 responds with a coordination response frame accepting the requested coordination operation.

[0460] Therefore, when AP1 acquires a TXOP, it occupies the 80 MHz band in a 160+80 MHz form, which is a punctured 80 MHz band from a 320 MHz PPDU, so as not to occupy AP2's primary 80 MHz band. At this time, the punctured 80 MHz band is the same band as AP2's primary 80 MHz band. Therefore, AP1's TXOP is acquired and proceeds without occupying AP2's primary 80 MHz band, and even during the process where AP1 transmits a DL PPDU to STA1 and receives a BA (BlockAck) frame as an acknowledgment, AP2 can acquire channel access rights through EDCA performed on the primary 20 MHz subchannel.

[0461] Although LL traffic requiring low latency support is generated while AP1's TXOP is in progress, AP2 can process the LL traffic through the Primary 80 MHz band without delaying the transmission of the LL traffic until AP1's TXOP is finished.

[0462] In addition, AP2 can transmit and receive LL traffic through the unoccupied P80 MHz band by applying a puncturing operation adjusted by AP1 to the R-TWT SP, even though AP1's TXOP is in progress.

[0463] FIG. 28 shows another example of a frame exchange sequence with adjusted puncturing applied for AP 2 according to one embodiment of the present invention.

[0464] AP1 and AP2 in FIG. 28 are APs having the same Operating BW and main channel settings as AP1 and AP2 shown in FIG. 26(b).

[0465] AP2 transmits a coordination request frame to AP1 through its primary 160 MHz band. At this time, the coordination request frame is a frame having a configuration including the element shown in FIG. 26(a), through which AP2 requests AP1 to apply a coordinated puncturing to its primary 80 MHz band, and after receiving the coordination request frame from AP2, AP1 responds with a coordination response frame accepting the requested coordination operation.

[0466] AP1 transmits the RTS frame and DL PPDU#1 across the 320 MHz band because the RTS frame transmitted to acquire the TXOP and DL PPDU#1 do not overlap temporally with AP2's R-TWT SP. However, AP1 transmits DL PPDU#2 in the form of a 160+80 MHz PPDU because DL PPDU#2 overlaps with AP2's R-TWT SP, thereby continuing the TXOP without occupying AP2's Primary 80 MHz band.

[0467] AP2 can transmit and receive LL traffic through the P80 MHz band during the R-TWT SP period because AP1 has applied a puncturing operation adjusted to the R-TWT SP, even though AP1's TXOP is in progress.

[0468] At this time, AP2 ignores the NAV and accesses its own P80 MHz band, even if the NAV set by the RTS frame transmitted by AP1, DL PPDU#1, is not 0. This is AP2's NAV-ignoring operation, taking into account that AP1, the TXOP holder, is a device that has performed coordination with it.

[0469] FIG. 29 shows an example of an element format transmitted by an AP performing a multi-AP cooperation operation according to an embodiment of the present invention to instruct the STAs of its BSS about information related to channel access restrictions.

[0470] FIG. 29(a) illustrates the UHR Operation Parameters field format. The Disabled Subchannel Bitmap Present subfield is a subfield that indicates whether the Disabled Subchannel Bitmap subfield is included in the UHR Operation element. The Disabled Subchannel Bitmap Present subfield is set to 1 when the Disabled Subchannel Bitmap subfield is included in the UHR Operation element, and to 0 when it is not included. The Disabled Subchannel Bitmap Resolution subfield indicates whether each bit of the Disabled Subchannel Bitmap included in the UHR Operation element corresponds to how many 20 MHz subchannels. The Disabled Subchannel Bitmap Resolution subfield is Reserved when the Disabled Subchannel Bitmap Present subfield is indicated as 0. If the Disabled Subchannel Bitmap Resolution subfield is indicated as 0, it means that each bit of the Disabled Subchannel Bitmap included in the UHR Operation element corresponds to one 20 MHz subchannel; if indicated as 1, it means that each bit of the Disabled Subchannel Bitmap included in the UHR Operation element corresponds to two 20 MHz subchannels; and if indicated as 2, it means that each bit of the Disabled Subchannel Bitmap included in the UHR Operation element corresponds to four 20 MHz subchannels.At this time, the setting value and meaning of the Disabled Subchannel Bitmap Resolution subfield are for illustrative purposes only, and it is possible to indicate / interpret it with other meanings, such as indicating 1 to mean one 20 MHz subchannel, indicating 2 to mean two 20 MHz subchannels, or indicating 3 to mean four 20 MHz subchannels.

[0471] FIG. 29(b) illustrates the UHR Operation element format. The UHR Operation element includes a Disabled Subchannel Bitmap subfield, and each bit of the Disabled Subchannel Bitmap subfield corresponds to each subchannel within the Operating BW. In this case, a specific bit of the Disabled Subchannel Bitmap subfield may correspond to multiple subchannels, which may be determined by the Disabled Subchannel Bitmap Resolution subfield described in FIG. 29(a). The Disabled Subchannel Bitmap subfield may have a size of 1, 2, or 4 octets. In this case, the size of the Disabled Subchannel Bitmap subfield is determined based on the Operating BW size of the BSS and the Resolution information indicated in the Disabled Subchannel Bitmap Resolution subfield.

[0472] For example, if the BSS operating BW is 640 MHz, a 4-octet Disabled Subchannel Bitmap consisting of 32 bits corresponding to each of the 32 20 MHz subchannels included in the 640 MHz may be specified. In this case, the Disabled Subchannel Bitmap Resolution subfield is set to a value indicating that each bit of the Disabled Subchannel Bitmap corresponds to one 20 MHz subchannel. If the Disabled Subchannel Bitmap Resolution subfield indicates that each bit of the Disabled Subchannel Bitmap corresponds to two 20 MHz subchannels, the Disabled Subchannel Bitmap transmitted by the AP of the BSS with a 640 MHz operating BW has a size of 2-octets. If the Disabled Subchannel Bitmap Resolution subfield indicates that each bit of the Disabled Subchannel Bitmap corresponds to four 20 MHz subchannels, the Disabled Subchannel Bitmap transmitted by the AP of the BSS with a 640 MHz operating BW has a size of 1 Octet.

[0473] As another example, if the BSS operating BW is 320 MHz, a 2-octet Disabled Subchannel Bitmap consisting of 16 bits corresponding to each of the 16 20 MHz subchannels included in the 320 MHz can be indicated. Therefore, for an AP of a BSS with a 320 MHz operating BW, the Disabled Subchannel Bitmap subfield cannot be configured to a size of 4 octets. If the Disabled Subchannel Bitmap Resolution subfield indicates that each bit of the Disabled Subchannel Bitmap corresponds to two 20 MHz subchannels, the Disabled Subchannel Bitmap transmitted by the AP of a BSS with a 320 MHz operating BW has a size of 1 octet.

[0474] The above-described UHR Operation Parameters field and UHR Operation element may be transmitted by being included in Beacon frames, Probe Response frames, combined Response frames, etc. transmitted by the AP, or may be transmitted by being included in frames transmitted by the AP to change the Operating Mode.

[0475] Figure 29 (c) illustrates a modified puncturing element format. The modified puncturing Subchannel Bitmap subfield is a subfield that indicates information about the subchannel to which modified puncturing, adjusted by multi-AP cooperative operation, should be applied. The number of bits included in the modified puncturing Subchannel Bitmap subfield is (the largest operating BW supported by UHR / 20 MHz). For example, if the largest operating BW supported by UHR is 640 MHz, the modified puncturing Subchannel Bitmap subfield may consist of 32 bits.

[0476] The first bit of the adjusted puncturing subchannel bitmap subfield corresponds to the 20 MHz subchannel located at the lowest position on the frequency axis among the subchannels included in the operating BW, and the x-th bit corresponds to the x-th 20 MHz subchannel in order of lowest on the frequency axis among the subchannels included in the operating BW. Therefore, if the operating BW of the BSS is limited, only the first x bits of the adjusted puncturing subchannel bitmap subfield may correspond to each 20 MHz subchannel, and the remaining bits from the x+1-th may not correspond to any subchannel. Consequently, the bits of the adjusted puncturing subchannel bitmap subfield for which no corresponding 20 MHz subchannel exists are set to a preset value (e.g., 0).

[0477] When a specific bit of the regulated puncturing Subchannel Bitmap subfield is set to 1, it means that the subchannel corresponding to said specific bit is a subchannel to which regulated puncturing must be applied. Therefore, if a specific bit of the regulated puncturing Subchannel Bitmap subfield received from the AP is indicated as 1, non-AP STAs may need to transmit a PPDU without occupying the subchannel corresponding to said specific bit. That is, if a specific bit of the regulated puncturing Subchannel Bitmap subfield is indicated as 1, non-AP STAs must set the bit corresponding to said specific bit (the bit corresponding to the same subchannel) among the bits of the TXVECTOR parameter INACTIVE_SUBCHANNEL of the PPDU they transmit to 1.

[0478] The Adjusted Puncture Offset subfield is a subfield that indicates information regarding the timing at which the Adjusted Puncture should be applied. The Adjusted Puncture Offset subfield is interpreted together with the Adjusted Puncture Interval subfield to indicate the timing at which the Adjusted Puncture should be applied. Specifically, it means that the Adjusted Puncture should be applied starting from the time point where the value indicated by the Adjusted Puncture Offset subfield is the same as the TSF (Timing Synchronization Function) % Interval (the value indicated by the Adjusted Puncture Interval subfield). In this case, the aforementioned formula symbol % represents the modulation operator (remainder operator). That is, the Adjusted Puncture Offset subfield and the Adjusted Puncture Interval subfield serve to indicate a TSF timer value having the interval indicated by the Adjusted Puncture Interval subfield, and it means that the Adjusted Puncture should be applied to PPDUs transmitted starting from the time point where the TSF timer value is the same as the indicated value. For example, if the adjusted puncturing Offset subfield is set to a value meaning 100 and the adjusted puncturing Interval subfield is set to a value meaning 1000, the TSF values ​​indicated by the two subfields are 100, 1100, 2100, 3100….

[0479] The Adjusted Puncture Duration subfield is a subfield that indicates whether adjusted punctures should be applied for a certain period of time starting from the TSF timer value specified by the Adjusted Puncture Offset subfield and the Adjusted Puncture Interval subfield. That is, non-AP STAs must apply adjusted punctures to PPDUs transmitted during the time interval specified by the Adjusted Puncture Duration subfield, starting from the time indicated by the Adjusted Puncture Offset subfield and the Adjusted Puncture Interval subfield. For example, if the adjusted puncturing Offset subfield is set to a value of 100, the adjusted puncturing Interval subfield is set to a value of 1000, and the adjusted puncturing Duration is specified as 30, non-AP STAs must apply the adjusted puncturing when transmitting PPDUs at TSF values ​​of 100 to 130, 1100 to 1130, 2100 to 2130, and 3100 to 3130.

[0480] In this case, TSF refers to the local timer used by Wi-Fi terminals to synchronize timing, the AP indicates its local timer value through the Time Stamp field of the Beacon frame, and non-AP STAs adjust their TSF timers based on the Time Stamp value received from the AP.

[0481] <AP들 간의 코디네이션이 수행되는 방법 및 절차>

[0482] As described above, APs intending to perform coordination exchange information necessary for coordination operations (e.g., Primary channel information, Minimum puncturing BW information, R-TWT SP information), and then operate their TXOP based on the information instructed by the other AP (acquire TXOP and determine the subchannel to acquire TXOP (apply puncturing, apply BW limit, etc.)).

[0483] Therefore, APs performing coordination operations must be able to transmit and receive necessary information to and from each other; in this case, a method different from how STAs belonging to the same BSS exchange information may be utilized. More specifically, since STAs belonging to the same BSS use the same Primary channel, they can exchange information by utilizing the Primary channel or frequency resources including the Primary channel. However, between APs in BSSs that use different subchannels as Primary channels, exchanging information using the Primary channel may be restricted. For example, if a first AP using a first subchannel as its Primary channel and a second AP using a second subchannel as its Primary channel wish to exchange information, the first and second APs must exchange information through their respective BSS Primary channels and / or the Primary channel of the other AP's BSS. In other words, an agreed-upon method is required for information exchange between APs using different subchannels as Primary channels.

[0484] Furthermore, a procedure for two different APs using different subchannels as primary channels to discover each other in order to perform multi-AP coordination must also be agreed upon; this is to prevent a situation where a specific AP discovers the other AP while the other AP fails to discover the specific AP.

[0485] For reference, in conventional Wi-Fi, to help non-AP STAs easily obtain information about other APs, each AP would include Neighbor Report elements and Reduced Neighbor Report elements in the beacon frames it transmitted. At that time, the elements transmitted by each AP included information such as the operating channel / class and TSF (timing synchronization function) offset of the Neighbor APs recognized by the AP transmitting the element; therefore, a non-AP STA that received the element from a specific AP could obtain information (primary channel information and beacon transmission timing information) for receiving beacon frames from other APs. In other words, a non-AP STA was able to discover other APs using the Neighbor Report elements and / or Reduced Neighbor Report elements received from a specific AP.

[0486] However, conventional Wi-Fi standards did not specify how each AP should verify Neighbor AP information when transmitting the aforementioned element; consequently, it was possible for each AP not to include information about Neighbor APs in the elements, even if it had its own Neighbor APs. Consequently, each AP had no reason to perform thorough discovery operations to identify Neighbor APs and could operate by including only information about the Neighbor APs it was aware of in the elements. In other words, even if a non-AP STA receives a Neighbor Report element and / or a Reduced Neighbor Report element from a specific AP, it is impossible to determine whether the Neighbor APs identified through the elements constitute all of the Neighbor APs of the specific AP.

[0487] As such, APs following conventional Wi-Fi standards acquire / indicate information about Neighbor APs, but may not perform operations to acquire information about all Neighbor APs, and operations to identify Neighbor APs may be performed differently. Consequently, the first AP may recognize that the second AP is its Neighbor AP, but the second AP may not recognize that the first AP is its Neighbor AP (i.e., the existence of the first AP). This asymmetric Neighbor AP recognition phenomenon is not a major problem in conventional Wi-Fi operations that are utilized only to provide information about Neighbor APs to non-AP STAs, but it can act as a cause of coordination failure when such a phenomenon occurs between APs attempting to perform M-AP coordination. Generally, APs using the same subchannel as their primary channel are highly likely to be "discovered" because they can receive beacon frames transmitted by each other, whereas APs using different subchannels as their primary channels are unlikely to be aware of each other because they cannot receive beacon frames from one another.

[0488] For example, the first AP may discover the second AP by receiving a Measurement Report frame from a non-AP STA associated with it, and then attempt to perform M-AP coordination with the second AP. If the second AP is unaware of the existence of the first AP, the series of procedures performed by the first AP to perform M-AP coordination with the second AP may not be recognized by the second AP and could become wasted procedures; in other words, the M-AP coordination procedures introduced by the next-generation standard to improve wireless LAN efficiency may instead result in unnecessary resource utilization.

[0489] Therefore, a procedure must be introduced to ensure that APs intending to perform M-AP coordination discover each other's existence and can transmit and receive frames sent for M-AP coordination.

[0490] According to one embodiment of the present invention, an AP can induce a counterpart AP that receives a frame to perform coordination with it by transmitting a frame indicating that it intends to perform Multi-AP coordination (hereinafter M-AP coordination) or has the capability to perform M-AP coordination. At this time, the frame may be a beacon frame or another type of management frame. At this time, the frame may be transmitted in a non-HT duplicated PPDU format or in a form where a 20 MHz UHR PPDU is duplicated. That is, an AP transmitting the frame in a 160 MHz BW may transmit a 20 MHz non-HT PPDU or a 20 MHz UHR PPDU through each of the eight 20 MHz subchannels included in the 160 MHz BW.

[0491] As such, the reason why a frame transmitted by an AP to perform M-AP coordination must be transmitted in a duplicated PPDU format is to allow a device (e.g., a counterpart AP or a non-AP STA associated with the counterpart AP) that receives the PPDU in any of the subchannels included in the BW where the PPDU is transmitted to receive the frame included in the PPDU through its own (receiving device's) primary 20 MHz channel. To explain in more detail, when a specific AP transmits a frame to perform M-AP coordination through a 20 MHz duplicated PPDU, devices using each subchannel occupied by the PPDU as their primary channel can confirm the frame transmitted by the specific AP by occupying their own primary channel and receiving only the received 20 MHz PPDU (part of the duplicated PPDU). That is, a device of the BSS (AP and / or non-AP STA) that uses a subchannel other than the primary channel of the AP that transmitted the frame as the primary channel can also verify (decode) the frame transmitted by the AP through a 20 MHz PPDU reception operation.

[0492] In this way, each AP can allow devices (AP and / or non-AP STA) in a BSS using different subchannels as primary channels to receive the frame for M-AP coordination that it transmits by transmitting it as a 20 MHz duplicated PPDU, and thus it is possible for the frame for M-AP coordination to be exchanged between APs in a BSS using different subchannels as primary channels.

[0493] A specific AP that receives a frame for M-AP coordination transmitted by another AP can discover that the other AP exists and can also recognize that the other AP has the intention to perform M-AP coordination. If the specific AP also has the intention to perform M-AP coordination with the other AP, the specific AP can transmit the frame for M-AP coordination through the RU located on the other AP's primary channel when transmitting a PPDU that occupies the other AP's primary channel. At this time, the specific AP can transmit the format of the PPDU that occupies the other AP's primary channel as a non-HT duplicated PPDU or a format that duplicates a 20 MHz UHR PPDU.

[0494] As described above, the frame transmitted by an AP to enable other APs to recognize its presence has a function similar to the beacon frame transmitted by an AP to enable non-AP STAs to recognize its presence and capability. For the sake of brevity, the frame transmitted by an AP to be discovered by other APs in this invention will be referred to as an M-AP beacon frame.

[0495] An M-AP beacon frame may contain basic information about the AP transmitting the frame and the BSS operated by that AP. In this case, the M-AP beacon frame includes information to help the counterpart AP receiving the M-AP beacon frame determine whether the AP transmitting the frame and the receiving AP (the counterpart AP) are in a relationship capable of performing coordination. In other words, the AP receiving the M-AP beacon frame can determine whether it and the AP transmitting the frame can perform M-AP coordination operations based on the information indicated through the M-AP beacon frame.

[0496] At this time, a specific method for an AP that receives an M-AP beacon frame to determine whether it and the other AP (the AP that sent the M-AP beacon frame) are in a relationship capable of performing M-AP coordination operations may be based on whether the primary channel of the AP that sent the M-AP beacon frame is a subchannel included in its own operating BW. To explain in more detail, if the primary channel of the AP that sent the M-AP beacon frame is a subchannel not included in its own operating channel, the AP that received the M-AP beacon frame may determine that M-AP coordination between itself and the AP that sent the M-AP beacon frame is impossible. At this time, the reason for not checking whether the Primary channel of the First AP that received the M-AP beacon frame is included in the Operating channel of the Second AP that transmitted the M-AP beacon frame is that the situation in which the M-AP beacon frame transmitted by the Second AP is received by the First AP occurs only when the Operating channel of the Second AP (or the BSS operated by the Second AP) includes a subchannel corresponding to the First AP's primary channel.

[0497] In addition, even if an AP that receives an M-AP beacon frame confirms that the primary channel of the AP that transmitted the frame is included in its own operating channel, it must check whether the other AP supports the M-AP coordination operation to be performed. The M-AP coordination operation that can be utilized between APs may include at least one of the following.

[0498] 1. Multi-AP Spatial Reuse (Coordinated Spatial Reuse)

[0499] - Spatial Reuse technique using information exchanged in advance between APs performing coordination.

[0500] - Each AP can perform transmission power regulation for spatial reuse.

[0501] A Shared AP that has identified the destination device of the transmission performed by the Sharing AP, which is the TXOP holder, can perform Spatial Reuse based on interference-related information acquired in advance.

[0502] 2. Multi-AP Coordinated resource sharing

[0503] - Coordinated TDMA: The Sharing AP, acting as the TXOP holder, allocates a portion of the time interval included in the acquired TXOP to the Shared AP, and the Shared AP uses the allocated time interval to service the non-AP STAs of the BSS it operates (transmitting DL PPDU or Trigger frames).

[0504] - Coordinated OFDMA: A Sharing AP that is a TXOP holder allocates some of the RUs included in the BW in which it acquired the TXOP to a Shared AP, and the Shared AP can use the allocated RUs to transmit DL PPDUs or Trigger frames.

[0505] 3. Multi-AP R-TWT protection (R-TWT coordination, Coordinated R-TWT)

[0506] - APs performing coordination exchange R-TWT (restricted-TWT) information operating in their respective BSSs. Each AP restricts the TXOP length or limits the subchannels acquiring the TXOP, taking into account the start time of the other AP's R-TWT SP. Through this, each AP can perform channel access at the start time of the R-TWT SP.

[0507] 4. Multi-AP joint sounding / transmission

[0508] - The APs that performed coordination perform sounding with the STAs belonging to the BSS operated by each AP, and through this, perform joint transmission.

[0509] - When joint transmission is performed, transmission from the specific AP and another AP may be performed simultaneously to the specific STA associated with the specific AP.

[0510] - When joint transmission is performed, when the specific AP transmits to the specific STA associated with the specific AP, the other AP may perform nulling (MIMO technology) to reduce interference with the specific STA.

[0511] 5. Multi-AP Coordinated Puncturing

[0512] - APs that have performed M-AP Coordination apply puncturing to each other's primary channels, thereby preventing a situation where another AP's BSS is unable to perform channel access due to transmissions performed by its own BSS. Since this operation is provided in the aforementioned invention, a detailed explanation is omitted.

[0513] As listed above, if multiple M-AP Coordination operations are defined, each AP may support all M-AP Coordination operations or only some of them. Therefore, each AP must determine whether to perform M-AP Coordination after verifying whether the other AP supports the M-AP Coordination operation it intends to perform with the other AP, based on the information indicated by the other AP via the M-AP Beacon Frame. For example, an AP that receives an M-AP Beacon Frame transmitted from a other AP determines, based on the information contained in the received frame, whether the other AP supports the M-AP Coordination it intends to perform with the other AP. It then proceeds with the procedure to perform M-AP Coordination with the other AP only if the other AP supports the said M-AP Coordination. Conversely, if it is determined that the other AP does not support the M-AP Coordination it intends to perform with the other AP, the AP may not attempt to perform M-AP Coordination with the other AP. In this case, the action performed by the AP to perform M-AP Coordination with the recipient who sent the received M-AP beacon frame may be to transmit its own M-AP beacon frame to the band occupying the band including the other AP's primary channel. In this case, the action performed by the AP to perform M-AP Coordination with the recipient who sent the received M-AP beacon frame may be to transmit its own M-AP coordination request frame to the band occupying the band including the other AP's primary channel.In this case, the M-AP coordination request frame is a frame containing information indicating the M-AP Coordination operation it supports and / or information indicating the M-AP Coordination operation it intends to perform with the counterpart AP. Additionally, the M-AP coordination request frame may have a configuration that includes an indicator of the counterpart AP with which it intends to perform M-AP Coordination. In this case, the AP that receives the M-AP coordination request frame can recognize that the AP that sent the M-AP coordination request frame intends to perform M-AP Coordination with it, and can recognize what kind of M-AP operation coordination is being requested.

[0514] An AP transmitting an M-AP coordination request frame can enable an AP receiving the M-AP coordination request frame to recognize that an M-AP coordination request has been made to it by transmitting a PPDU containing an indicator related to the AP for which it intends to perform coordination. At this time, the AP transmitting the M-AP coordination request frame can enable the other AP to recognize that M-AP coordination has been requested to it by indicating the MAC address of the other AP through the RA field (Receiver address field) of the M-AP coordination request frame. At this time, the AP transmitting the M-AP coordination request frame can enable the other AP to recognize that M-AP coordination has been requested to it by indicating the color of the BSS operated by the other AP through the BSS Color field included in the Preamble of the 20 MHz duplicated UHR PPDU it transmits. In this manner, if an AP transmitting an M-AP coordination request frame specifies the BSS Color field of the PPDU as the Color of the BSS operated by the counterpart AP, non-AP STAs that are members of the BSS operated by the counterpart AP recognize the corresponding PPDU as an intra-PPDU; consequently, the M-AP Coordination frame receives a higher level of protection from non-AP STAs. (Although this has effects such as preventing non-AP STAs from attempting Spatial Reuse operations based on BSS color, a detailed explanation is omitted as it is not significantly related to the main concept intended by this invention.)

[0515] The process of discovering each other among APs having different primary channels, recognizing the type of M-AP Coordination supported by the other AP, and performing M-AP Coordination is explained in detail through the embodiments of the present invention described below.

[0516] FIG. 30 shows an example of a frame format used in a multi-AP coordination process according to an embodiment of the present invention.

[0517] The names of the frames described in FIG. 30 are for the convenience of explanation, and each frame is not limited thereto and may be referred to by a different name. Furthermore, the names of each field included in each frame may be changed, or some fields may not be included. Additionally, it should be understood that the functional aspects of each frame described through the discovery / M-AP coordination procedure between APs according to the present invention constitute the content of the invention.

[0518] Figure 30 (a) illustrates the M-AP beacon frame format.

[0519] An M-AP beacon frame contains an AP identifier used to identify the AP transmitting the frame. Specifically, an M-AP beacon frame may include an AP ID field. The AP ID field indicates the BSS Color value of the BSS operated by the AP transmitting the M-AP beacon frame. Alternatively, the AP ID field may indicate the MAC address of the AP transmitting the M-AP beacon frame. In other words, the AP ID field functions to help the receiving device recognize the AP that transmitted the frame, and it is also possible for other types of information capable of identifying the transmitting AP to be indicated instead.

[0520] An M-AP beacon frame can be a type of broadcast frame.

[0521] An M-AP beacon frame contains information about the operating channel of the BSS operated by the AP transmitting the frame. Specifically, the M-AP beacon frame includes an operating class field. The operating class indicated by the operating class field can be used to obtain channel starting frequency information, channel spacing information, and channel set information. Therefore, a device receiving an M-AP beacon frame can know the operating channel information (channel set and bandwidth) of the BSS operated by the AP transmitting the M-AP beacon frame.

[0522] An M-AP beacon frame contains information regarding the main channel of the BSS operated by the AP transmitting the frame. Specifically, the M-AP beacon frame includes a Channel Number field. The Channel Number field is interpreted in combination with the accompanying Operating channel information (indicated via the aforementioned Operating Class field) and functions to identify one of the sub-channels included in the Operating channel (the main channel).

[0523] An M-AP beacon frame contains information regarding the TSF value of the AP transmitting the frame. Specifically, an M-AP beacon frame includes a Timestamp field. The Timestamp field represents the TSF timer value of the STA (AP STA and / or non-AP STA) transmitting the frame. In this case, the Timestamp field included in the M-AP beacon frame may have a size equal to or smaller than the Timestamp field (8-octet) included in a standard beacon frame. The Timestamp field is used by the AP receiving the M-AP beacon frame to calculate its own TSF offset with that of the AP transmitting the M-AP beacon frame. An AP that wishes to perform timing synchronization with the AP transmitting the M-AP beacon frame can adjust its own TSF timer using the Timestamp field of the received M-AP beacon frame.

[0524] An M-AP beacon frame indicates the type of M-AP coordination operation supported by the AP transmitting the frame. Specifically, an M-AP beacon frame may include an M-AP Coordination Support Bitmap field. In this case, each bit included in the M-AP Coordination Support Bitmap may be set to indicate whether a specific M-AP coordination function is supported. For example, the first bit of the M-AP Coordination Support Bitmap field (e.g., B0) may be set to 1 to indicate support for a specific M-AP coordination function, or set to 0 to indicate that support for the specific M-AP coordination function is not supported.

[0525] Figure 30 (b) illustrates the M-AP coordination request frame format.

[0526] An M-AP coordination request frame is a frame transmitted by an AP that wishes to perform M-AP coordination with a peer AP, and its basic function is to instruct the peer AP on the type of M-AP coordination it intends to request.

[0527] The M-AP adjustment request frame can be a type of action frame.

[0528] The M-AP coordination request frame includes an AP identifier used to identify the AP transmitting the frame. Specifically, the M-AP coordination request frame may include an AP ID field. The AP ID field indicates the BSS Color value of the BSS operated by the AP transmitting the M-AP coordination request frame. Since this is identical to the AP ID field included in the aforementioned M-AP beacon frame, a redundant explanation is omitted.

[0529] An M-AP coordination request frame may include a Dialog Token field. The Dialog Token field is used to identify which M-AP coordination request frame a response frame corresponds to when a response frame is received after multiple M-AP coordination request frames have been transmitted. In other words, an AP transmitting M-AP coordination request frames configured differently must set the Dialog Token field of each request frame to a different value, and upon receiving a response frame, must verify which M-AP coordination request frame the response corresponds to by checking the value of the Dialog Token field of the received frame.

[0530] The M-AP coordination request frame includes the Operating Class field, Channel Number field, Timestamp field, and M-AP Coordination Support Bitmap. Since these fields have the same configuration / interpretation methods and functions as fields of the same name included in M-AP beacon frames, redundant descriptions are omitted.

[0531] An M-AP coordination request frame includes a Requested M-AP Coordination field. The Requested M-AP Coordination field serves to indicate the M-AP coordination action that the AP transmitting the frame wishes to perform with the counterpart AP. The Request M-AP Coordination field can be composed of a bitmap, and each bit in the Request M-AP Coordination field can correspond to the same M-AP coordination as the bit at the same position included in the M-AP Coordination Support Bitmap field. In other words, a specific M-AP coordination corresponding to a bit at a specific position in the M-AP Coordination Support Bitmap corresponds to a bit at the same position in the Requested M-AP Coordination field. For example, if the B0 bit in the M-AP Coordination Support Bitmap corresponds to M-AP Coordinated Puncturing, the B0 bit in the Requested M-AP Coordination field also corresponds to M-AP Coordinated Puncturing. Each bit in the Request M-AP Coordination field indicates whether the AP wishes to coordinate the corresponding M-AP function with the counterpart AP. That is, an AP transmitting an M-AP coordination request frame may request coordination of a specific M-AP function with a counterpart AP by setting a specific bit included in the Request M-AP Coordination field to 1, or may not request coordination for the specific M-AP function by setting the specific bit to 0. In this case, each bit of the Request M-AP Coordination field can be set to 1 only when the bit of the corresponding M-AP Coordination Support Bitmap is set to 1. That is, an AP transmitting an M-AP coordination request frame must request only the M-AP coordination functions it supports from the counterpart AP.Additionally, the AP transmitting the M-AP coordination request frame may request coordination only for the M-AP coordination functions indicated as being supported by the counterpart AP. That is, the AP transmitting the M-AP coordination request frame must request coordination from the counterpart AP only for the M-AP coordination functions that are supported by both itself and the counterpart AP. The AP transmitting the Requested M-AP Coordination field can request coordination for multiple M-AP coordination functions at once by setting one or more bits included in the field to 1.

[0532] Figure 30 (c) illustrates the M-AP adjustment response frame format.

[0533] The M-AP coordination response frame is a response frame transmitted by an AP that has received an M-AP coordination request frame.

[0534] M-AP coordination response frames include a Dialog Token field, which serves to distinguish which request frame the response frame corresponds to. In other words, the AP responding with the frame sets the Dialog Token field of the response frame to the same value specified in the Dialog Token field of the target request frame for which it is responding.

[0535] The M-AP coordination response frame includes a Control field. The Control field indicates whether the frame contains any type of M-AP coordination Information fields (M-AP Info fields in Fig. 30(c)). That is, the configuration of the M-AP Info fields varies depending on the setting of the Control field.

[0536] The M-AP Info fields may include multiple M-AP Adjustment Information fields. Each M-AP Adjustment Information field indicates the information required to perform adjustment for each M-AP Adjustment function. For example, an M-AP Adjustment Information field related to M-AP Coordinated Puncturing may include information regarding the minimum Puncturing BW. The information required for the adjustment of each M-AP Adjustment function may differ from one another, and since the frame format provided in the present invention relates to the general M-AP Adjustment execution procedure and frame format rather than to the adjustment method of each M-AP Adjustment function, a detailed description of the configuration of the M-AP Adjustment Information fields is omitted.

[0537] Each M-AP coordination information field included in the M-AP Info fields of the M-AP coordination response frame relates to the M-AP coordination function requested by the corresponding M-AP coordination request frame. However, the AP responding to the M-AP coordination response frame may not include the M-AP coordination information field for the M-AP coordination function for which it does not intend to perform coordination in the M-AP Info fields. That is, the AP transmitting the M-AP coordination response frame may selectively accept only the coordination it intends to perform among the M-AP coordinations requested by the request frame it received. In this case, the selective acceptance method may include the M-AP coordination information field related to the M-AP coordination to be accepted in the M-AP Info fields of the response frame, and not include the M-AP coordination information field related to the M-AP coordination not to be accepted. Therefore, an AP that has transmitted an M-AP coordination request frame and received an M-AP coordination response frame can refuse to perform the M-AP coordination indicated by the response frame if the type of M-AP coordination function to be coordinated, identified through the received response frame, differs from the type it desires.

[0538] Alternatively, an AP that has transmitted an M-AP coordination request frame to a counterpart AP and received an M-AP coordination response frame can re-request an M-AP coordination different from the form dictated by the received response frame by transmitting an M-AP coordination response frame (responding with a frame of the same format) as a response to the response frame. In other words, APs performing M-AP coordination may not accept the M-AP coordination functions requested by the counterpart and may instead transmit an M-AP coordination response frame to the counterpart AP to dictate the M-AP coordination functions they desire.

[0539] Additionally, it is possible for an M-AP coordination information field regarding an M-AP coordination function not requested by the request frame to be included in the M-AP Info fields. If an M-AP coordination information field regarding an M-AP coordination function not requested by the request frame is additionally included in the M-AP Info fields, it can be understood that the M-AP coordination function corresponding to the additionally included M-AP coordination information field has been requested for coordination by the AP transmitting the response frame to the AP that transmitted the request frame. That is, the AP transmitting the M-AP coordination response frame can perform a coordination request for an M-AP coordination function that was not requested by the AP that transmitted the M-AP coordination request frame. The types of M-AP coordination functions that the AP transmitting the response frame can request from the AP that transmitted the request frame are limited to M-AP coordination functions supported by both APs.

[0540] Figure 30 (d) illustrates the M-AP adjustment Confirm frame format.

[0541] The M-AP Coordination Confirm Frame is a frame transmitted by an AP that has received an M-AP Coordination Response Frame when it intends to accept or reject the establishment of M-AP coordination indicated by the received frame. The M-AP Coordination Confirm Frame includes a Dialog Token field, which is set to the same value as the Dialog Token field of the M-AP Coordination Response Frame that is to be accepted or rejected via the Confirm Frame. The M-AP Coordination Confirm Frame includes a Status Code field, through which Accept or Reject can be indicated. Therefore, the AP that transmitted the M-AP Coordination Response Frame can verify whether the M-AP coordination it indicated has been accepted or rejected by the other AP based on the Status Code value of the received M-AP Coordination Confirm Frame. If acceptance of the M-AP coordination is indicated via the Status Code field, the corresponding M-AP Coordination Confirm Frame may include an M-AP Coordination Information field regarding the M-AP coordination subject to coordination. If the rejection of M-AP adjustment is indicated via the Status Code field, the corresponding M-AP adjustment Confirm frame may include information regarding the reason for rejection (e.g., Reason Code).

[0542] FIG. 31 shows an example of a multi-AP coordination process between APs according to an embodiment of the present invention.

[0543] Referring to FIG. 31, AP1 transmits M-AP beacon frames not only to its primary 20 MHz channel but also to other sub-channels included in its operating channel. By receiving the M-AP beacon frames transmitted by AP1 through its main channel, AP2 can obtain information about the operating channel, main channel information, and the M-AP coordination function supported by AP1, along with the fact that AP1 exists.

[0544] AP2 transmits an M-AP coordination request frame through sub-channels included in its operating channel for the purpose of performing M-AP coordination with AP1. By receiving the M-AP coordination request frame transmitted by AP2, AP1 obtains information regarding AP2's operating channel, main channel information, M-AP coordination functions supported by AP2, and the type of M-AP coordination requested by AP2.

[0545] AP1 transmits an M-AP coordination response frame in response to the M-AP coordination request frame requested by AP2, and AP2 completes the M-AP coordination procedure by transmitting an M-AP coordination Confirm frame after receiving the M-AP coordination response frame from AP1. Although not shown in FIG. 17, AP1 performs an Ack response to the M-AP coordination Confirm frame, and AP2 considers the M-AP coordination to be completed (established) when it receives the Ack response to the M-AP coordination Confirm frame it transmitted. That is, M-AP coordination is completed when the transmission of a successful M-AP coordination Confirm frame is confirmed between the two APs.

[0546] <Multi-AP 조정의 삭제(Delete, teardown, expired)>

[0547] As in the embodiment of the present invention described above, APs identify the M-AP adjustment functions supported by the counterpart AP and perform M-AP adjustment with the counterpart AP through a series of processes.

[0548] According to one embodiment of the present invention, M-AP coordination established between two APs can be modified or released through an agreed procedure. For example, an AP that has performed M-AP coordination may release the established M-AP coordination by transmitting a frame requesting the release of M-AP coordination to the other AP. In this case, the AP that receives the request for release of M-AP coordination from the other AP may always accept the request. This implies that M-AP coordination is a procedure performed / completed through consultation between two APs, and therefore, if one AP has no intention of fulfilling the consultation, M-AP coordination cannot continue to be applied by the other AP.

[0549] That is, in order to service low-latency traffic within a TXOP set by another AP, if a specific channel (e.g., the main channel) is made available for use during a specific interval (e.g., the R-TWT interval) through a coordination procedure with another AP, the use of the specific channel resulting from this coordination procedure can be released through a procedure agreed upon between the AP and the other AP. Specifically, the AP or the other AP can perform the coordination release procedure by transmitting a release request frame to the other AP requesting the release of use of the specific channel within a specific interval. At this time, the AP that receives the release request frame may accept the release request, and if the release request is accepted, the use of the channel is terminated.

[0550] In addition to the procedure for releasing the above coordination, if a specific frame that must be periodically transmitted from the AP requesting the use of a specific channel is not received within a set period, the other AP may determine that the AP has no intention of using the specific channel and release the use of that channel. In other words, if it is determined that the AP is not operating, such as when the other AP's power is turned off, the other AP can release the coordination for that specific channel because there is no longer a need to continue granting permission for the AP to use the channel. For example, an AP that is authorized to use a specific channel within a specific range through the coordination procedure must transmit a specific frame to other APs at regular intervals to inform them of the channel's usage; if such a specific frame is not transmitted within the set period, the other AP may consider the coordination procedure for the specific channel to have expired and release the coordination. In this case, the transmission period of the specific frame may be longer than the transmission period of a general beacon frame. Furthermore, the specific frame must be transmitted at least once within the set period, or within a set time after the previously transmitted specific frame. In this case, a specific frame may be a beacon frame (e.g., an M-AP (multi-AP) beacon frame, etc.).

[0551] Meanwhile, if adjustments regarding multiple M-AP adjustment functions have been performed between two APs, it is possible to release the M-AP adjustment for only some of the multiple M-AP adjustments. For example, if the first AP and the second AP have performed adjustments regarding the first M-AP adjustment function and the second M-AP adjustment function, the first AP may request the release of only the first M-AP adjustment function or only the second M-AP adjustment function.

[0552] Furthermore, a situation may arise when the power to one of the APs that performed the M-AP coordination is shut off or the operating mode of one of the APs changes, causing the previously established M-AP coordination to no longer function validly. In such a situation, an AP that believes the M-AP coordination is still valid bears an unnecessary burden of having to perform operations for M-AP coordination and manage information in the absence of the counterpart AP. To resolve this issue, each AP that performed the M-AP coordination may consider the M-AP coordination established with the counterpart AP to be no longer valid and terminated if a frame transmitted from the counterpart AP is not acknowledged within a certain period of time (e.g., M-AP Timeout). In other words, if frames transmitted from the counterpart AP are no longer received, the AP may perform actions considering the M-AP coordination established with the counterpart AP to have expired (expire, teardown, terminated).

[0553] Therefore, each AP may need to manage the M-AP coordination established with the counterpart AP so that it is not released by transmitting at least one PPDU within the aforementioned specified time in a manner that occupies the counterpart AP's main channel. At this time, the frame included in the PPDU may be an M-AP beacon frame. At this time, the frame included in the PPDU may also be an individually addressed frame with the counterpart AP as the destination device. To this end, the M-AP beacon frame may be transmitted through the Disabled subchannel of the BSS (a subchannel disabled by M-AP Coordinated Puncturing). That is, the M-AP beacon frame may be transmitted without being affected by M-AP Coordinated Puncturing. At this time, the specified time may be a time pre-specified in the 11bn standard or may be instructed by each AP to the counterpart AP. At this time, the specified time may be named the MAP Max Idle Period or named by another name.

[0554] In the 11bn standard, when the above-mentioned time is specified, each AP that has performed M-AP coordination and wishes to maintain the performed M-AP coordination may be restricted in its operation to transmit at least one frame to the other AP within the above-mentioned time. That is, the period during which each AP transmits an M-AP beacon frame (a frame transmitted for discovery between the APs described above) cannot be set to a period exceeding the above-mentioned time specified in the 11bn standard (e.g., Max M-AP Beacon transmission interval).

[0555] When each AP instructs the counterpart AP to the aforementioned fixed time, the value of the aforementioned fixed time instructed by each AP is respected by the counterpart AP. For example, when a second AP that has performed M-AP Coordination with a first AP wishes to maintain the M-AP Coordination performed with the first AP, it must transmit at least one frame to the first AP within the aforementioned fixed time instructed by the first AP. Accordingly, an AP that has performed coordination with multiple APs can maintain the coordination performed with each AP by setting the transmission period of the M-AP beacon frame based on the shortest time length among the multiple specified fixed times instructed by the multiple APs with which it has performed coordination. At this time, the frame transmitted by the AP to the counterpart AP may be transmitted in a non-HT (duplicated) PPDU format (or another 20 MHz repeating PPDU format) in the band occupying the Primary 20 MHz subchannel of the BSS operated by the counterpart AP.

[0556] The frame transmitted by an AP that intends to maintain an already established coordination may be a different type of frame than the M-AP beacon frame considered in the aforementioned embodiment. This is because the frame transmitted by the AP is sent for the purpose of indicating to other APs that it intends to continue maintaining the already established M-AP coordination, and is not intended to utilize the information indicated through the M-AP beacon frame. Furthermore, if two APs perform frame exchange while performing an operation using M-AP coordination (e.g., Coordinated TXOP sharing), the M-AP coordination between the two APs is not released even if M-AP beacon frames are not exchanged within the aforementioned time period. This is because, during the process of two APs performing an operation using M-AP coordination, it can be considered that the other AP has implicitly indicated to the other that it intends to maintain the M-AP coordination.

[0557] Therefore, the function intended by this invention is to enable an AP that has performed M-AP Coordination with a counterpart AP to verify whether the counterpart AP can still perform operations using M-AP Coordination, and to manage (maintain / terminate) the already established M-AP Coordination based on this; the specific frame format and framework used in this process should be considered as unimportant under the assumption that the same function can be achieved.

[0558] <Instruction to temporarily suspend participation in M-AP coordination operations>

[0559] If, during the operation for M-AP Coordination to share part or all of the TXOP from the Sharing AP, a situation may occur where the AP is temporarily unable to participate in the operation using M-AP Coordination.

[0560] Specifically, if the AP has an unavailable period during which it cannot transmit or receive frames, the AP cannot transmit or receive frames during that unavailable period (e.g., when the AP is in Power Save mode or has switched to an operation mode for Scanning or Measurement). Therefore, the AP cannot receive frames transmitted from the Sharing AP during that unavailable period (e.g., invitation frames, polling ICF, trigger frames, etc.), and even if the AP becomes available again later, it cannot receive data or transmit an acknowledgment message (Ack frame) because it has not already received frames for M-AP Coordination from the Sharing AP.

[0561] In other words, there may be situations where an AP that has performed M-AP coordination with a counterpart AP is temporarily unable to participate in operations using M-AP Coordination. For example, if an AP is operated in Power Save mode to reduce power consumption, or switches to an operation mode to perform Scanning or Measurement operations, it may temporarily become impossible to participate in M-AP Coordination operations initiated by the counterpart AP. An AP that is unaware that the counterpart AP has switched to a state where it cannot participate in M-AP coordination operations may perform recovery operations, such as retransmitting the frame, after transmitting a frame to initiate M-AP coordination operations to the counterpart AP (e.g., transmitting a TXS Trigger frame for TXOP sharing), and when the counterpart AP does not respond to the frame it transmitted, it may encounter a situation where no response frame is received from the counterpart AP despite having performed recovery operations.

[0562] Therefore, in order to prevent the other AP from destroying frames for M-AP Coordination operations in such unavailable sections, the AP must notify the other AP if an unavailable section is set. That is, if an unavailable section is set, the AP must transmit information about the unavailable section to the other AP so that the other AP can recognize it.

[0563] That is, APs performing Co-BF operations through TXOP sharing can exchange information about unavailable sections when unavailable sections are set, and perform Co-BF operations based on this. For example, if AP1 (Sharing AP or Coordinated AP) and AP2 (Shared AP or Coordinated AP) perform Co-BF operations through TXOP sharing and an unavailable section is set for AP1 or AP2, AP1 or AP2 can exchange information about the unavailable section before performing Co-BF operations in order not to transmit frames to the other AP in the unavailable section. Based on the acquired information about the unavailable section for the other AP, AP1 or AP2 can transmit frames for Co-BF operations to the other AP.

[0564] Information regarding unavailable periods may include the start time of the unavailable period, duration, and, if set periodically, the set stock price, etc.

[0565] Specifically, an AP intending to perform an operation using M-AP Coordination must decide whether to initiate M-AP Coordination with the counterpart AP based on whether the counterpart AP is in a state where it can participate in the operation using M-AP Coordination. To this end, an AP that is likely to transition to a state of temporary inability to participate in M-AP Coordination must assist the counterpart AP in not performing unnecessary operations (e.g., repeatedly transmitting the initiation frame for an operation using M-AP Coordination) by indicating to the counterpart AP that it may transition to a temporary inability state. At this time, the aforementioned state of temporary inability to participate in M-AP Coordination is the aforementioned<M-AP Coordination의 삭제> This is a situation distinct from a state requiring action execution, and an AP that has transitioned to a state of temporary inability to participate can re-enter an action using M-AP Coordination after the aforementioned state is released. Therefore, if an already established M-AP Coordination is released due to a state of temporary inability to participate, an inefficiency problem arises where the same coordination must be re-established from the beginning. To prevent this, the state of temporary inability to participate in M-AP Coordination operations is the aforementioned<M-AP Coordination의 삭제> It is distinguished from a state in which an operation is triggered. In this case, the state distinguished as the temporary inability to participate in the M-AP Coordination operation refers to a state of inability to participate maintained for a duration short enough not to satisfy the initiation conditions for the deletion operation of the aforementioned M-AP Coordination.However, exceptionally, even if the state of inability of a specific AP to participate in M-AP Coordination operations is long enough to satisfy the initiation conditions for the deletion operation of M-AP Coordination, it is possible for the deletion operation of M-AP Coordination established by the specific AP with another AP not to be initiated. As a specific example, if the reason an AP switches to a state of inability to participate in M-AP Coordination operations is that the Link operated by the AP is disabled, the M-AP Coordination previously established by the AP may not be deleted even if the state of inability to participate in operations is maintained for a time exceeding the MAP MAX Idle Period. In this case, the AP may enable the other AP to recognize that it will switch to a disabled state and the time it will be maintained in a disabled state by providing information (length information or information regarding the time of switching back to an enabled state) regarding the time when the Link operated by it switches to a disabled state and the time it is maintained.

[0566] An AP using an operation mode that transitions to a state of temporary inability to participate in M-AP Coordination can assist other APs in performing actions that take into account its inability to participate by notifying them that it possesses the characteristic of being capable of transitioning to the aforementioned inability to participate. For example, if a specific AP indicates that it may transition to a state of inability to participate in M-AP Coordination, other APs that have performed M-AP Coordination with said specific AP may choose not to retransmit the initiation frame when the frame for initiating M-AP Coordination with said specific AP fails to transmit (i.e., when a response frame is not received from said specific AP). In this case, the reason the other APs do not retransmit the initiation frame is to avoid attempting unnecessary retransmission by considering that said specific AP may have transitioned to a state of inability to participate in M-AP Coordination. At this time, each AP may indicate whether it may transition to a state of inability to participate in M-AP Coordination by using the M-AP beacon frame it transmits. That is, a specific field / bit of an M-AP beacon frame transmitted by an AP that can be switched to a state unable to participate in M-AP Coordination operations (not shown in the format illustrated in the embodiment of FIG. 16) can be set to a different value from the specific field / bit transmitted by an AP that is not switched to a state unable to participate in operations. Through this, a counterpart AP that receives an M-AP beacon frame transmitted by a specific AP can determine whether the specific AP has the characteristic of being switched to a state unable to participate in M-AP Coordination operations, and can determine whether to transmit an initiation frame based on this when performing an initiation of operations using M-AP Coordination with the specific AP.

[0567] Additionally, an AP scheduled to transition to a state of temporary inability to participate in M-AP Coordination operations may notify the other AP of information regarding the time at which it transitions to the aforementioned inability to participate state, the duration of the said inability to participate state, or the time at which the said inability to participate state is lifted (information on transition to inability to participate state), as well as information on the transition period. In this case, to instruct the other AP with its information on transition to the inability to participate state, the AP may instruct information related to the time of the said inability to participate state (time, duration, period, etc.) in the M-AP beacon frame it transmits. At this time, the information on the time of the said inability to participate state can only be instructed by the AP that indicated via the M-AP beacon frame that it may transition to a state of inability to participate in M-AP Coordination operations. That is, the field related to the information on the time of the said inability to participate state can be included and indicated in the corresponding M-AP beacon frame only when it is indicated via the M-AP beacon frame that it may transition to a state of inability to participate in M-AP Coordination operations.

[0568] An AP having the characteristic of periodically changing its ability to participate in M-AP Coordination operations (whether it is capable or unable to participate) can indicate time information related to its periodic state changes using the TWT (Target Wake Time) element used in conventional Wi-Fi. A specific method for an AP to indicate its ability to participate in M-AP Coordination operations (whether it is capable or unable to participate) may be to indicate the transition point to M-AP Coordination operations, the duration of the capable state, and the transition cycle to the capable state using the Broadcast TWT Parameter Set field of the TWT element. The Broadcast TWT Parameter Set field of the TWT element includes a Target Wake Time subfield, which can be utilized when an AP indicates the transition point to M-AP Coordination operations. In this case, the Target Wake Time subfield is set to the value of the TSF timer (i.e., TSF time) that the AP transmitting the subfield is expected to have when transitioning to the M-AP Coordination operation capable state. The Broadcast TWT Parameter Set field of the TWT element includes the Nominal Minimum TWT Wake Duration subfield, which can be used to indicate the duration for which the AP maintains a state available to participate in its M-AP Coordination operation. The Broadcast TWT Parameter Set field of the TWT element includes the TWT Wake Interval Mantissa subfield, which can be used to indicate the transition cycle for which the AP transitions to a state available to participate in its M-AP Coordination operation.At this time, the TWT element containing information regarding the transition of the ability to participate in M-AP Coordination operation is set such that the Negotiation Type subfield (included in the Control field of the TWT element) of the TWT element is set to 3 (A future Broadcast TWT SP start time), and the Broadcast TWT Recommendation subfield (included in the Request Type field of the TWT element) is set to a specific value (e.g., one of 4 to 7) indicating that it is information for M-AP Coordination.

[0569] Accordingly, an AP that receives a TWT element containing information regarding the possibility or impossibility of participating in M-AP Coordination operations from another AP can obtain information regarding at what point in time the other AP transitions to a state where it can participate in M-AP Coordination operations, the length of time maintained in that state, and the period of transition from an impossibility state to a state where it can participate. However, in this process, since the state transition point information indicated by the other AP is set based on the other AP's TSF timer, the TSF timer offset between the other AP and the other AP may also be considered when the other AP interprets the information. That is, an AP that receives the information on the possibility of participating in M-AP Coordination operations indicated by the other AP based on its TSF timer interprets that the other AP transitions to a state where it can participate in M-AP Coordination operations when its own TSF timer value reaches 'the indicated TSF timer value of the other AP + the TSF timer offset between itself and the other AP'.

[0570] Meanwhile, an AP scheduled to be temporarily switched to a state unable to participate in M-AP Coordination operations may indicate information regarding the time at which it is switched to an unavailable state and the duration of the unavailable state through a response frame it transmits (e.g., a Multi-STA BlockAck frame transmitted in response to a BSRP Trigger frame) when it receives an Initial Control frame transmitted by the other AP (e.g., a Buffer Status Report Poll (BSRP) Trigger frame). This may be an indication method utilized for non-periodic M-AP coordination supportable state transitions, rather than the periodic state transitions described above.

[0571] The Initial Control frame transmitted by an AP to a counterpart AP can be briefly explained as follows. The Initial Control frame is a frame defined to be transmitted by APs performing M-AP Coordination operations when they initiate M-AP Coordination operations. If an AP that has acquired a TXOP intends to perform an operation using M-AP Coordination with the acquired TXOP, it may transmit an Initial Control frame to a counterpart AP that intends to perform M-AP Coordination together. In this case, the Initial Control frame includes an indicator specifying the type of M-AP Coordination operation to be performed together (i.e., Coordinated TDMA, Coordinated Spatial Reuse, etc.). Therefore, an AP that receives an Initial Control frame from a counterpart AP can recognize the proposed type of M-AP Coordination operation and responds via a response frame regarding whether it intends to participate in the M-AP Coordination operation. An AP that has received an acknowledgment frame after transmitting an Initial Control frame to a counterpart AP performs M-AP Coordination with the counterpart AP only if it is confirmed that the counterpart AP intends to participate in M-AP Coordination, and does not perform subsequent operations for M-AP Coordination (such as information and frame exchanges for M-AP feature execution) if it is confirmed that the counterpart AP does not intend to participate in M-AP Coordination. In this case, the specific frame type of the Initial Control frame may be a BSRP (Buffer Status Report Poll) Trigger frame, and the specific frame type of the acknowledgment frame may be a Multi-STA BlockAck frame.

[0572] In other words, an AP scheduled to temporarily transition to a state unable to participate in M-AP Coordination operations may, upon receiving an Initial Control frame from a peer AP, indicate its intention to participate in M-AP Coordination operations along with information regarding the timing of its transition to the unavailable state through a response frame. In this case, the information regarding the timing of the transition to the unavailable state indicated through the response frame may be interpreted based on the time of transmission of the response frame. That is, the information regarding the transition time to the unavailable state of M-AP Coordination operations indicated through the response frame may be indicated or interpreted based on the time of transmission or reception of the response frame. For example, an AP indicating to a peer AP the time of its transition to the unavailable state of M-AP Coordination operations may indicate, through the response frame, the remaining time interval from the time it transmits the response frame until it transitions to the unavailable state of M-AP Coordination operations. In this case, the AP that receives the response frame can recognize that the AP that transmitted the response frame will transition to a state unable to participate in M-AP Coordination operations when a specified time interval has elapsed since the time the response frame was received. At this time, even if the AP that transmitted the response frame and the AP that received it perform instruction / interpretation based on the time of transmission and the time of reception, respectively, the propagation delay and MAC processing delay between the two APs are not significant; therefore, the time when the AP that transmitted the response frame transitions to a state unable to participate in M-AP Coordination operations can be indicated to the AP that received the response frame without significant error.

[0573] Alternatively, information regarding the transition point to a state of inability to participate in M-AP Coordination, indicated via the response frame, can be indicated using the TSF timer value expected to be possessed by the AP transmitting the response frame at the time of transition to a state of inability to participate in M-AP Coordination. In this case, the AP receiving the response frame (i.e., the AP that transmitted the Initial Control frame for M-AP Coordination) calculates the time point at which the counterpart AP (the AP that transmitted the response frame) transitions to a state of inability to participate in M-AP Coordination by considering the TSF timer value indicated via the response frame together with the TSF offset between itself and the counterpart AP.

[0574] Alternatively, information regarding the transition time to the state of inability to participate in M-AP Coordination, indicated via the response frame, may be based on the TSF timer of the AP receiving the response frame. In this case, the AP transmitting the response frame must set the TSF timer value it indicates via the response frame to the TSF timer value that the counterpart AP is expected to have when it transitions to the state of inability to participate in M-AP Coordination. In this case, the AP transmitting the response frame must determine the TSF timer value to be indicated via the response frame by considering its own TSF timer value expec...

Claims

1. As the first AP (access point), Transmitter / receiver; and Includes a processor, The above processor is, Transmit an invite frame for Co-BF (coordinated beamforming) operation to the second AP within a TXOP (transmission opportunity) shared by the first AP, The above invitation frame includes i) a specific field indicating whether, during the shared TXOP, the first AP exchanges an initial control frame (ICF) and an initial control response (ICR) frame between the first AP and the first non-AP STA before transmitting a first Co-BF to the first non-AP STA associated with the first AP, and ii) first station identifier (STA ID) information for identifying the first non-AP, and In response to the invitation frame above, receive a response frame from the second AP, When the second AP accepts the Co-BF operation, the response frame comprises i) length information related to the second ICF and second ICR frames exchanged between the second AP and the second non-AP before the second Co-BF transmission between the second AP and the second non-AP to the second non-AP associated with the second AP during the second TXOP, and ii) second STA ID information for identifying the second non-AP.

2. In Paragraph 1, The above second Co-BF transmission is performed based on whether the specific field indicates the exchange of the first ICF and first ICR frames.

3. In claim 1, the processor, Transmit a trigger frame for the first Co-BF transmission and the second Co-BF transmission to the first non-AP STA and the second non-AP STA, wherein The above trigger frame is an AP containing acknowledgment policy information related to the acknowledgment policy (ack policy) included in the second Co-BF transmission.

4. In Paragraph 3, The above response policy related to the above response policy information is an AP included in the MPDU (medium access control protocol data unit) transmitted through the above second Co-BF transmission.

5. In Paragraph 4, The above response policy is an AP that is either No Ack or Block Ack.

6. In Paragraph 3, If the response policy indicated by the above response policy information is not No Ack, the trigger frame further includes duration information related to the length of the response frame for the Co-BF transmission through the Co-BF operation.

7. In claim 1, the processor, An AP that exchanges unavailable information related to an unavailable period in which the frame exchange procedure for the Co-BF operation is impossible to perform with the above-mentioned second AP.

8. In Paragraph 7, The above unavailable information includes at least one of the start time information of the unavailable section, duration information, or period information, and The above Co-BF operation is an AP performed based on the above unavailable information.

9. In a method performed by an AP (access point), the above method is, A step of transmitting an invite frame for Co-BF (coordinated beamforming) operation to the second AP within a TXOP (transmission opportunity) shared by the first AP, The above invitation frame comprises i) a specific field indicating whether, during the second TXOP, the first AP exchanges an initial control frame (ICF) and an initial control response (ICR) frame between the first AP and the first non-AP STA prior to the first Co-BF transmission to the first non-AP STA associated with the first AP, and ii) first station identifier (STA ID) information for identifying the first non-AP; and The method includes the step of receiving a response frame from the second AP in response to the invitation frame, A method in which, when the second AP accepts the Co-BF operation, the response frame comprises i) length information related to the second ICF and second ICR frames exchanged between the second AP and the second non-AP before the second Co-BF transmission between the second AP and the second non-AP associated with the second AP during the second TXOP, and ii) second STA ID information for identifying the second non-AP.

10. In Paragraph 9, The above second Co-BF transmission is performed based on whether the specific field indicates the exchange of the first ICF and first ICR frames.

11. In claim 9, the above method is, The method includes the step of transmitting a trigger frame for the first Co-BF transmission and the second Co-BF transmission to the first non-AP STA and the second non-AP STA, wherein A method in which the above trigger frame includes response policy information related to the response policy (ack policy) included in the above second Co-BF transmission.

12. In Paragraph 11, A method in which the above response policy related to the above response policy information is included in an MPDU (medium access control protocol data unit) transmitted through the above second Co-BF transmission.

13. In Paragraph 12, The above response policy is a method that is either No Ack or Block Ack.

14. In Paragraph 11, A method in which, when the response policy indicated by the response policy information is not No Ack, the trigger frame further includes duration information related to the length of the response frame for the Co-BF transmission through the Co-BF operation.

15. In claim 9, the above method is, A method for exchanging unavailable information related to an unavailable period in which the frame exchange procedure for the above-mentioned second AP and the above-mentioned Co-BF operation cannot be performed.

16. In Paragraph 15, The above unavailable information includes at least one of the start time information of the unavailable section, duration information, or period information, and The above Co-BF operation is a method performed based on the above unavailable information.

Images