Method for managing multi-AP coordination for multi-AP operation and wireless communication terminal using same

Abstract

Disclosed are an operation method and device for a wireless communication terminal. Specifically, a first access point (AP) according to the present invention may receive a management frame related to a restricted target wake time service period (R-TWT SP) scheduled by a second AP for a coordinated restricted target wake time (Co-RTWT) operation, and may transmit a beacon frame.

Description

Method for managing multi-AP consultation for multi-AP operation 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; The system includes a processor, wherein the processor receives a management frame associated with an R-TWT SP (restricted target wake time service period) scheduled by a second AP for Co-RTWT (coordinated restricted target wake time) operation, the management frame includes a Multi-AP coordination (MAPC) element comprising a first parameter field for indicating parameters for the R-TWT SP, the first parameter field includes a first Broadcast Target Wake Time Persistence field indicating the duration of the R-TWT SP as the number of first TBTTs (Target beacon transmission Times) of the second AP, and transmits a beacon frame based on the management frame, wherein the beacon frame includes a second parameter field associated with the R-TWT SP scheduled by the second AP, the second parameter field indicating the duration of the R-TWT SP as the number of second TBTTs of the first AP It includes a second broadcast TWT persistence field that indicates, wherein the value of the second broadcast TWT persistence field is set to the number of the second TBTT based on the number of the first TBTT, and if the beacon interval, which is the period during which the beacon frame of the second AP is transmitted, is greater than the beacon interval of the first AP, and the number of the second TBTT based on the number of the first TBTT exceeds the maximum value of the number of TBTTs that can be indicated by the second broadcast TWT persistence field, the value of the second broadcast TWT persistence field is set to a specific value.

[0015] In addition, in the present invention, when the value of the second broadcast TWT persistence field is set to the specific value and the number of the second TBTTs falls below the maximum value, the first AP reduces the value of the broadcast TWT persistence field included in the beacon frame.

[0016] In addition, in the present invention, the maximum value is '254'.

[0017] Additionally, in the present invention, the processor receives a request frame for MAPC from the second AP, wherein the request frame includes a MAPC function field indicating at least one scheme supported by the second AP for the MAPC and a MAPC parameter field indicating one or more schemes for which the second AP intends to perform negotiation, and transmits a response frame for the request frame.

[0018] In addition, in the present invention, i) the at least one method and ii) the one or more methods are at least one of Coordinated Beamforming (Co-BF), Coordinated Spatial Reuse (Co-SR), Coordinated Time Division Multiple Access (Co-TDMA), and Coordinated Restricted Target Wake Time (Co-RTWT).

[0019] In addition, in the present invention, the MAPC parameter field includes one or more Agreement Establishment Enabled fields that correspond individually to each of the one or more methods, and the value of the field corresponding to the method to be negotiated among the one or more Agreement Establishment Enabled fields is set to '1'.

[0020] Additionally, in the present invention, the first AP and the second AP perform negotiation on all or part of the one or more methods based on the MAPC parameter field.

[0021] In addition, in the present invention, the MAPC element further includes instruction information indicating that the R-TWT SP is the R-TWT SP scheduled by the second AP.

[0022] In addition, in the present invention, the maximum number of the first TBTTs that can be indicated by the first broadcast TWT persistence field is '254'.

[0023] In addition, the present invention comprises the step of receiving a management frame associated with an R-TWT SP (restricted target wake time service period) scheduled by a second AP for a Co-RTWT (coordinated restricted target wake time) operation, wherein the management frame includes a Multi-AP coordination (MAPC) element including a first parameter field for indicating parameters for the R-TWT SP, and the first parameter field includes a first Broadcast Target Wake Time Persistence field indicating the duration of the R-TWT SP as the number of first TBTTs (Target beacon transmission Times) of the second AP; The method comprises the step of transmitting a beacon frame based on the above management frame, wherein the beacon frame includes a second parameter field related to the R-TWT SP scheduled by the second AP, and the second parameter field includes a second broadcast TWT duration field that indicates the duration of the R-TWT SP as the number of second TBTTs of the first AP, and the value of the second broadcast TWT duration field is set to the number of second TBTTs based on the number of first TBTTs, and if the beacon interval, which is the period during which the beacon frame of the second AP is transmitted, is greater than the beacon interval of the first AP, and the number of second TBTTs based on the number of first TBTTs exceeds the maximum value of the number of TBTTs that can be indicated by the second broadcast TWT duration field, the value of the second broadcast TWT duration field is set to a specific value.

[0024]

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

[0026] According to one embodiment of the present invention, the first AP can support the second AP in performing channel access for processing low-latency traffic by not occupying the primary channel of the second AP. At this time, non-AP STAs associated with the first AP can also perform an operation in which they do not occupy the primary channel of the second AP.

[0027] According to one embodiment of the present invention, the first AP may stop channel access to a band included in the operating bandwidth (BW) of the second AP before the R-TWT (Restricted Target Wake Time) SP (Service Period) of the second AP begins. At this time, non-AP STAs coupled with the first AP may also stop channel access to a band included in the operating bandwidth of the second AP before the R-TWT SP of the second AP begins.

[0028] According to one embodiment of the present invention, discovery and M-AP coordination between APs using different subchannels as main channels can be performed.

[0029] According to one embodiment of the present invention, each AP can apply coordinated puncturing (static puncturing) to the channel access channel of the BSS operated by the counterpart AP. According to one embodiment of the present invention, an AP wishing to participate in Co-BF transmission can provide information on the target device of the Co-BF transmission it wishes to perform to the AP that is the 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 an example of the format of frames used in a Multi-AP Coordination process according to one embodiment of the present invention.

[0044] FIG. 13 illustrates an example of a process in which M-AP coordination consultation between APs is performed according to an embodiment of the present invention.

[0045] FIG. 14 shows an example of the format of an M-AP coordination teardown frame according to one embodiment of the present invention.

[0046] FIG. 15 shows an example of a frame format used in a discovery procedure for MAPC according to an embodiment of the present invention.

[0047] FIG. 16 shows an example of a frame format used in a MAPC negotiation procedure according to an embodiment of the present invention.

[0048] FIG. 17 shows an example of a frame format used in a MAPC teardown procedure according to an embodiment of the present invention.

[0049] FIG. 18 shows an example of the format of a Request Parameter Set field for a MAPC that a Coordinating AP transmits to a Coordinated AP according to an embodiment of the present invention.

[0050] FIG. 19 shows an example of the format of a Broadcast TWT Parameter Set field used when indicating R-TWT SP information according to an embodiment of the present invention.

[0051] FIG. 20 is a flowchart illustrating an example of the operation of a controlled AP according to an embodiment of the present invention.

[0052]

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

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

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

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

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

[0058] 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).

[0059] 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).

[0060] 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 as a concept including a 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.

[0061] 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).

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

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

[0064] 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).

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

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

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

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

[0069] 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).

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

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

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

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

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

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

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

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

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

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

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

[0081] <Examples of Various PPDU Formats>

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

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

[0084] 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 legacy preambles.

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

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

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

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

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

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

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

[0092]

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

[0094]

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

[0096]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0112]

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

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

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

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

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

[0118]

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

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

[0121]

[0122] <EDCA와 TXOP>

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

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

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

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

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

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

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

[0130]

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

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

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

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

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

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

[0137]

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

[0139] 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).

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

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

[0142]

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

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

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

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

[0147]

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

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

[0150]

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

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

[0153]

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

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

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

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

[0158] 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 a 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.

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

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

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

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

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

[0164] <Multiple AP Cooperative Operations>

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

[0166] 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 for a single STA).

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

[0168] 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 transmitting and receiving traffic, 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 the 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.

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

[0170] The process of APs exchanging information regarding wireless resources they require from one another can be understood as a Multi-AP Coordination (MAPC) 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 APs performing transmission using these resources, can be understood as a Multi-AP Coordinated operation.

[0171] Multi-AP Cooperation Method for Low-Latency Traffic Services

[0172] Furthermore, multiple APs performing coordination operations can perform additional coordination to support services for low-latency traffic. For example, each AP can request other APs to perform operations that take into account the low-latency traffic they need to handle by exchanging information regarding the amount of low-latency traffic and Quality of Service (QoS) requirements they need to service, or by exchanging information regarding the R-TWT SPs they operate on their BSSs.

[0173] As a more specific example, the first AP may instruct the second AP performing the coordination operation to provide information regarding the start time, length of the SP, and period of the R-TWT SP that it is operating in its BSS. In this case, when the second AP acquires the TXOP, it may help the first AP service low-latency traffic during the R-TWT SP by terminating the TXOP before the first AP's R-TWT SP starts.

[0174] <AP들 간의 조정이 수행되는 방법 및 절차>

[0175] As explained above, APs intending to perform adjustments exchange information necessary for adjustment operations (e.g., main channel information, minimum puncturing BW information, R-TWT SP information), and then operate their TXOPs based on the information instructed by the other AP (acquire TXOPs and determine the subchannels to acquire TXOPs (apply puncturing, apply BW limits, etc.)).

[0176] 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 main channel, they can exchange information by utilizing the main channel or frequency resources including the main channel. However, between APs in BSSs that use different subchannels as their main channels, exchanging information using the main channel may be restricted. For example, if a first AP using a first subchannel as its main channel and a second AP using a second subchannel as its main channel wish to exchange information, the first and second APs must exchange information via their respective BSS's main channel and / or the other AP's BSS's main channel. In other words, an agreed-upon method for exchanging information between APs using different subchannels as their main channels is required.

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

[0178] 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 transmitting AP; therefore, a non-AP STA that received such elements from a specific AP could obtain information (main channel information and beacon transmission timing information) necessary to receive beacon frames from other APs. In other words, it was possible for a non-AP STA to discover other APs using the Neighbor Report elements and / or Reduced Neighbor Report elements received from a specific AP.

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

[0180] 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 in a "discovered" state 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.

[0181] 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 M-AP coordinate 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.

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

[0183] 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 referred to as M-AP coordination or MAPC) or that it has the capability to perform M-AP coordination. At this time, the frame may be a beacon frame or another type of management frame. For example, for MAPC, APs may transmit and receive management frames, such as MAPC discovery request frames and / or MAPC discovery response frames, to indicate the method for the MAPC they support and the method they wish to negotiate. Additionally, they may transmit management frames, such as beacon frames, to notify other terminals of parameters for the negotiated MAPC. For such MAPC operations, management frames, such as MAPC discovery request frames, MAPC discovery response frames, and / or beacon frames, may be used. At this time, the frame may be transmitted in a non-HT duplicated PPDU format or as a duplicated 20 MHz UHR PPDU. That is, an AP transmitting the frame over a 160 MHz BW can 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.

[0184] As such, the reason why the frame transmitted by the 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 main channel of the AP that transmitted the frame as the main channel can also verify (decode) the frame transmitted by the AP through a 20 MHz PPDU reception operation.

[0185] In this way, each AP can allow devices (AP and / or non-AP STA) of BSS using different subchannels as main 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 of BSS using different subchannels as main channels.

[0186] 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 main channel of the other AP when transmitting a PPDU that occupies the main channel of the other AP. At this time, the specific AP can transmit the PPDU that occupies the main channel of the other AP in the format of a non-HT duplicated PPDU or a format that duplicates a 20 MHz UHR PPDU.

[0187] 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. In the present invention, for the sake of brevity, the frame transmitted by an AP to be discovered by other APs may be referred to as an M-AP beacon frame (or, MAPC discovery request frame or MAPC discovery response frame).

[0188] 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 can perform M-AP coordination operations with the AP transmitting the frame based on the information indicated through the M-AP beacon frame.

[0189] At this time, a specific method for an AP that has received 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 main 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 main channel of the AP that sent the M-AP beacon frame is a subchannel that is not included in its own Operating channel, the AP that has 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 main channel of the first AP that received the M-AP beacon frame is included in the Operating channel of the second AP that sent the M-AP beacon frame is that the situation in which the M-AP beacon frame sent by the second AP is received by the first AP occurs only when the subchannel corresponding to the main channel of the first AP is included in the Operating channel of the second AP (of the BSS operated by the second AP).

[0190] In addition, even if an AP that receives an M-AP beacon frame confirms that the main 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.

[0191] Multi-AP Coordinated resource sharing

[0192] Coordinated TDMA (Co-TDMA): The Sharing AP, which is the TXOP holder, allocates a portion of the time interval included in the TXOP it acquired 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 transmitting trigger frames). At this time, the Sharing AP can inquire whether the Shared AP intends to perform operations using Co-TDMA by transmitting an Initial Control Frame to the Shared AP. At this time, the format of the Initial Control Frame (hereinafter ICF) is a Buffer Status Report Poll (BSRP) trigger frame, and the BSRP trigger frame includes a User Info field indicating the AP ID assigned by the Sharing AP to the Shared AP. Upon receiving the ICF from the Sharing AP, the Shared AP responds to the Sharing AP with an Initial Control Response Frame (hereinafter ICR) and indicates whether it intends to perform operations using Co-TDMA. At this time, the format of the Initial Control Response frame may be a Multi-STA BlockAck frame. When the Sharing AP responds with an ICR indicating that the Shared AP intends to perform an operation using Co-TDMA, it may share some of the time resources corresponding to its TXOP with the Shared AP by transmitting a MU-RTS TXS (TXOP Sharing) trigger frame within the TXOP it operates.

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

[0194] At this time, the process in which the AP that acquired the TXOP inquires with the other AP whether it intends to perform an operation using coordination by transmitting an ICF, and the AP that received the ICF indicates its intention to participate through an ICR, can be utilized as a common initial control frame exchange process that can be performed not only between APs using Co-TDMA but also between APs using Co-BF and Co-SR.

[0195] <Multiple AP R-TWT Protection (R-TWT Coordination, Coordinated R-TWT, Co-RTWT (Coordinated R-TWT)>

[0196] APs that have performed coordination exchange R-TWT (restricted-TWT) information operated in their respective BSSs. Each AP restricts the TXOP length or restricts the subchannels for acquiring TXOPs, 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. At this time, the other AP protecting the R-TWT SP of the other AP can enable non-AP STAs belonging to its BSS to recognize the start time and duration of the R-TWT SP operated by the other AP by including a TWT element corresponding to the other AP's R-TWT SP in the beacon frame it transmits. At this time, the TWT element (Broadcast TWT) corresponding to the R-TWT SP of the other AP transmitted by the other AP can be configured according to the following 1 to 13.

[0197] 1. The Restricted TWT Schedule Info subfield is set to 3.

[0198] 2. The Broadcast TWT ID subfield is set to 31.

[0199] 3. The TWT Request field is set to 0.

[0200] 4. The TWT Setup Command field is set to 4.

[0201] 5. The Trigger field and Flow Type field are Reserved.

[0202] 6. The Broadcast TWT Recommendation field is set to 4.

[0203] 7. The TWT Wake Interval Exponent subfield is set to be equal to the value of the TWT Wake Interval Exponent among the parameters of the R-TWT SP for which protection was requested from the opposing AP.

[0204] 8. Aligned fields are Reserved if they exist.

[0205] 9. The Target Wake Time field is set to its own TSF value (TSF[10:25]) corresponding to the start time of the R-TWT SP for which protection was requested from the opposing AP.

[0206] 10. The Nominal Minimum TWT Wake Duration field is set to a value corresponding to the Duration of the R-TWT SP for which protection was requested from the opposing AP.

[0207] 11. The TWT Wake Interval Mantissa field is set to match the field value of the same name among the parameters of the R-TWT SP for which protection is requested from the opposing AP.

[0208] 12. The Restricted TWT Traffic Info Present subfield is set to 0.

[0209] 13. The Broadcast TWT Persistence subfield is set to the number of beacon frames (i.e., the number of TBTTs) expected to be transmitted during the persistence time of the R-TWT SP for which protection has been requested by the peer AP (for example, an AP whose persistence time for the R-TWT SP for which protection has been requested by the peer AP is 1000 ms and whose Beacon Interval is 100 ms transmits with the value of the Broadcast TWT Persistence subfield set to 10. In this case, the persistence information of the R-TWT SP for which protection has been requested by the peer AP is calculated based on the peer AP's Beacon Interval and the value of the Broadcast TWT Persistence subfield set by the peer AP for the said R-TWT SP). For example, if the Beacon Interval (BI) for transmitting a beacon frame of an R-TWT SP scheduled by the coordinating AP is 1000 ms and the value of the Broadcast TWT persistence subfield of the frame transmitted by the coordinating AP to the coordinating AP is 5 (i.e., the number of remaining TBTTs in the interval where the R-TWT SP appears (or persists) is 5), the coordinating AP may set the value of the Broadcast TWT persistence subfield included in the management frame (e.g., a beacon frame) to 50 based on its own BI. That is, the coordinating AP may set the value of the Broadcast TWT persistence subfield to a value set based on its own BI for the number of remaining TBTTs in the interval where the R-TWT SP scheduled by the coordinating AP appears (or persists). At this time, if the BI of the adjusting AP is greater than the BI of the adjusted AP, the number of remaining TBTTs of the adjusting AP may exceed the number of broadcast TWT persistence subfields when converting based on its own BI, and in this case, a problem arises with setting the value of the broadcast TWT persistence subfield set by the adjusted AP.

[0210] In this case, if the BI of the R-TWT SP (Co-RTWT) scheduled by the coordinating AP is greater than the BI of the mediated AP (the BI of the Co-RTWT), and the number of TBTTs of the mediated AP based on the number of TBTTs in the interval where the R-TWT SP scheduled by the coordinating AP exists is greater than the maximum value that can be indicated by the broadcast TWT persistence subfield, the mediated AP may set the value of the broadcast TWT persistence subfield to a specific value and transmit it. Subsequently, if the number of TBTTs of the mediated AP based on the number of TBTTs in the interval where the R-TWT SP scheduled by the coordinating AP exists becomes smaller than the maximum value that can be indicated by the broadcast TWT persistence subfield, the mediated AP may start decreasing the value of the broadcast TWT persistence subfield.

[0211] In other words, the BI of the coordinating AP can be set longer than the beacon period of the coordinated AP. In this case, due to the limitations of the range of values ​​that the broadcast TWT persistence field can represent (e.g., 0 to 254), the coordinated AP may be unable to accurately indicate the number of its remaining TBTTs through said field until the R-TWT schedule ends. To overcome this limitation, if the number of remaining TBTTs of the coordinated AP exceeds 254 until the end of the R-TWT schedule, the coordinated AP may set the value of the broadcast TWT persistence field to a specific indicator value of 255 and transmit it. The value of 255 can be used to indicate that the number of remaining TBTTs exceeds the representation range of said field. Subsequently, the controlled AP may transmit by decreasing the value of the broadcast TWT duration field according to the calculated number, starting from the point when the time remaining until the end of the above R-TWT schedule through continuous monitoring falls within 254 times based on the beacon cycle of the controlled AP (i.e., the point when the number of remaining TBTTs is calculated to be 254 or less).

[0212] For reference, the broadcast TWT persistence subfield is a subfield that indicates information regarding the duration for which the TWT (R-TWT) SP corresponding to that subfield is maintained, and the unit is TBTT. That is, if the value of the broadcast TWT persistence subfield corresponding to a specific R-TWT SP is 10, it indicates that the specific R-TWT SP is maintained until 10 TBTTs (i.e., 10 Beacon Intervals) have elapsed. The broadcast TWT persistence subfield has an 8-bit size, and the largest value that can be indicated through that subfield is 255, which is used to indicate that the corresponding TWT (R-TWT) SP is maintained until an explicit instruction is given; thus, an R-TWT SP with the broadcast TWT persistence subfield set to 255 is maintained until an explicit instruction is given.

[0213] The Broadcast TWT persistence subfield for an R-TWT SP for which protection is requested via Co-RTWT cannot be set to 255. This is a restriction intended to prevent opposing APs from continuing unnecessary protection of the R-TWT SP if the AP that requested protection of the R-TWT SP from opposing APs transitions to an inoperable state without an explicit termination instruction for the protected R-TWT SP. Therefore, an AP that wishes to request protection of its own R-TWT SP via Co-RTWT must not set the Broadcast TWT persistence subfield corresponding to the R-TWT SP to 255. Additionally, an AP that includes a TWT element corresponding to the R-TWT SP of the other AP in a beacon frame it transmits for the purpose of protecting the R-TWT SP of the other AP may decide to set the broadcast TWT persistence subfield of the said TWT element to a value other than 255, or to no longer include the TWT element corresponding to the R-TWT SP in its beacon frame when it is determined that the said R-TWT SP is no longer valid. At this time, the method for determining the validity of the R-TWT SP operated by the other AP may be that no explicit protection request (repeated protection request for the same R-TWT SP) is made from the other AP within a predetermined time period.

[0214] Multi-AP joint sounding / transmission (transmission using beamforming, i.e., can be called Co-BF (Coordinated Beamforming))

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

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

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

[0218] Multi-AP Spatial Reuse (can be called Coordinated Spatial Reuse (Co-SR))

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

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

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

[0222] 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 counterpart that transmitted the received M-AP beacon frame may be to transmit its own M-AP beacon frame to the band occupying the band including the counterpart AP's main channel. In this case, the action performed by the AP to perform M-AP coordination with the counterpart that transmitted 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 counterpart AP's main channel. In this case, the M-AP coordination request frame is a frame containing information indicating the M-AP coordination action supported by the AP and / or information indicating the M-AP coordination action that the AP intends to perform with the counterpart AP.In addition, 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.

[0223] An AP transmitting an M-AP coordination request frame can make the AP receiving the M-AP coordination request frame aware that an M-AP coordination request has been made to it by transmitting a PPDU containing an indicator related to the AP to which it intends to perform coordination. At this time, the AP transmitting the M-AP coordination request frame can make the other AP aware 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 make the other AP aware 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.)

[0224] The process of discovering each other between APs having different main 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.

[0225] FIG. 12 shows an example of the format of frames used in a Multi-AP Coordination process according to one embodiment of the present invention.

[0226] The names of the frames illustrated in FIG. 12 are given to indicate the functional aspects of each frame provided by the present invention, and the specific names of the frames can be changed at any time. In addition, the format of each frame illustrated in FIG. 12 consists of fields intended to explain the function of each frame provided by the invention, and it is possible to change the name of a field illustrated as being included in each frame to a different name, remove some of the multiple fields included in the frame, or include a field that is not included in the frame. Therefore, the names and formats of the frames illustrated in FIG. 12 should be understood as being for illustrative purposes, and the functional aspects of each frame described through the discovery / M-AP coordination procedure between APs provided in the embodiment of FIG. 13 should be understood as the content of the invention.

[0227] Figure 12 (a) illustrates the M-AP beacon frame format.

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

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

[0230] 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 BW (bandwidth)) of the BSS operated by the AP transmitting the M-AP beacon frame.

[0231] 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 subchannels included in the operating channel (the main channel).

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

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

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

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

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

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

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

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

[0240] 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 Requested M-AP Coordination field can be composed of a bitmap, and each bit in the Requested 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 Requested 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.

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

[0242] The M-AP coordination response frame is a response frame transmitted by the AP that receives the M-AP coordination request frame.

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

[0244] 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. 12(c)). That is, the configuration of the M-AP Info fields varies depending on the setting of the Control field.

[0245] 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 specifying the adjustment method of each M-AP Adjustment function, a detailed description of the configuration of the M-AP Adjustment Information fields is omitted.

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

[0247] Alternatively, an AP that has received an M-AP coordination response frame after transmitting an M-AP coordination request frame to a counterpart AP can request a different form of M-AP coordination from the M-AP coordination indicated 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 M-AP coordination response frame. In other words, APs performing M-AP coordination may not accept the M-AP coordination functions requested by the counterpart AP, but instead transmit an M-AP coordination response frame to the counterpart AP to indicate the M-AP coordination function they desire.

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

[0249] Figure 12 (d) illustrates the M-AP confirmation frame format.

[0250] An M-AP Coordination Confirmation 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 Confirmation 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 frame. The M-AP Coordination Confirmation 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 responded M-AP Coordination Confirmation Frame. If acceptance of the M-AP Coordination is indicated via the Status Code field, the corresponding M-AP Coordination Confirmation Frame may include an M-AP Coordination Information field regarding the M-AP Coordination being coordinated. If the rejection of M-AP adjustment is indicated via the Status Code field, the corresponding M-AP adjustment confirmation frame may include information regarding the reason for rejection (e.g., Reason Code).

[0251] FIG. 13 illustrates an example of a process in which M-AP coordination consultation between APs is performed according to an embodiment of the present invention.

[0252] Referring to FIG. 13, AP1 transmits M-AP beacon frames not only to its primary 20 MHz channel but also to other subchannels 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.

[0253] AP2 transmits an M-AP coordination request frame through subchannels included in its operational 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 operational channel, main channel information, M-AP coordination functions supported by AP2, and the type of M-AP coordination requested by AP2.

[0254] 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 confirmation frame after receiving the M-AP coordination response frame from AP1. Although not shown in FIG. 13, AP1 performs an Ack response to the M-AP coordination confirmation frame, and AP2 considers the M-AP coordination to be completed (established) when it receives the Ack response to the M-AP coordination confirmation frame it transmitted. That is, M-AP coordination is completed when the transmission of a successful M-AP coordination confirmation frame is confirmed between the two APs.

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

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

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

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

[0259] Furthermore, situations may arise where the power to one of the APs that performed 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 cases, 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 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).

[0260] Accordingly, 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.

[0261] 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).

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

[0263] 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 information indicated through the M-AP beacon frame. Furthermore, if two APs exchange frames while performing an operation using M-AP coordination (e.g., Coordinated TXOP sharing), the M-AP coordination is not released between the two APs 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 an intention to maintain the M-AP coordination, which is implicitly indicated to each other.

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

[0265] <Instruction to temporarily disable participation in M-AP coordination operations>

[0266] 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 the M-AP coordination operation initiated by the counterpart AP. An AP that is unaware that the counterpart AP has switched to a state where it cannot participate in the M-AP coordination operation may perform recovery operations, such as retransmitting the frame, after transmitting a frame to initiate the M-AP coordination operation 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 the recovery operations.

[0267] Therefore, an AP intending to perform an operation using M-AP coordination must decide whether to initiate an M-AP coordination operation with the opposing AP based on whether the opposing 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 the M-AP coordination operation must assist the opposing AP in not performing unnecessary operations (e.g., repeatedly transmitting the initiation frame for the operation using M-AP coordination) by indicating to the opposing AP that it may transition to a state of temporary inability. At this time, the aforementioned state of temporary inability to participate in the M-AP coordination operation is the aforementioned<M-AP 조정의 삭제> This is a situation distinct from a state requiring operation execution, and an AP that has transitioned to a state of temporary inability to participate can resume participation in operations using M-AP adjustment after the aforementioned state is released. Therefore, if an already established M-AP adjustment is released due to the state of temporary inability to participate, an inefficiency problem arises where the same adjustment must be established again from the beginning. To prevent this, the state of temporary inability to participate in M-AP adjustment operations is as described above<M-AP 조정의 삭제> It is distinguished from a state in which an operation is triggered. In this case, the state classified as the temporary inability to participate in the M-AP adjustment operation refers to a state of inability to participate maintained for a period short enough not to satisfy the initiation conditions for the deletion operation of the M-AP adjustment described above. However, exceptionally, even if the state of inability of a specific AP to participate in the M-AP adjustment operation is long enough to satisfy the initiation conditions for the deletion operation of the M-AP adjustment, it is possible for the M-AP adjustment deletion operation established by the specific AP with another AP not to be initiated.As a specific example, if the reason an AP is switched to a state where it cannot participate in M-AP coordination operations is that the Link in which the AP operates is disabled, the M-AP coordination previously established by the AP may not be deleted even if the state of being unable to participate in operations is maintained for a time exceeding the MAP MAX Idle Period. In this case, the AP may instruct the other AP to recognize that it will be switched 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 it is switched back to an enabled state) regarding the time when the Link in which it operates is switched to a disabled state and the time it is maintained in a disabled state.

[0268] An AP using an operation mode that transitions to a state of temporary inability to participate in M-AP coordination operations 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 operations, 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 operations 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 operations. At this time, each AP may indicate whether it may transition to a state of inability to participate in M-AP coordination operations 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 of being unable to participate in M-AP coordination operations (not shown in the format illustrated in the embodiment of FIG. 12) can be set to a different value from the specific field / bit transmitted by an AP that is not switched to a state of being unable to participate in said operation. 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 of being 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 operation using M-AP coordination with the specific AP.

[0269] 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 for which the inability to participate state is maintained, or the time at which the inability to participate state is released (information on transition to the 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 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 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 inability to participate state can be included and instructed 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.

[0270] An AP that has received the aforementioned time information regarding the inability to participate from a counterpart AP may determine whether to transmit the initiation frame for an operation using M-AP coordination to the counterpart AP based on whether the counterpart AP is in a state of inability to participate in the M-AP coordination operation. As a specific example, a second AP that determines, based on information indicated by the first AP, that the first AP is in a state of inability to participate in the M-AP coordination operation, must not transmit a frame for initiating the operation using M-AP coordination to the first AP. That is, the second AP may transmit the initiation frame for an operation using M-AP coordination to the first AP only when it is determined that the first AP is not in a state of inability to participate in the M-AP coordination operation.

[0271] However, the state of being unable to participate in M-AP coordination operations experienced by an AP may occur in a manner that the AP cannot predict in advance. In this case, the AP only indicates via the M-AP beacon frame that it may transition to a state of being unable to participate in M-AP coordination operations, and cannot indicate specific information regarding the time of the inability to participate. Therefore, each AP may encounter a situation where it only confirms that the other AP may transition to a state of being unable to participate in M-AP coordination operations, but fails to obtain information regarding the time of the other AP's inability to participate. In this case, after the AP transmits a start frame for an operation using M-AP coordination to the other AP, if a response frame to said start frame is not received, the AP must perform an action assuming that the other AP is in a state of being unable to participate. That is, the AP may not retransmit the start frame for an operation using M-AP coordination to the other AP, considering that the other AP is in a state of being unable to participate. Additionally, the AP may decide not to transmit the start frame for an operation using M-AP coordination to the other AP while the other AP is considered to be in a state of being unable to participate. At this time, if the AP receives a frame transmitted from a counterpart AP that it has determined to be in a state of being unable to participate, it may consider that the counterpart AP's state of being unable to participate in M-AP coordination operations has been released.

[0272] FIG. 14 shows an example of the format of an M-AP coordination teardown frame according to one embodiment of the present invention.

[0273] The AP can terminate the M-AP coordination performed with the other AP by sending an M-AP coordination tear-down frame to the other AP.

[0274] M-AP coordination teardown frames may include an AP ID field. The AP ID field of an individually addressed M-AP coordination teardown frame indicates the ID (BSS Color or the AP's MAC address) of the recipient AP. The AP ID field of a broadcast M-AP Coordinated teardown frame indicates the ID (BSS Color or the AP's MAC address) of the AP transmitting the M-AP coordination teardown frame. Broadcast M-AP coordination teardown frames are used when the AP transmitting the frame intends to tear down coordination with all APs with which it has performed M-AP coordination. That is, an AP receiving a broadcast M-AP coordination teardown frame can release the M-AP coordination it performed with the AP indicated by the AP ID field. In this case, it refers to a frame where the RA field (Receiver Address, Address 1 field) of the individually addressed M-AP coordination teardown frame is indicated by the MAC address of a specific AP. At this time, the above Broadcast address M-AP adjustment teardown frame refers to a frame in which the RA field of the frame is set to a specific value (e.g., each bit is 1) and instructed to be received by all STAs.

[0275]

[0242] An M-AP coordination teardown frame may include a Teardown All field (1-bit) indicating whether to release all established M-AP coordinations. An AP transmitting an M-AP coordination teardown frame may request the deletion of all M-AP coordination functions that have been coordinated with the counterpart AP by setting the Teardown All field to 1. When the Teardown All field is set to 0, the M-AP coordination functions to be released are specified through the M-AP coordination Bitmap field. However, if the AP transmitting the M-AP coordination teardown frame has only one M-AP coordination function that has been coordinated with the counterpart AP, the Teardown All field must always be set to 1.

[0276] An M-AP coordination teardown frame has a configuration including an M-AP coordination bitmap field when the Teardown All field is set to 0. Each bit of the M-AP coordination bitmap field corresponds to an M-AP coordination function. An AP transmitting an M-AP coordination teardown frame indicates which M-AP coordination function it wishes to release by setting to 1 the bit of the M-AP coordination bitmap field corresponding to the M-AP coordination function for which it requests release among the M-AP coordination functions for which coordination has been established with the counterpart AP.

[0277] Meanwhile, in the case of APs conducting Co-RTWT consultations, multiple Co-RTWT consultations for multiple R-TWT SPs can be performed separately, and accordingly, Co-RTWT consultations for each of the multiple R-TWT SPs can be maintained, managed, or released separately.

[0278] As mentioned above, an R-TWT SP is a type of Broadcast TWT and is scheduled by an AP operating a BSS to be utilized as a service interval for low-latency transmission. Since a Broadcast TWT SP is scheduled by an AP, the AP that schedules the Broadcast TWT is called a TWT scheduling AP, and the member STA participating in the TWT is called a TWT scheduled STA. An AP can schedule multiple R-TWT SPs, and each R-TWT SP can be distinguished based on a Broadcast TWT ID value, just like a Broadcast TWT. An AP that schedules multiple R-TWT SPs can perform low-latency traffic communication with a specific non-AP STA through a specific R-TWT SP, and low-latency traffic communication with other non-AP STAs through other R-TWT SPs.

[0279] Each of the multiple Broadcast TWTs operating in the BSS has a different Broadcast TWT ID, and therefore, each Broadcast TWT can be distinguished using its Broadcast TWT ID value. More precisely, each Broadcast TWT<Broadcast TWT ID, TWT Scheduling AP의 MAC address> Although they are distinguished by tuples, the TWT Scheduling APs of Broadcast TWTs operating in the BSS are all the same as Associated APs, so Broadcast TWTs operating in the BSS are distinguished using Broadcast TWT IDs. In this case, among the values ​​of the 5-bit Broadcast TWT ID subfield, 31 can be used commonly for multiple Broadcast TWTs, and specifically, it is used as a Broadcast TWT ID for Broadcast TWTs scheduled by Co-hosted / Co-located APs, rather than Broadcast TWTs scheduled by the AP transmitting the Broadcast TWT ID subfield.

[0280] Accordingly, an AP may conduct Co-RTWT related consultations with a counterpart AP for the purpose of requesting protection for multiple R-TWT SPs operating in its BSS, and to this end, may provide information regarding the multiple R-TWT SPs (e.g., start time and maintenance time, etc.) to the counterpart AP. At this time, the AP requesting Co-RTWT consultation regarding the multiple R-TWT SPs may provide Broadcast TWT ID information assigned to each R-TWT SP, along with information regarding each of the multiple R-TWT SPs. In this case, the counterpart AP that receives the request for Co-RTWT consultation regarding the multiple R-TWT SPs can distinguish and identify / designate each R-TWT SP for which protection has been requested using the Broadcast TWT ID provided together. At this time, an AP that has received a request for Co-RTWT consultation from multiple R-TWT SPs may accept the Co-RTWT consultation for some or all of the multiple R-TWT SPs, or reject the Co-RTWT consultation for all of the multiple R-TWT SPs.

[0281] In addition, two APs that have already completed Co-RTWT consultation for a specific R-TWT SP may proceed with additional consultation for another R-TWT SP. That is, the number of Co-RTWT consultations that can be performed between the two APs is limited to the sum of the number of R-TWT SPs operated by each AP in their respective BSSs. In this case, when distinguishing between R-TWT SPs for which Co-RTWT consultation has already been completed and R-TWT SPs for which Co-RTWT consultation is newly requested, the two APs can manage each R-TWT SP by utilizing the Broadcast TWT ID assigned to each R-TWT SP.

[0282] For example, a second AP that has completed Co-RTWT negotiations with the first AP's first R-TWT SP (Broadcast TWT ID = 1) and second R-TWT SP (Broadcast TWT ID = 2) can request the release of Co-RTWT negotiations only for the first R-TWT SP using a Teardown frame transmitted to the first AP. That is, through the Teardown frame transmitted by the second AP, it is possible to request the release of only a specific R-TWT SP among the R-TWT SPs protected through Co-RTWT, without requesting the release of the entire Co-RTWT negotiation performed with the first AP. In this case, the second AP can identify the R-TWT SP for which the release of protection is requested by specifying the Broadcast TWT ID information for the R-TWT SP for which the release of protection is requested among the R-TWT SPs protected through Co-RTWT negotiations. That is, in the above example, if the second AP requests the release of protection for the first R-TWT SP, the second AP may instruct the first AP to terminate Co-RTWT protection for the first R-TWT SP by specifying the Broadcast TWT ID as 1 along with a request to release Co-RTWT consultation through a Teardown frame transmitted by itself. Additionally, it is possible for the first AP to request the second AP to release Co-RTWT consultation for its own R-TWT SP, the first R-TWT SP, and in this case as well, the first AP may specify that it is requesting the release of Co-RTWT consultation for the first R-TWT SP among the Co-RTWT consultations performed for the first R-TWT SP and the second R-TWT SP by transmitting a Teardown frame indicating the Broadcast TWT ID for the first R-TWT SP.At this time, the Broadcast TWT ID is a name used for illustrative purposes, and it is also possible to use an ID with a different name (e.g., Co-RTWT ID, Multi-AP Coordination ID (MAPC ID), Multi-AP Coordination Info. (MAPC Info.), etc.) to distinguish each R-TWT SP to which the Co-RTWT consultation performed between the two APs applies. Additionally, each AP may indicate to the other AP that the ID of the R-TWT SP to be indicated is a value other than the Broadcast TWT ID (ID used within the BSS) that it has assigned to the R-TWT SP. That is, even if the Broadcast TWT ID assigned to a specific R-TWT SP (the Broadcast TWT ID included in the TWT element for the said specific R-TWT SP) is x, the AP requesting the other AP to conduct Co-RTWT consultation for the said specific R-TWT SP may indicate that the ID of the said specific R-TWT SP is y. This is because the Broadcast TWT ID used to distinguish multiple Broadcast TWT IDs operating within the BSS does not need to be identical to the ID used to distinguish each of the multiple R-TWT SPs agreed upon between the APs.

[0283] Meanwhile, the two APs performing Co-RTWT consultations can each request protection for their respective R-TWT SPs from each other. That is, the first AP and the second AP performing Co-RTWT consultations can each request protection from the other AP for the R-TWT SPs they are operating (scheduling). At this time, the Broadcast TWT IDs assigned to the different R-TWT SPs operated by the two APs may be the same value, which may be a result of the two APs individually setting the Broadcast TWT IDs to be used in their respective BSSs. Therefore, some of the Co-RTWT consultations performed between the two APs may be for two different R-TWT SPs with the same Broadcast TWT ID. That is, among the two R-TWT SPs with the same Broadcast TWT ID for which Co-RTWT consultations were performed, it is possible for one to be the R-TWT SP of the first AP and the other to be the R-TWT SP of the second AP. In this case, the two APs conducting the Co-RTWT consultation cannot distinguish between the R-TWT SP they scheduled (i.e., the R-TWT SP of the BSS they operate) and the R-TWT SP scheduled by the other AP (i.e., the R-TWT SP of the BSS operated by the other AP) using the Broadcast TWT ID (because the Broadcast TWT IDs of the two R-TWT SPs are identical), and must consider the information of the AP that scheduled each R-TWT SP together.Accordingly, an AP transmitting a teardown frame to request the release of Co-RTWT agreement for an R-TWT SP that it has scheduled can indicate to the other AP that the target R-TWT SP for which the release of Co-RTWT is requested is one of the R-TWT SPs operated by itself by including additional information indicating that it is for its own R-TWT SP, along with Broadcast TWT ID information for the R-TWT SP, in the teardown frame. As an example of the additional information, a 1-bit indication may be considered. In this case, the AP may indicate that the R-TWT SP for which the teardown is requested is an R-TWT SP operated by itself (Transmitter) by setting the 1-bit to a specific value (e.g., 0), and indicate that the R-TWT SP for which the teardown is requested is an R-TWT SP operated by the other AP (Receiver) by setting the 1-bit to another value (e.g., 1).[SK2.1]

[0284] In summary, APs that have conducted Co-RTWT consultations may Teardown the Co-RTWT consultations with the R-TWT SPs using one of the following methods 1 to 5.

[0285] 1. Release of Co-RTWT consultations for all R-TWT SPs for which Co-RTWT consultations were conducted between the two APs

[0286] - In this case, the AP requesting the release of Co-RTWT consultation for all R-TWT SPs requests a teardown of the Co-RTWT Scheme.

[0287] - When a teardown is requested for the Co-RTWT Scheme, separate instructions regarding the Broadcast TWT ID and R-TWT SP operator are not executed.

[0288] 2. Termination of Co-RTWT consultation for specific R-TWT SPs operated by oneself

[0289] - An AP requesting the release of Co-RTWT negotiation for a specific R-TWT SP indicates the Broadcast TWT ID of the said specific R-TWT SP through a Teardown frame transmitted to the other AP.

[0290] In addition, the Teardown frame contains information indicating that the R-TWT SP for which release is requested is the Transmitter's R-TWT SP.

[0291] - In this case, Co-RTWT agreements established between the two APs for other R-TWT SPs (excluding the specific R-TWT SP mentioned above) are not affected.

[0292] 3. Release of Co-RTWT consultation for all R-TWT SPs operated by oneself (where Co-RTWT consultation has been performed)

[0293] - The AP indicates that all R-TWT SPs are targets through the Teardown frame transmitted to the opposing AP.

[0294] i) The relevant instruction can be performed by setting the Broadcast TWT ID of the R-TWT SP for which release is requested to a pre-specified value (e.g., 0 or 31).

[0295] In addition, the Teardown frame contains information indicating that the R-TWT SP for which release is requested is the Transmitter's R-TWT SP.

[0296] - In this case, Co-RTWT consultation regarding the R-TWT SP operated by the counterpart AP (the AP receiving the request to release Co-RTWT consultation) is not affected.

[0297] 4. Lifting of Co-RTWT consultation regarding specific R-TWT SPs operated by the opposing AP.

[0298] - An AP requesting the release of Co-RTWT negotiation for a specific R-TWT SP indicates the Broadcast TWT ID of the said specific R-TWT SP through a Teardown frame transmitted to the other AP.

[0299] i) In this case, the Broadcast TWT ID of the specific R-TWT SP is the Broadcast TWT ID assigned by the counterpart AP to the specific R-TWT SP.

[0300] In addition, the Teardown frame includes information indicating that the R-TWT SP for which release was requested is the Receiver's R-TWT SP.

[0301] - In this case, Co-RTWT agreements established between the two APs for other R-TWT SPs (excluding the specific R-TWT SP mentioned above) are not affected.

[0302] 5. Release of Co-RTWT consultation for all R-TWT SPs operated by the opposing AP (where Co-RTWT consultation has been performed)

[0303] - The AP indicates that all R-TWT SPs are targets through the Teardown frame transmitted to the opposing AP.

[0304] i) The relevant instruction can be performed by setting the Broadcast TWT ID of the R-TWT SP for which release is requested to a pre-specified value (e.g., 0 or 31).

[0305] In addition, the Teardown frame includes information indicating that the R-TWT SP for which release was requested is the Receiver's R-TWT SP.

[0306] - In this case, Co-RTWT consultation for the R-TWT SP operated by the AP transmitting the Teardown frame (the AP transmitting the request to release Co-RTWT consultation) is not affected.

[0307] <Multi-AP 조정의 관리(Maintenance)>

[0308] Conventional Wi-Fi APs can change the operating parameters of the BSS they manage at any time during the operation of the BSS. For example, the AP may make decisions such as changing the BSS's operating channel or modifying the EDCA parameter set. In this case, the AP performs a procedure to notify non-AP STAs affiliated with the BSS so that they can recognize the changed BSS parameters and modify their operations appropriately. In particular, when parameters considered important are changed, the AP manages this as a critical update and performs actions to notify non-AP STAs that such an update has occurred (or is scheduled to occur). Specifically, the AP helps non-AP STAs recognize whether a critical update has occurred through the Check Beacon field included in the Traffic Indication Map (TIM) frame it transmits. A STA that recognizes that a critical update has occurred via the TIM frame must obtain (update) information related to the parameter that triggered the critical update by receiving the beacon frame. The situation managed by the AP as a Critical Update is when a change occurs in any of the following elements included in the beacon frame. (Based on Wi-Fi 6)

[0309] - Inclusion of a Channel Switch Announcement element

[0310] - Inclusion of an Extended Channel Switch Announcement element

[0311] - Modification of the EDCA parameters element

[0312] - Inclusion of a Quiet element

[0313] - Modification of the DSSS Parameter Set

[0314] - Modification of the HT Operation element

[0315] - Inclusion of a Wide Bandwidth Channel Switch element

[0316] - Inclusion of a Channel Switch Wrapper element

[0317] - Inclusion of an Operating Mode Notification element

[0318] - Inclusion of a Quiet Channel element

[0319] - Modification of the VHT Operation element

[0320] - Modification of the HE Operation element

[0321] - Insertion of a Broadcast TWT element

[0322] - Inclusion of the BSS Color Change Announcement element

[0323] - Modification of the MU EDCA Parameter Set element

[0324] - Modification of the Spatial Reuse Parameter Set element

[0325] - Modification of the UORA Parameter Set element

[0326] - Insertion of an Index Adjustment Factor field in a Multiple BSSID Configuration element

[0327] As such, when a critical update occurs (or is scheduled to occur) in the BSS it operates, the AP must provide information so that member STAs can recognize the changed parameters and operate in the correct manner, thereby enabling both AP and non-AP STAs to perform unified operations regarding the operating channel, operating mode, channel access rules, channel quieting, etc.

[0328] In conventional Wi-Fi, only parameter management between the AP and the member STAs of the BSS operated by the AP was required; however, as considered in one embodiment of the present invention, if coordination between APs is performed, parameter management between APs must also be performed. In other words, if an AP that has performed M-AP coordination changes a specific parameter, there are situations where the counterpart AP that has performed M-AP coordination must recognize this and take action. Therefore, a procedure is required for APs to notify each other that their parameters have been changed (or are scheduled to be changed). At this time, it is possible for the already established M-AP coordination to be updated based on the changed parameter.

[0329] For example, if one of the two APs performing M-AP Coordinated Puncturing changes the main channel of the BSS, the other AP can support puncturing for the changed main channel of the said one AP. That is, it is possible for a subchannel that has undergone static puncturing (disabled subchannel) by M-AP Coordinated Puncturing to be changed to another subchannel by changing the main channel of the other AP.

[0330] As another example, if one of the two APs performing M-AP Coordinated Puncturing operates a new R-TWT SP, the other AP can support Coordinated Puncturing for the said new R-TWT SP interval. In other words, the time interval during which puncturing is performed by M-AP Coordinated Puncturing can be extended by the addition of the other AP's R-TWT SP. Conversely, the time interval during which puncturing is performed by M-AP Coordinated Puncturing can be shortened by the deletion (removal) of the other AP's R-TWT SP.

[0331] As another example, if one of two APs performing M-AP Coordinated Resource Sharing changes the Operating BW of the BSS, the other AP may need to allocate resources by taking into account the changed Operating BW of the one AP when determining the resources to be shared with said one AP. If the other AP reduces its Operating BW from the existing 80 MHz to 40 MHz, the AP must allocate resources to said AP only for the 40 MHz band including the main channel of said AP, and not allocate resources for other bands within the 80 MHz band excluding the Primary 40 MHz.

[0332] Accordingly, similar to how a conventional Wi-Fi AP instructs non-AP STAs that are members of its BSS to recognize BSS parameter updates, an AP that has performed M-AP coordination may instruct other APs to recognize its BSS parameter updates when it intends to change its BSS parameters. In this case, the type of M-AP critical update that the AP that has performed M-AP coordination must instruct to change its BSS parameters may include at least one of a) to e) described below. An AP that has generated an M-AP critical update must make other APs recognize the content of its critical update by transmitting a frame containing the element that generated the critical update in a 20 MHz duplicated format through its operating channel.

[0333] For example, an AP that has generated a critical update according to a) described below must transmit a frame (Channel Switch Announcement frame) containing a Channel Switch Announcement element in a 20 MHz duplicated format so that the other AP can recognize its Channel Switch plan.

[0334] As another example, an AP that has received a critical update due to a) to e) described below must transmit a beacon frame through all subchannels (idle subchannels) included in the operating channel as well as the main channel at every TBTT. That is, the beacon frame must be transmitted as a 20 MHz duplicated PPDU (20 MHz non-HT duplicated PPDU or 20 MHz duplicated UHR PPDU).

[0335] a) We plan to change the BSS operating channels.

[0336] That is, if the beacon frame transmitted by itself includes i) a Channel Switch Announcement element, ii) an Extended Channel Switch Announcement element, iii) a Wide Bandwidth Channel Switch element, or iv) a Channel Switch Wrapper element

[0337] b) Plan to add / change the Quiet duration of BSS

[0338] In other words, if the beacon frame transmitted includes i) a Quiet element or ii) a Quiet Channel element

[0339] c) We plan to change the BSS's Operating BW.

[0340] That is, in the case where at least one of the i) HT Operation element, ii) VHT Operation element, iii) HE Operation element, iv) EHT Operation element, or v) UHR Operation element included in the beacon frame transmitted by itself is changed to a value different from the existing one

[0341] d) When planning to change the BSS color

[0342] In other words, when the beacon frame transmitted includes a BSS Color Change Announcement element

[0343] e) When the R-TWT SP operated in the BSS is scheduled to be changed (addition / removal, etc.)

[0344] In other words, when the beacon frame being transmitted indicates a new R-TWT SP, or includes a Broadcast TWT element from which the existing R-TWT SP has been removed

[0345] In the case of a) described above, this corresponds to a situation where the AP's operating class / channel (frequency position of the operating channel and / or the position of the main channel) changes. As the AP's operating channel changes, a situation occurs where coordinated operation with the counterpart AP that performed M-AP adjustment becomes impossible, or a situation occurs where the channel to which the adjustment operation applies changes.

[0346] For example, as a result of the first AP changing its operating channel after performing M-AP coordination with the second AP, the operating channels of the first AP and the second AP may not overlap at all. In this case, there are no actions that the first AP and the second AP can perform for M-AP coordination, and therefore, the M-AP coordination established between the two APs needs to be terminated. At this time, the first AP notifies the second AP of its plan to change its operating channel so that the second AP can be aware of it, and the second AP may consider the M-AP coordination established with the first AP to be terminated at the time the first AP changes its operating channel.

[0347] As another example, as a result of the first AP, which has performed coordination for M-AP Coordinated Puncturing with the second AP, changing the main channel, the subchannel to which the second AP must apply Puncturing (the subchannel corresponding to the first AP's main channel) may change. In this case, the first AP may instruct the second AP to perform Coordinated Puncturing on its changed main channel by instructing the second AP to change its own main channel.

[0348] b) applies when an AP sets a Quiet duration for Channel measurement or R-TWT SP, and a counterpart AP that recognizes that a specific AP has set a Quiet duration can set a Quiet duration identical to the Quiet duration set by the specific AP in its own BSS. That is, APs that have performed M-AP adjustment can support each STA in performing more accurate Channel measurement or in obtaining channel access rights at the start of R-TWT SP by performing adjustments to set the same time interval as the Quiet duration.

[0349] c) is a situation in which the AP changes the BSS’s Operating BW, thereby making it impossible to coordinate with the counterpart AP that performed M-AP coordination, or a situation in which the type of RU (Resource unit) that can be allocated through resource sharing changes.

[0350] For example, as a result of the first AP changing the Operating BW after performing M-AP coordination with the second AP, the operating channels of the first AP and the second AP may not overlap at all. In this case, there are no actions that the first AP and the second AP can perform for M-AP coordination, and therefore, the M-AP coordination established between the two APs needs to be terminated. At this time, the first AP notifies the second AP of its plan to change the Operating BW so that the second AP can be aware of it, and the second AP may consider the M-AP coordination established with the first AP to be terminated at the time when the first AP changes the Operating BW.

[0351] As another example, as a result of the first AP changing its operating BW after performing coordination for M-AP Coordinated Resource Sharing with the second AP, the types of RUs that the second AP can allocate to the first AP may increase or decrease (increase in the types of RUs when the BW increases, and decrease in the types of RUs when the BW decreases). In this case, the first AP can help the second AP perform resource sharing that takes its changed operating BW into account by instructing the second AP on its plan to change its operating BW.

[0352] Cases d) and e) are BSS parameter changes that cause changes in the method and timing of application of M-AP Coordinated Spatial Reuse and M-AP Coordinated R-TWT, respectively, and detailed explanations are omitted. In this case, M-AP Coordinated R-TWT (Co-RTWT) refers to an M-AP coordination technique that terminates the TXOP before the R-TWT SP of the counterpart AP starts, after exchanging information on the R-TWT SP between APs.

[0353] Established MAPC (Multi-AP Coordination) Management Techniques

[0354] According to one embodiment of the present invention described above, an AP that has established an MAPC with a counterpart AP may transmit a teardown frame to release the agreement established with the counterpart AP. At this time, the AP transmitting the teardown frame to the counterpart AP may request release by individually specifying the Coordinated Scheme to be released, or request release for all agreements established with the counterpart AP. Additionally, the AP may request release for individual Coordinated Schemes or all Coordinated Schemes to all counterpart APs with which it has performed MAPC agreements by transmitting a Broadcast address teardown frame. An AP that receives an Individually address teardown frame or a Broadcast address teardown frame transmitted by the counterpart AP releases the Coordinated Scheme (a specified Coordinated Scheme or all Coordinated Schemes that performed agreements with the counterpart AP) for which release was requested by the teardown frame when the teardown frame was received. At this time, the AP must transmit a tear-down frame to the other AP to release the adjusted method, or the AP that receives the said tear-down frame from the other AP must request the release itself as soon as practical in implementation, or apply the changes that are applied as a result of the release of the adjustment for which the other AP requested release.

[0355] For example, an AP that has established M-AP Coordinated R-TWT (Co-RTWT) coordination to protect the R-TWT SP of a counterpart AP terminates protection of the counterpart AP's R-TWT SP by no longer including the TWT element corresponding to the counterpart AP's R-TWT SP in the beacon frame it transmits, when it transmits a teardown frame to the counterpart AP to release the Co-RTWT coordination with the counterpart AP, or receives a teardown frame from the counterpart AP requesting the release of the Co-RTWT coordination. In this case, the AP terminating protection of the counterpart AP's R-TWT SP may not include the TWT element corresponding to the R-TWT SP in the beacons transmitted after the point in time when protection for the R-TWT SP is released, regardless of the duration of the R-TWT SP for which protection was requested. That is, when protection for a specific R-TWT SP is released (by a teardown frame), protection for said specific R-TWT SP is immediately stopped (in accordance with the above-mentioned "as soon as practical"), regardless of the duration indicated by the Broadcast TWT Persistence subfield corresponding to said specific R-TWT SP. At this time, in order to stop protection for the specific R-TWT SP of the counterpart AP, the AP no longer includes the TWT element for said specific R-TWT SP in the beacon frame it transmits.

[0356] As another example, an AP that has performed Co-BF (Coordinated Beamforming), Co-SR (Coordinated Spatial Reuse), and Co-TDMA (Coordinated TDMA) consultation with a counterpart AP transmits a Teardown frame to the counterpart AP to terminate the Co-BF, Co-SR, and Co-TDMA consultation, or if a Teardown frame requesting termination of the Co-BF, Co-SR, and Co-TDMA consultation is received from the counterpart AP, it no longer transmits an initial control frame to the counterpart AP to initiate operation using Co-BF, Co-SR, and Co-TDMA.

[0357] New MAPC Negotiation Management

[0358] Even APs that support Multi-AP Coordination may decide to restrict the execution of new Multi-AP Coordination (MAPC) depending on operational objectives. For example, an AP that has already completed Co-BF negotiations with multiple APs may not wish to conduct further Co-BF negotiations for various reasons, such as when the expected benefits from negotiating with more APs are small, or when the management burden of handling more Co-BF negotiations is anticipated to increase. Although Co-BF was used as an example, new negotiations for other types of MAPC can also be blocked at the discretion of the AP; in such cases, the AP must instruct other APs that it has no intention of conducting new negotiations. This is intended to prevent a situation where MAPC negotiation request frames are repeatedly sent to an AP that has no intention of conducting new negotiations, and where negotiations for new negotiations are repeatedly rejected. Therefore, each AP must indicate whether it intends to conduct a new MAPC negotiation through the frames it transmits (e.g., M-AP beacon frames), thereby enabling the receiving counterparty AP to verify whether it intends to conduct a new MAPC negotiation. Accordingly, an AP that receives a frame transmitted by a counterparty AP may initiate the procedure for a new MAPC negotiation with said counterparty AP only when the frame transmitted by the counterparty AP indicates that the counterparty AP intends to conduct a new MAPC negotiation. In other words, an AP may transmit a MAPC negotiation request frame for conducting a new MAPC negotiation only to an AP that has indicated an intention to conduct a new MAPC negotiation. That is to say, an AP must not request a new MAPC negotiation from an AP that has indicated no intention to conduct a new MAPC negotiation.In other words, MAPC negotiation request frames must not be transmitted. However, if the MAPC negotiation request frame that an AP intends to transmit is for the purpose of modifying an already established coordination (such as changing or releasing parameters), the AP may transmit the frame even to an AP that has indicated it has no intention of performing a new MAPC negotiation.

[0359] Meanwhile, whether an AP intends to conduct new negotiations for each coordination method may depend on the AP's choice. That is, an AP may intend to conduct new negotiations for a specific coordination method but not for another. For example, an AP may intend to conduct new negotiations for Co-TDMA but plan not to conduct new negotiations for Co-BF. This may be a negotiation management method adopted when an AP wishes to access the medium more frequently by conducting negotiations with more APs regarding Co-TDMA, while simultaneously limiting the increase in operational complexity by discontinuing new negotiations for Co-BF.

[0360] In summary, the AP can decide whether to allow a new negotiation on an MAPC method basis. In this case, the AP can separately indicate whether it intends to conduct a new negotiation for each MAPC method. Each AP must indicate whether it intends to conduct a new MAPC negotiation for each MAPC method via the frames it transmits (e.g., M-AP beacon frames), thereby enabling the receiving counterparty AP to verify whether it intends to conduct a new MAPC negotiation for each MAPC method. Therefore, an AP that receives a frame transmitted by a counterparty AP can request a new MAPC negotiation only for the specific MAPC method for which the counterparty AP indicated an intention to conduct a new negotiation via the transmitted frame. For example, if the counterpart AP indicates that it intends to conduct a new MAPC negotiation regarding the first MAPC method and does not intend to conduct a new MAPC negotiation regarding the second MAPC method, the AP that intends to conduct a new MAPC negotiation with said counterpart AP must request a new negotiation only for said first MAPC method and must not request a new negotiation for said second MAPC method. In other words, the AP must not transmit a MAPC negotiation request frame to the counterpart AP requesting a new negotiation for the MAPC method for which counterpart A has indicated that it has no intention to conduct a new MAPC negotiation. However, if the MAPC negotiation request frame that the AP intends to transmit is for a change to an already established coordination (such as changing or releasing parameters), the AP may transmit the frame even if the counterpart AP has indicated that it has no intention to conduct a new MAPC negotiation for said MAPC method.

[0361] In other words, an AP may negotiate with other APs for only some of the methods it supports. In this case, the AP may transmit a management frame (e.g., a beacon frame, a request frame, or a response frame) to other APs that includes a MAPC function field specifying at least one method it supports and a MAPC parameter field specifying one or more methods for which the AP intends to negotiate with other APs. The AP may indicate that it intends to negotiate for a specific method by transmitting a value in the field corresponding to the method among the at least one method it supports that it intends to negotiate with other APs set to a value indicating negotiation (e.g., '1').

[0362] For example, the methods that APs can negotiate via MAPC may include Coordinated Beamforming (Co-BF), Coordinated Spatial Reuse (Co-SR), Coordinated Time Division Multiple Access (Co-TDMA), Coordinated Restricted Target Wake Time (Co-RTWT), and Coordinated Channel Recommendation (Co-CR). An AP can inform other APs of whether it supports the above methods through fields corresponding to each method. Additionally, an AP may include fields that individually indicate whether a negotiation request has been made for each of the above methods. An AP can proceed with negotiation on a specific method with another AP by setting the value of the field corresponding to the requested method to '1' and transmitting it to another AP via a management frame.

[0363] For example, an AP may include MAPC elements in a beacon frame. A MAPC Common Info field containing information that applies commonly to all MAPC schemes included in the MAPC element may consist of a MAPC Common Info Length field, a MAPC Capabilities field, a MAPC Parameters field, and an optionally included AP Identifier (ID) field. Here, the MAPC Common Info Length field indicates the total number of octets of the common information field including itself, and the MAPC Capabilities field may include an AP TB PPDU Response Support subfield to indicate whether the AP (e.g., UHR AP) supports a specific MAPC technology, and subfields indicating whether each of the following is supported: Coordination Beamforming (Co-BF), Coordination Space Reuse (Co-SR), Coordination Time Division Multiple Access (Co-TDMA), Coordination Restricted TWT (Co-RTWT), Coordination Contention-Based Access (Co-CR), and MAPC Security scheme. Furthermore, the above MAPC parameter field indicates whether actual agreement establishment has been activated and whether security negotiation is required for each supported MAPC method, and specifically, it may be configured to include Agreement Establishment Enabled subfields for each MAPC method that are set to 1 only when the support subfield of the corresponding method in the above MAPC capability field is set to 1 and at the same time the AP has activated negotiation for a new MAPC agreement establishment for that method, and a Protected Negotiations Required subfield that indicates whether the use of a Protected MAPC negotiation request and response frame is mandatory to perform MAPC agreement negotiation with the AP.

[0364] <MAPC을 위한 프레임 포맷>

[0365] As previously explained, APs supporting MAPC can conduct consultations for utilizing the MAPC method, and the consultation procedure includes a discovery procedure, a negotiation request procedure, a negotiation response procedure, a negotiation update procedure (which can be understood as updating the established negotiation when a new consultation is conducted regarding an already established adjustment), and a negotiation teardown procedure. At this time, each consultation procedure is performed using a frame of a pre-specified format, and examples of frame formats that can be used in each consultation procedure are described in this invention. However, the frame format can be changed at any time, and it is possible to use a frame format in the MAPC consultation procedure in which other subfields not considered in this invention are added, some of the subfields considered in this invention are removed, or field names are specified differently. Therefore, the names and formats of frames used in the present invention should be understood as being for illustrative purposes only, and even if other frames / fields having the same or similar functions as the frames / fields described in the present invention are utilized, or if some fields are added or removed, if the functions intended to be provided for the MAPC consultation procedure through the present invention are implemented in the same or similar way, this can be considered not to be outside the spirit of the present invention.

[0366] Before describing the frame format examples of the frames used in each MAPC consultation procedure, the aforementioned MAPC consultation procedure of the present invention is briefly summarized. Detailed information regarding the rules and signaling methods applied to each consultation procedure is omitted as it has been explained through the embodiments of the present invention described above.

[0367] Discovery Procedure: APs that wish to perform MAPC with other APs inform the other APs of the types of MAPC methods they support and whether they intend to perform new negotiations for each MAPC method. If it is confirmed that the other AP supports the MAPC they wish to perform, they can perform a negotiation procedure for each method. To allow APs to discover each other's presence and verify the MAPC-related capabilities they support, each AP transmits an M-AP Beacon frame, and the name of the frame may be defined by other names, such as an MAPC Discovery Frame. The M-AP Beacon (MAP Discovery Frame) may additionally include an indication of whether there is an intention to perform new negotiations for each MAPC method, and APs receiving this can decide whether to perform MAPC negotiations with the AP that transmitted the M-BA Beacon based on the indicated information.

[0368] Negotiation Request Procedure: An AP that discovers the existence of an adjacent AP supporting the MAPC it intends to perform may initiate a new MAPC negotiation by transmitting an M-AP coordination request frame (also known as a MAPC negotiation request frame) to the other AP for the purpose of attempting to negotiate the MAPC method with the said adjacent AP. At this time, the AP transmitting the MAPC negotiation request frame to the other AP may request negotiation only for the MAPC method among the MAPC methods supported by the other AP that the other AP has indicated as having the intention to perform a new negotiation.

[0369] Negotiation Response Procedure: An AP that receives a MAPC negotiation request frame transmitted from another AP may accept or reject the negotiation requested by the received MAPC negotiation request frame by responding with a MAPC negotiation response frame. At this time, the AP responding with the MAPC negotiation response frame indicates whether to accept or reject each of the one or more MAPC methods for which negotiation was requested by the MAPC negotiation request frame. If an acceptance of the negotiation request for a specific MAPC method is responded to via the MAPC negotiation response frame, the negotiation regarding the said specific MAPC method is established between the AP that transmitted the MAPC negotiation request frame and the AP that responded with the MAPC negotiation response frame, and an operation using the said specific MAPC method is performed between the two APs. At this time, the MAPC method having the established negotiation between the two APs can be understood as an Active MAPC method.

[0370] Negotiation Update Procedure: Two APs wishing to update the parameters used in an already established MAPC method may update the parameters used in that method by attempting a new negotiation regarding the said MAPC method (an MAPC method with an already established agreement). In this case, the two APs initiate a new negotiation procedure for the already agreed-upon MAPC method, and the aforementioned MAPC negotiation request / response frames may be reused in this process. When a new negotiation regarding the already established MAPC method is completed between the two APs (i.e., a MAPC negotiation response frame indicating Accept for the said MAPC method is newly exchanged between the two APs), the two APs perform operations according to the MAPC method using the parameters agreed upon in the newly completed negotiation process. At this time, the negotiation procedure performed to update the parameters for the already established MAPC method does not affect the active state (whether it is active or inactive) of the said MAPC method. That is, even if the AP responding with the MAPC negotiation response frame rejects the requested parameter update via the MAPC negotiation request frame, the MAPC method remains in an active state. In other words, an agreement established before negotiations for a parameter update are conducted remains valid even if the new negotiations are rejected or fail.

[0371] Negotiation Tear-down Procedure: An AP that wishes to release an established MAPC agreement performed with a counterpart AP may notify that the established MAPC agreement performed with said counterpart AP has been released by transmitting a MAPC negotiation tear-down frame (or MAPC tear-down frame) with the counterpart AP as the destination device. Through the MAPC negotiation tear-down frame it transmits, the AP notifying the release may perform various forms of release notification, such as: 1. Release of all MAPC agreements established with the counterpart AP; 2. Release of a designated MAPC agreement among the MAPC agreements established with the counterpart AP; and 3. Release of protection agreement for a specific R-TWT SP among the R-TWTs protected by the Co-RTWT method established with the counterpart AP. Additionally, the AP may notify all APs with which it performed MAPC agreements of the release of the MAPC agreement by transmitting a Broadcast address MAPC negotiation tear-down frame.

[0372] FIG. 15 shows an example of a frame format used in a discovery procedure for MAPC according to an embodiment of the present invention.

[0373] Referring to FIG. 15, the MAPC discovery frame format has a configuration including Category, Public Action, Dialog Token, and Discovery MAPC Element.

[0374] The Category field is set to a value (i.e., 4) indicating that the frame is an Action frame. The Public Action field is set to a value indicating that the frame is an MAPC discovery frame or a frame exchanged between APs for MAPC. The Dialog Token field is set to a non-zero value selected by the AP transmitting the frame.

[0375] The discovery MAPC element includes the MAPC Control field and the MAPC Common Info field.

[0376] The MAPC Control field includes the MAPC Type field, the MAPC Agreement Establishment Enabled field, and the MAPC Parameters Present field. The MAPC Type is set to a value indicating that it is a discovery type; therefore, an AP receiving this field can recognize that it is a MAPC discovery frame transmitted by another AP. The MAPC Agreement Establishment Enabled field indicates whether the AP transmitting this field intends to conduct a new MAPC negotiation; an AP intending to conduct a new negotiation sets this field to 1 and transmits it. An AP that confirms that the MAPC Agreement Establishment Enabled field transmitted by another AP is set to 0 must not request negotiation for the establishment of a new MAPC Agreement from the said other AP. The MAPC Parameters Present field indicates whether the MAPC Parameters field is included in the MAPC Common Info field, and it can be set to 1 only when the accompanying MAPC Agreement Establishment Enabled field is set to 1.

[0377] The MAPC Common Info field includes the MAPC Capabilities field and additionally includes the MAPC Parameters field if the MAPC Parameters Present field of the MAPC Control field is indicated as 1. MAPC Parameters Present field

[0378] The MAPC Capabilities field includes the AP TB PPDU Response Support, Co-BF Support, Co-SR Support, Co-TDMA Support, and Co-RTWT Support fields, and each field included in the MAPC Capabilities field is configured as follows.

[0379] AP TB PPDU Response Support field: Set to 1 if the AP sending the field can respond with a TB PPDU in response to the trigger frame sent by the other AP, and set to 0 otherwise.

[0380] - Co-BF Support: Set to 1 if the AP transmitting the field supports operation using the Co-BF method among MAPC methods, and set to 0 otherwise.

[0381] - Co-SR Support: Set to 1 if the AP transmitting the field supports operation using the Co-SR method among MAPC methods, and set to 0 otherwise.

[0382] - Co-TDMA Support: Set to 1 if the AP transmitting this field supports operation using the Co-TDMA method among MAPC methods, and set to 0 otherwise.

[0383] - Co-RTWT Support: Set to 1 if the AP transmitting the field supports operation using the Co-RTWT method among MAPC methods, and set to 0 otherwise.

[0384] In this way, if the support status for each MAPC method is indicated through a frame transmitted by the AP, the AP that receives the frame can attempt to negotiate MAPC negotiations only for the MAPC methods supported by the AP that transmitted the frame.

[0385] - The MAPC Parameters field includes the Co-BF New Agreement Enabled, Co-SR New Agreement Enabled, Co-TDMA New Agreement Enabled, and Co-RTWT New Agreement Enabled fields, and each field included in the MAPC Parameters field is configured as follows.

[0386] - Co-BF New Agreement Enabled field: Set to 1 if the AP transmitting this field allows new negotiation for the Co-BF method among MAPC methods, and set to 0 otherwise.

[0387] - Co-SR New Agreement Enabled field: Set to 1 if the AP transmitting this field allows new negotiation for the Co-SR method among MAPC methods, and set to 0 otherwise.

[0388] - Co-TDMA New Agreement Enabled field: Set to 1 if the AP transmitting this field allows new negotiation for the Co-TDMA method among MAPC methods, and set to 0 otherwise.

[0389] - Co-RTWT New Agreement Enabled field: Set to 1 if the AP transmitting this field allows new negotiation for the Co-RTWT method among MAPC methods, and set to 0 otherwise.

[0390] In this way, if the permission to negotiate a new MAPC method is indicated through a frame transmitted by the AP, the AP that receives the frame can attempt to negotiate a new MAPC negotiation only for the MAPC methods for which the AP that transmitted the frame allows new negotiation.

[0391] That is, an AP according to one embodiment transmits an Action frame-based MAPC discovery frame for multi-AP coordination (MAPC) with another AP, and the discovery MAPC element included in the frame includes a MAPC common information field composed of a MAPC control field indicating whether the AP's overall willingness to negotiate and parameter fields are included, a MAPC Capabilities field indicating specific MAPC methods supported by the AP (Co-BF, Co-SR, Co-TDMA, Co-RTWT, etc.), and a MAPC parameter field that is included only when indicated by the control field and specifies whether to allow new negotiation for each supported method, thereby controlling the other AP that receives it to effectively request a new MAPC agreement only for a specific MAPC method where both the supported capabilities and willingness to negotiate have been confirmed.

[0392] FIG. 16 shows an example of a frame format used in a MAPC negotiation procedure according to an embodiment of the present invention.

[0393] The frames used in the MAPC negotiation process are classified into two types: MAPC negotiation request frames and MAPC negotiation response frames, and both frames have the same frame format. Among the fields included in the frames used in the MAPC negotiation process, if a field with the same name and setting / interpretation method as a field included in the frames used in the MAPC discovery process is identical, the explanation is omitted for the sake of repetition.

[0394] The MAPC negotiation request / response frame has a configuration including Category, Public Action, Dialog Token, and negotiation MAPC Element. The Category and Public Action fields are set to a value indicating that the frame is a Public Action frame, a value indicating that the frame is an MAPC negotiation request / response frame, or a value indicating that the frame is a frame exchanged between APs for MAPC.

[0395] The Category field is set to a value (i.e., 4) indicating that the frame is an Action frame. The Public Action field is set to a value indicating that the frame is an MAPC discovery frame or a frame exchanged between APs for MAPC. The Dialog Token field included in the MAPC negotiation request frame is set to a non-zero value selected by the AP sending the frame, and the Dialog Token field included in the MAPC negotiation response frame is set to the same value as the Dialog Token field value of the MAPC negotiation request frame received by the AP sending the response frame.

[0396] The negotiation MAPC element includes the MAPC Control field, the MAPC Common Info field, and the MAPC Method Information(s) field. The MAPC Common Info field has the same configuration / setting method as the MAPC Common Info field included in the MAPC Discovery frame, except that it may additionally include an AP ID field. In this case, the AP ID field is a field that indicates the AP ID value assigned to the destination device of the frame containing the field.

[0397] The MAPC Control field of an MAPC negotiation frame includes the MAPC Type field and the AP ID Present field. The MAPC Type field is set to a value indicating whether the frame containing the field is an MAPC negotiation request frame or an MAPC negotiation response frame. The AP ID Present field indicates whether the AP ID field is included in the MAP Common Info field. The AP ID Present field is set to 1 only in frames exchanged to perform negotiation for Co-BF, Co-SR, or Co-TDMA among MAPC negotiation request / response frames exchanged between APs for which no established MAPC negotiation already exists for Co-BF, Co-SR, or Co-TDMA. This is because there is no need to assign a new AP ID between APs that have already assigned each other AP IDs, and in the case of Co-RTWT, there are no actions performed by the two APs using each other's AP IDs.

[0398] A negotiation MAPC element may include one or more MAPC method Information(s) fields.

[0399] The MAPC Method Information(s) field includes a Subelement ID field, a Length field, and one or more MAPC Method Information Set fields. In this case, the MAPC Method Information(s) field containing one or more MAPC Method Information Set fields is limited to the type of MAPC coordination method indicated by the Subelement ID field being Co-RTWT. The Subelement ID field is set to a different value depending on which MAPC coordination method the information indicated by the corresponding MAPC Method Information(s) field refers to—that is, whether it is Co-BF or Co-SR, Co-TDMA, or Co-RTWT. The Length field indicates the length of the MAPC Method Information Set field.

[0400] The MAPC Method Information Set field of the MAPC Method Information(s) field includes the MAPC Method Control field, and the Last MAPC Method Information field of the MAPC Method Control field is set to 1 when the MAPC Method Information Set field containing the corresponding MAPC Method Control field is the last MAPC Method Information Set field included in the MAPC Method Information(s) field containing that field. The MAPC Method Control field of the MAPC Method Information Set field includes the MAPC Operation Type field, and the MAPC Operation Type field indicates the type of negotiation directed / requested to the counterpart AP through the MAPC Method Information Set field included in the MAPC Method Control field. If the MAPC Operation Type field is set to the first value, it indicates that the Parameter directed through the MAPC Method Information Set field containing that field is for a new MAPC negotiation. If the MAPC Method Information Set field is set to the second value, it indicates that the MAPC Method Information Set field containing that field is for canceling (tiering down) an established negotiation. If the MAPC Operation Type field is set to a third value, it indicates that the MAPC Method Information Set field, including that field, has been transmitted to accept the negotiation requested by the counterparty AP. If the MAPC Method Information Set field is set to a fourth value, it indicates that the MAPC Method Information field, including that field, has been transmitted to reject the negotiation requested by the counterparty AP.

[0401] The MAPC method Information Set fields for Co-RTWT (i.e., the Subelement ID field is set as a value for Co-RTWT) indicate / identify which ID the MAPC method Information Set field corresponds to for the R-TWT SP through the value of the MAPC Info field included in the MAPC method Control field. For example, if the MAPC method Information Set field for Co-RTWT corresponds to the first R-TWT SP, the MAPC Info field included in the MAPC method Control field of the MAPC method information Set field is set as a value specifying the ID for the first R-TWT SP (e.g., the Broadcast TWT ID assigned to the first R-TWT SP by the AP operating the first R-TWT SP).

[0402] Additionally, the Direction field included in the MAPC Control field of the MAPC Information Set field for Co-RTWT is used to indicate which of the two APs exchanging the frame operates the R-TWT SP indicated / identified through the MAPC Info field. For example, an AP transmitting the MAPC Control field for its own R-TWT SP may set the Direction field to a specific value (e.g., 1), while an AP transmitting the MAPC Control field for the R-TWT SP operated by the other AP may set the Direction field to a different value (e.g., 0). The Direction field can be set to a value indicating the R-TWT SP operated by the other AP only when the Operation type indicated through the MAPC Operation Type field is Agreement Teardown.

[0403] That is, when a management frame includes parameters for Co-RTWT configuration in the MAPC method within a MAPC element, identification information indicating whether the configured Co-RTWT's R-TWT is the R-TWT of the coordinating AP or the R-TWT of the coordinated AP may be included in the MAPC element. For example, such identification information may be transmitted by being included in the MAPC method information contained within the MAPC element.

[0404] Accordingly, an AP that wishes to terminate (tear down) the consultation with a specific R-TWT SP (an R-TWT SP operated by the counterpart AP) that has conducted Co-RTWT consultation with the counterpart AP may stop the Co-RTWT consultation with the specific R-TWT SP by transmitting a MAPC negotiation request frame configured in the following manner.

[0405] Subelement ID of the MAPC method Information(s) field = Co-RTWT

[0406] MAPC Operation Type of the MAPC Method Information Set Field = Agreement Teardown

[0407] MAPC Info field of the MAPC method Information Set field = ID of the specific R-TWT SP mentioned above

[0408] Direction field of the MAPC method Information Set field = Value indicating that it is the R-TWT SP of the counterpart AP

[0409] The MAPC method Parameter Set field of the MAPC method Information Set field includes parameters for the MAPC method corresponding to the MAPC method Information Set field. For example, the MAPC method Parameter Set field of the MAPC method Information Set field corresponding to Co-RTWT includes at least one of the following: an ID for the R-TWT SP for which protection is requested, information capable of identifying the start time of the R-TWT SP, period information of the R-TWT SP, and information related to the time during which the R-TWT SP is maintained. However, since the parameters exchanged for each MAPC method are irrelevant to the consultation procedure between APs intended to be provided in the present invention, a detailed description is omitted.

[0410] The frame format used in the negotiation update procedure is recycled as is from the negotiation request / response process, so a detailed explanation is omitted. The negotiation update procedure is achieved through a process in which newly agreed parameters are updated to existing agreed parameters when a new negotiation is performed regarding the MAPC method already established between two APs.

[0411] FIG. 17 shows an example of a frame format used in a MAPC teardown procedure according to an embodiment of the present invention.

[0412] The MAPC negotiation teardown frame includes Category, Public Action, Dialog Token, and Teardown MAPC Element. The Category and Public Action fields are set to a value indicating that the frame is a Public Action frame, a value indicating that the frame is an MAPC teardown frame, or a value indicating that the frame is a frame exchanged between APs for MAPC.

[0413] A teardown MAPC element contains only MAPC Control fields, in addition to fields (Element ID, Length, Element ID Extension) that indicate that the element is a teardown MAPC element.

[0414] The MAPC Control field of a teardown MAPC element includes the MAPC Type field and the Present Bit field.

[0415] The MAPC Type field is set to a value indicating "Teardown all" if the corresponding teardown frame is transmitted to instruct the teardown of all agreements established for all MACP schemes. In this case, the AP receiving the MAPC teardown frame interprets it as a directive to release all agreements established with the AP that transmitted the frame. That is, an AP sending a MAPC teardown frame with the MAPC Type field set to "Teardown all" to a Broadcast address can release all MAPC agreements it has established with other APs at once. At this time, if a MAPC teardown frame with the same setting is transmitted to an Individually Address, all agreements established between the transmitting AP and the destination AP are released.

[0416] The MAPC Type field is set to a value representing the Teardown per method if the corresponding teardown frame is transmitted to instruct the teardown of all agreements established for a specific MACP method. When the MAPC Type field is set to the Teardown per method, the MAPC Control field further includes the Teardown Co-BF, Teardown Co-SR, Teardown Co-TDMA, and Teardown Co-RTWT fields. The Teardown Co-BF field is set to 1 if a teardown for Co-BF is requested through the corresponding MAPC teardown frame. The Teardown Co-SR field is set to 1 if a teardown for Co-SR is requested through the corresponding MAPC teardown frame. The Teardown Co-TDMA field is set to 1 if a teardown for Co-TDMA is requested through the corresponding MAPC teardown frame. The Teardown Co-RTWT field is set to 1 if a teardown for Co-RTWT is requested through the corresponding MAPC teardown frame. When the MAPC Type is set to the Teardown per method, at least one of the four Teardown fields is set to 1, and all Teardown fields (a total of four fields for Co-BF, Co-SR, Co-TDMA, and Co-RTWT in the example, respectively) are restricted from being set to the same value (i.e., all set to 0 or all set to 1). This is because not requesting Teardown for all types of MAPC methods would render the transmission of MAPC Teardown frames meaningless, and instructing Teardown for all MAPC coordination methods is an instruction method that can be performed by setting the MAPC Type to Teardown all.

[0417] An AP transmitting a MAPC tier-down frame to a broadcast address with the MAPC Type field set to a value indicating the tier-down method can simultaneously release all agreements established with other APs regarding the coordination method specified by the tier-down fields. In this case, if a MAPC tier-down frame with the same configuration is transmitted to an individually address, the agreement regarding the coordination method specified by the tier-down fields among the agreements established between the transmitting AP and the destination AP is released.

[0418] <non-AP STA들의 불필요한 동작을 방지하기 위한 MAPC 협의 방법>

[0419] Frames exchanged between APs performing MAPC (e.g., MAPC discovery frames, MAPC negotiation request / response frames, MAPC negotiation teardown frames, etc.) are frames that do not need to be received by non-AP STAs. When APs exchange multiple frames during the process of performing MAPC, non-AP STAs must repeatedly receive and discard unnecessary frames. Considering that typical non-AP STAs operate using limited power resources such as batteries, it is desirable to avoid such problems.

[0420] To this end, APs performing MAPC can prevent non-AP STAs from attempting to decode frames due to restrictions related to the PPDU format, or induce them to filter the PPDU based on the value indicated in the PPDU Preamble, by setting the format of the PPDU containing the frame exchanged to perform MAPC and the PPDU Preamble to a value that non-AP STAs do not decode.

[0421] According to one embodiment of the present invention, APs performing MAPC can use the format of the PPDU exchanged between APs as UHR PPDU (UHR SU or UHR MU PPDU), thereby preventing non-AP STAs of the previous generation from receiving the PPDU (i.e., not attempting frame decoding).

[0422] Furthermore, to prevent UHR non-AP STAs from receiving UHR PPDUs containing frames transmitted for MAPC, the AP may set the UL / DL field included in the Preamble of the UHR PPDU containing frames transmitted for MAPC to a value representing UL (i.e., 1). In this case, non-AP STAs of the EHT / UHR and post-UHR generations determine that the PPDU is a UL PPDU transmitted to the AP, and filter it without receiving it.

[0423] Additionally, the AP can indicate that a frame included in the UHR PPDU is a frame for MAPC by setting the BSS Color field included in the Preamble of the UHR PPDU to a predetermined value (e.g., 0 or another predetermined value to indicate that the PPDU contains a frame for MAPC). If the BSS Color field indicates that the PPDU contains a frame for MAPC, each AP can decide to receive the frame for MAPC received in the PPDU, even if its own BSS Color differs from the value indicated by the PPDU's BSS Color field.

[0424] Alternatively, an AP transmitting a UHR PPDU containing a frame for MAPC may indicate that the UHR PPDU contains a frame for MAPC by setting a specific field included in the U-SIG of the UHR PPDU to a predetermined value. In this case, APs receiving the UHR PPDU can determine whether the UHR PPDU contains a MAPC frame based on the setting value of the specific field. In this case, an AP intending to decode the MAPC frame (e.g., an AP with capabilities related to MAPC consultation) may attempt to receive the MAPC frame included in the UHR PPDU, while an AP not intending to decode it may decide not to proceed with receiving the UHR PPDU.

[0425] <Co-RTWT 협의 절차 및 AP간의 교환 정보>

[0426] As described above, APs performing multiple AP cooperative operations can engage in consultations regarding various cooperative operations, and the cooperative operations for which consultation can be performed include Co-RTWT. Among the two APs performing Co-RTWT consultations, the AP requesting protection for its own R-TWT schedule from the other AP can be referred to as the Co-RTWT coordinating AP regarding the R-TWT schedule, and the AP performing the consultation regarding protection for the R-TWT schedule can be referred to as the Co-RTWT coordinated AP. At this time, as described above, it is possible for Co-RTWT consultations regarding multiple R-TWT schedules to be performed between the two APs, and it is possible for the AP requesting protection for each R-TWT SP and the AP accepting it to be different. Therefore, it is possible for each of the two APs to be both a Co-RTWT coordinating AP and a Co-RTWT coordinated AP to each other simultaneously. Therefore, the concept of Co-RTWT requesting / coordinating AP does not define a general relationship between two APs, but is a concept defined for each R-TWT SP where consultation between the two APs has been conducted.

[0427] Co-RTWT SP refers to the time during which protection is performed via the Co-RTWT mechanism for an R-TWT schedule for which the Co-RTWT coordinating AP and the Co-RTWT coordinated AP have completed consultation regarding protection. Since the R-TWT schedule consists of R-TWT SPs that appear repeatedly at regular time intervals, multiple Co-RTWT SPs occur when Co-RTWT consultation regarding the R-TWT schedule is completed.

[0428] The Co-RTWT SP start time refers to the TSF value of the Co-RTWT Coordination AP corresponding to the start time of the Co-RTWT SP that is initiated at the earliest point from when the Co-RTWT consultation between the two APs is performed.

[0429] The Co-RTWT Coordinating AP instructs the Co-RTWT mediated AP by including information regarding the R-TWT schedule requesting protection in the MAPC Request Parameter Set field of the MAPC Method Information field, and the Co-RTWT mediated AP can verify the information regarding the R-TWT schedule for which protection has been requested through this. At this time, the information regarding the R-TWT schedule that the Co-RTWT Coordinating AP instructs the Co-RTWT mediated AP is indicated through the Target Wake Time, Nominal Minimum TWT Wake Duration, TWT Wake Interval Mantissa, TWT Wake Interval Exponent, Broadcast TWT Persistence, and Restricted TWT Schedule Info fields. Since each field indicated through the MAPC Request Parameter Set field has the same / corresponding meaning as the fields with the same name included in the TWT element, the specific information indicated through each field can be verified in more detail through an embodiment of FIG. 19 described later.

[0430] A Co-RTWT Coordinating AP that instructs the Co-RTWT Coordinating AP regarding information on the R-TWT schedule through the MAPC request Parameter Set field instructs using fields set to the same values ​​as when announcing the information on the R-TWT schedule to its BSS. Therefore, when the Co-RTWT Coordinating AP checks the information on the R-TWT schedule through the fields received from the Co-RTWT Coordinating AP, it must interpret some fields using parameters used by the BSS operated by the Co-RTWT Coordinating AP.

[0431] For example, the Target Wake Time field specified for the R-TWT schedule is set based on the TSF of the Co-RTWT coordinating AP, and the Co-RTWT coordinated AP receiving this must consider the TSF offset between itself and the Co-RTWT coordinating AP to determine the time indicated by the Target Wake Time field. That is, if the value indicated by the Target Wake Time field is x (the TSF value of the Co-RTWT coordinating AP), the Co-RTWT coordinated AP can recognize that the R-TWT schedule of the Co-RTWT coordinating AP is initiated when its TSF reaches a value obtained by correcting x by the TSF offset (the TSF offset between the Co-RTWT coordinating AP and the Co-RTWT coordinated AP). An AP performing multi-AP cooperative operation can calculate its own TSF offset with that of the counterpart AP by receiving a frame containing a TimeStamp field among the frames transmitted by the counterpart AP (e.g., a beacon frame and / or an M-AP beacon frame, etc.), and since this has already been explained in the example of the present invention described above, further explanation will be omitted.

[0432] As another example, the Broadcast TWT Persistence field indicated for the R-TWT schedule indicates that the time interval during which the R-TWT SPs of the R-TWT schedule appear (or persist) is based on the TBTT of the Co-RTWT Coordinating AP; therefore, the Co-RTWT coordinated AP receiving this must consider the Beacon Interval of the Co-RTWT Coordinating AP when calculating the time interval during which the R-TWT SPs appear (or persist). Specifically, the Co-RTWT coordinated AP must calculate that the R-TWT SPs appear (or persist) for a time length corresponding to [(Co-RTWT Coordinating AP's Beacon Interval) x (value indicated through the Broadcast TWT Persistence field + 1)]. The method of indicating / interpreting other fields will be explained through an example of FIG. 18.

[0433] FIG. 18 shows an example of the format of a Request Parameter Set field for a MAPC that a Coordinating AP transmits to a Coordinated AP according to an embodiment of the present invention.

[0434] The MAPC request Parameter Set field shown in FIG. 18 (a) is a MAPC request Parameter Set field containing parameters for Co-RTWT, and includes Target Wake Time, Nominal Minimum TWT Wake Duration, TWT Wake Interval Mantissa, and Service Period Info fields.

[0435] The Target Wake Time field indicates the start time of the earliest Co-RTWT SP among the Co-RTWT SPs requesting protection from the Co-RTWT Coordinating AP. This field is set based on the Co-RTWT Coordinating AP's TSF, and the Co-RTWT Coordinating AP interprets the start time of the Co-RTWT SP indicated based on the Co-RTWT Coordinating AP's TSF by substituting it with a time based on its own TSF, based on the offset value between its own TSF and the Co-RTWT Coordinating AP's TSF.

[0436] The TWT Nominal Minimum TWT Wake Duration field indicates the duration for which each Co-RTWT SP is maintained, and the unit is 256 us. That is, the time length of each Co-RTWT SP generated in correspondence with the R-TWT schedule for which Co-RTWT consultation has been completed is indicated through this field.

[0437] The TWT Wake Interval Mantissa field is interpreted in combination with the TWT Wake Interval Exponent field included in the Service Period Info field and indicates the difference between the start times of each Co-RTWT SP.

[0438] The specific format of the Service Period Info field is shown in Fig. 18 (b).

[0439] Referring to Fig. 18(b), the Service Period Info field includes the TWT Wake Interval Exponent, Broadcast TWT Persistence, and Restricted TWT Schedule Info fields.

[0440] The TWT Wake Interval Exponent field is interpreted in combination with the above TWT Wake Interval Mantissa field and is used to indicate the difference between the start times of the Co-RTWT SP.

[0441] The Broadcast TWT Persistence field indicates the number of TBTTs that appear (or persist) during the time Co-RTWT SPs generated in response to the R-TWT schedule subject to negotiation are maintained, and the number of TBTTs is the TBTT of the BSS operated by the Co-RTWT Coordinating AP. If the Broadcast TWT Persistence field is set to a value between 0 and 254, it indicates that one more TBTT than the value indicated through the field appears during the time Co-RTWT SPs are maintained. The Co-RTWT Coordinating AP does not set the Broadcast TWT Persistence field transmitted to the Co-RTWT Coordinating AP to 255. Upon receiving the Broadcast TWT Persistence field from the Co-RTWT Coordinating AP, the Co-RTWT Coordinating AP can calculate the time during which Co-RTWT SPs appear (or persist) based on the number of TBTTs of the Co-RTWT Coordinating AP indicated through the Broadcast TWT Persistence field and the Beacon interval of the Co-RTWT Coordinating AP. That is, the time at which Co-RTWT SPs appear is calculated as (number of TBTTs of Co-RTWT coordination APs) x (Beacon interval of Co-RTWT coordination APs).

[0442] The Restricted TWT Schedule Info field is set in the same way as when a Co-RTWT coordination AP instructs its BSS the R-TWT SP to be coordinated (i.e., instructed via a TWT element included in a beacon frame transmitted by itself).

[0443] Meanwhile, the Co-RTWT Coordinating AP instructs the Co-RTWT Coordinating AP with the Broadcast TWT ID information it has assigned to the R-TWT schedule, which is indicated through the MAPC Request Parameter Set field. The Broadcast TWT ID information assigned to the R-TWT schedule subject to negotiation is indicated through the MAPC Info field of the MAPC Method Information Set field, which includes the MAPC Request Parameter Set field for the R-TWT scheduled, and is therefore not included in the MAPC Request Parameter Set field.

[0444] <Co-RTWT 협의를 완료한 Co-RTWT 피 조정 AP의 동작>

[0445] A Co-RTWT coordinated AP that has accepted protection for an R-TWT schedule requested by a Co-RTWT coordinated AP provides protection to the Co-RTWT SP by terminating its TXOP or abandoning the initiation of a TXOP before the Co-RTWT SPs initiate. Through this, the Co-RTWT coordinated AP that has performed Co-RTWT consultation with the Co-RTWT coordinated AP can increase the probability of successfully acquiring channel access (TXOP) at the start of the R-TWT SP and increase the probability of timely transmission of low-latency traffic. In this case, if the Co-RTWT coordinated AP abandoning the initiation of a TXOP cannot be terminated before the start of the Co-RTWT SP, it does not initiate the TXOP (abandons the TXOP initiation) and creates a new backoff counter. At this time, the AP creates a new backoff counter using the current Contention Window and does not change the Retry counter.

[0446] In addition, the Co-RTWT coordinating AP directs the R-TWT SP corresponding to the Co-RTWT SPs in the beacon frames it transmits so that non-AP STAs, who are members of the BSS it operates, can provide protection for the Co-RTWT SPs. More specifically, by announcing the R-TWT SP that starts at the same time as the Co-RTWT SPs through the beacon frames it transmits, the Co-RTWT coordinating AP can induce the member STAs of the BSS it operates to terminate the TXOP in accordance with the time when the Co-RTWT SP starts, or to forgo acquiring the TXOP in consideration of the time of the Co-RTWT SP. That is, the Co-RTWT coordinating AP implements R-TWT schedule protection according to the Co-RTWT agreement with the Co-RTWT coordinating AP by inducing the member STAs of the BSS it operates to perform the same protection actions it performs for the Co-RTWT SPs. The mechanism by which a Co-RTWT coordinating AP induces member non-APs of the BSS it operates to terminate a TXOP by announcing R-TWT SP information related to the Co-RTWT SP in the beacon frame it transmits is as follows: Non-AP STAs that comply with the 7th generation wireless LAN standard (802.11be), i.e., EHT non-AP STAs, perform protection on the R-TWT SP announced by the AP, and the protection operation is to manage the termination of one's TXOP before the start time of the R-TWT SP (including abandoning the initiation of the TXOP if the TXOP one intends to initiate cannot be terminated before the start time of the R-TWT SP).Accordingly, the Co-RTWT coordinating AP can induce EHT non-AP STAs to terminate a TXOP or delay the initiation of a TXOP in accordance with the Co-RTWT SP by announcing R-TWT SPs that are initiated at the same time as the Co-RTWT SPs through the beacon frames it transmits. Meanwhile, the R-TWT SPs announced by the AP include R-TWT SPs scheduled by other APs in the Multiple-BSS set to which the AP belongs, and EHT non-AP STAs that are members of the BSS operated by the AP apply the same protection mechanism to R-TWT SPs scheduled by other APs in the Multiple-BSS set. In this case, for the R-TWT SP of another AP in the Multiple-BSS set (an AP of a nontransmitted BSS) announced by the AP, the Restricted TWT Schedule Info subfield is set to 3 and the Broadcast TWT ID subfield is indicated as 31, and the specific method for indicating the R-TWT SP and the method for setting the subfields are explained through the format examples described below. In addition, the Co-RTWT mediated AP prevents non-AP STAs that do not follow channel access rules related to the R-TWT SP (i.e., EHT STAs that do not support the R-TWT SP and pre-EHT STAs) from performing channel access at the time the Co-RTWT SP starts by setting a Quiet interval that starts at the same time as the Co-RTWT SP in the BSS it operates. At this time, if the Co-RTWT mediated AP sets a Quiet interval that starts at the same time as the Co-RTWT SP (an error of less than a unit in the subfield specifying the start time of the Quiet interval may exist), non-AP STAs do not perform channel access during the Quiet interval in accordance with the operation of conventional Wi-Fi standards regarding the Quiet interval.

[0447] FIG. 19 shows an example of the format of a Broadcast TWT Parameter Set field used when indicating R-TWT SP information according to an embodiment of the present invention.

[0448] The Co-RTWT technology described in Fig. 19 can be implemented to mutually protect R-TWT schedules for delay-sensitive traffic between adjacent BSSs (OBSSs) in a multi-AP environment. A coordinating AP seeking to obtain protection for its own R-TWT schedule and a coordinating AP protecting said schedule establish a Co-RTWT agreement through a MAPC negotiation procedure. Specifically, the requesting AP initiating the negotiation transmits a Co-RTWT profile within a MAPC negotiation request frame that includes a Broadcast TWT ID identifying a specific R-TWT schedule and a MAPC action type field indicating the purpose of the negotiation (e.g., establishment, update, release), and by exchanging parameters with the responding AP, a unique Co-RTWT agreement can be established, identified by a combination of each MAC address and the Broadcast TWT ID.

[0449] When the above Co-RTWT agreement is established, the mediated AP may periodically perform an announcement by including a broadcast TWT element in its beacon frame, etc., to protect the active R-TWT schedule of the mediated AP. At this time, the mediated AP explicitly indicates that it is the R-TWT schedule of another AP it protects by setting the Restricted TWT Schedule Info field within the element to 3 and the broadcast TWT ID to 31. In addition, the mediated AP sets the schedule start time and TWT wake interval parameters converted based on the mediated AP's Time Synchronization Function (TSF), and induces accurate schedule synchronization of terminals within the network by calculating the number of remaining Target Beacon Transmission Time (TBTT) until the schedule ends and recording it in the broadcast TWT Persistence field.

[0450] Furthermore, as a media access control rule to substantially protect the R-TWT schedule of the regulating AP, the regulating AP must ensure that even if it acquires a Transmission Opportunity (TXOP), the TXOP is completely terminated before the start time of the regulating AP's R-TWT Service Period (SP). Accordingly, before starting frame transmission, the regulating AP must check whether there is sufficient time to complete frame exchange before the R-TWT SP starts, and if there is insufficient time, it must defer transmission and perform a new backoff procedure. However, if exceptional conditions are satisfied, such as the channel of the TXOP acquired by the regulating AP not overlapping with the regulating AP's BSS operation channel, or performing a specific non-channel connection (NPCA) based on the regulating AP's PPDU, the regulating AP may operate to extend the TXOP or avoid deferring transmission.

[0451] In this case, TWT SPs are classified into individually addressed TWT SPs established through negotiation between STAs and Broadcast TWT SPs scheduled by APs. R-TWT SPs are a type of Broadcast TWT SP; therefore, information related to R-TWT SPs is indicated through the Broadcast TWT Parameter Set field. The Broadcast TWT Parameter Set field is included in a TWT element when it is indicated that the corresponding TWT element is a Broadcast TWT through the Negotiation Type subfield of the Control field included in the TWT element.

[0452] Referring to FIG. 19(a), the Broadcast TWT Parameter Set field includes a Request Type field, and FIG. 19(b) illustrates the specific configuration of the Request Type field. The Target Wake Time subfield of the Broadcast TWT Parameter Set field is set to a TSF value (Time Sync Function) indicating the start time of the R-TWT SP indicated by the corresponding TWT element, and the AP indicating the Co-RTWT SP indicates its own TSF value corresponding to the time when the Co-RTWT SP is initiated through the corresponding subfield. The Nominal Minimum TWT Wake Duration subfield is a field indicating the duration of the R-TWT SP indicated by the corresponding TWT element. The unit of the duration length indicated by this field can be 256 us or 1 TU, but when utilized for Co-RTWT SP, 256 us is always used as the unit. The TWT Wake Interval Mantissa field is a field indicating the time period during which the Broadcast TWT SP indicated by the corresponding TWT element is repeated. The detailed configuration of the Broadcast TWT Info field is illustrated in Fig. 19 (c). The Restricted TWT Traffic Info field appears only when the information indicated by the corresponding TWT element is for an R-TWT SP operated by the AP transmitting the element. That is, the Broadcast TWT Parameter Set field of an R-TWT SP indicated for a Co-RTWT SP does not include the Restricted TWT Traffic Info field.The original purpose of the Restricted TWT Traffic Info field is to indicate the type of traffic (Traffic ID) that can be transmitted during the R-TWT SP indicated by the TWT element, and since the Co-RTWT SP is not used by the BSS of the AP transmitting the TWT element, information regarding the type of traffic is not indicated.

[0453] Referring to Fig. 19(b), the Request Type field included in the Broadcast TWT Parameter Set field includes TWT Request, TWT Setup Command, Trigger, Last Broadcast Parameter Set, Flow Type, Broadcast TWT Recommendation, TWT Wake Interval Exponent, and Align subfields. The TWT Request subfield is set to 1 in TWT elements transmitted by an STA requesting Individual TWT negotiation or by an STA requesting participation in a Broadcast TWT SP scheduled by an AP. Accordingly, an AP transmitting a TWT element corresponding to an R-TWT SP or Co-RTWT SP that it has scheduled sets the TWT Request subfield of the TWT element to 0. The TWT Setup Command, Trigger, Last Broadcast Parameter Set, and Flow Type subfields are used in the same way when indicating a conventional Broadcast TWT SP and when indicating an R-TWT SP for a Co-RTWT SP, so further explanation is omitted. The Broadcast TWT Recommendation subfield is a subfield that indicates the constraints applied during the time corresponding to the Broadcast TWT SP indicated by the TWT element. If the Broadcast TWT Recommendation subfield is indicated as 0, it means that no separate constraints are applied during the Broadcast TWT SP; if indicated as 1, the AP does not transmit trigger frames containing RA-RU (Random access Resource Unit) during the Broadcast TWT SP; and if indicated as 2, the AP can transmit trigger frames containing RA-RU during the Broadcast TWT SP.If the Broadcast TWT Recommendation subfield is set to 3, the AP transmits a TIM frame or a FILS discovery frame containing a TIM element at the start of each Broadcast TWT SP. The Broadcast TWT Recommendation subfield of the TWT element for an R-TWT SP is set to 4; the value 4 signifies that the corresponding Broadcast TWT is an R-TWT SP and that only the transmission of low-latency traffic is permitted. The AP sets the Broadcast TWT Recommendation subfield of the R-TWT SP corresponding to the Co-RTWT SP to 4. The TWT Wake Interval Exponent field is set to the exponent value (binary) of the TWT Wake Interval in milliseconds. The Aligned subfield indicates whether a Broadcast TWT SP aligned with the Broadcast TWT SP indicated by the TWT element has been scheduled on other links of the AP MLD (Multi-Link Device) to which the AP belongs. In the TWT element of the R-TWT SP for the Co-RTWT SP, the Aligned subfield is set to 0.

[0454] Referring to Fig. 19(c), the Broadcast TWT Info subfield includes the Restricted TWT Traffic Info Present, Restricted TWT Schedule Info, Broadcast TWT ID, and Broadcast TWT Persistence subfields. The Restricted TWT Traffic Info Present subfield indicates whether the Restricted TWT Traffic Info field is included in the Broadcast TWT Parameter Set field containing the corresponding subfield. The Restricted TWT Traffic Info field is not included in the Broadcast TWT Parameter Set field of the R-TWT SP for the Co-RTWT SP. The Restricted TWT Schedule Info subfield is a subfield that indicates the status of the R-TWT SP indicated through the TWT element and the information of the AP that scheduled the R-TWT SP. A detailed explanation of the setting value of the Restricted TWT Schedule Info subfield is provided by the table included in Fig. 19 (Table for Restricted TWT Schedule Info subfield and Description). In summary, the Co-RTWT coordinating AP sets the Restricted TWT Schedule Info subfield of the R-TWT SP for the Co-RTWT SP to 3. The Broadcast TWT ID subfield is a subfield that indicates the Broadcast TWT ID assigned to the TWT SP indicated by the TWT element. The Co-RTWT coordinating AP sets the Broadcast TWT ID of the R-TWT SP for the Co-RTWT SP to 31.The Broadcast TWT ID value 31 is not a unique ID used to distinguish each Broadcast TWT, but is a value commonly used for one or more Broadcast TWT SPs scheduled by other APs of Multiple BSSID and co-hosted BSSID, and for R-TWT SPs of other APs that have performed Co-RTWT consultation.

[0455] The Broadcast TWT Persistence subfield included in the Broadcast TWT Info subfield indicates how many TBTTs the Broadcast TWT indicated by the TWT element is maintained (Active, Present, existence) for. For example, if a Broadcast TWT SP is maintained over 100 Beacon Intervals, the Broadcast TWT Persistence subfield is set to a value representing 100 TBTTs. Specifically, the value indicated by the Broadcast TWT Persistence subfield is the number of Beacon Intervals (or TBTTs) included in the time the Broadcast TWT SP is maintained minus 1; therefore, if the value of the Broadcast TWT Persistence subfield transmitted by the AP is x, it is indicated to non-AP STAs that the Broadcast TWT SP is maintained until x+1 Beacon Intervals have elapsed (i.e., until x+1 TBTTs have passed). The maximum number of TBTTs (number of Beacon Intervals) that can be indicated through the Broadcast TWT Persistence subfield is 255 (i.e., the Broadcast TWT Persistence subfield is set to 254), and a value of 255 for the Broadcast TWT Persistence subfield is indicated for a Broadcast TWT SP with a retention length not specified in advance. A Broadcast TWT SP with a value of 255 for the Broadcast TWT Persistence subfield is retained until an explicit release instruction is performed from the AP.

[0456] The Co-RTWT coordinating AP indicates the number of TBTTs of its BSS that appear (or persist) while the Co-RTWT SP is maintained through the Broadcast TWT Persistence subfield of the R-TWT SP for the Co-RTWT SP. For example, if the Co-RTWT SP is to be maintained until the TBTTs of the BSS operated by the Co-RTWT coordinating AP appear 10 times in the future, the AP transmitting the TWT element of the R-TWT SP for the Co-RTWT SP sets the value of the Broadcast Persistence subfield to a value (e.g., 9) that signifies 10 TBTTs. At this time, the meaning that the Co-RTWT SP is maintained until 10 TBTTs appear is that Co-RTWT SPs appear until after the point corresponding to the 9th TBTT, and the Co-RTWT SP ends before the point corresponding to the 10th TBTT arrives (i.e., Co-RTWT SPs no longer appear after the point corresponding to the 10th TBTT).

[0457] Therefore, if the Beacon Intervals of the Co-RTWT Coordinating AP and the Co-RTWT mediated AP are different, the value of the Broadcast TWT Persistence subfield indicated by each AP in response to the Co-RTWT SP is set to a different value. This is because the value of the Broadcast TWT Persistence subfield transmitted by the Co-RTWT Coordinating AP regarding the R-TWT schedule subject to negotiation is set based on the Beacon Interval of the BSS operated by the Co-RTWT Coordinating AP, and the Broadcast TWT Persistence subfield transmitted by the Co-RTWT mediated AP indicating the R-TWT SP for the Co-RTWT SP is set based on the Beacon Interval of the BSS operated by the Co-RTWT mediated AP. At this time, the Broadcast TWT Persistence subfield transmitted by the Co-RTWT coordinating AP is the Broadcast TWT Persistence subfield of the MAPC request Parameter Set field transmitted by the Co-RTWT coordinating AP to the Co-RTWT coordinating AP, and the Broadcast TWT Persistence subfield transmitted by the Co-RTWT coordinating AP is the Broadcast TWT Persistence subfield that the Co-RTWT coordinating AP includes in its own beacon frame and transmits to protect the R-TWT SP of the Co-RTWT coordinating AP.

[0458] For example, if the Beacon Interval of the Co-RTWT Coordinating AP is twice as long as the Beacon Interval of the Co-RTWT Coordinating AP, the value of the Broadcast TWT Persistence subfield transmitted by the Co-RTWT Coordinating AP is approximately twice as large as the value of the Broadcast TWT Persistence subfield transmitted by the Co-RTWT Coordinating AP. As a specific example, a Co-RTWT Coordinating AP with a Beacon Interval of 200 ms can set the Broadcast TWT Persistence subfield to 99, thereby indicating the duration of the R-TWT SP corresponding to that subfield as 200 ms * (99+1), i.e., 200 seconds. In this case, a Co-RTWT Coordinating AP with a Beacon Interval of 100 ms must set the Broadcast TWT Persistence subfield to 199 to indicate the duration corresponding to 200 seconds. In this case, the Broadcast TWT Persistence subfield set to 199 transmitted by the Co-RTWT coordinating AP indicates 100 ms * (199+1) = 200 seconds, which is the same duration as the duration indicated by the Broadcast TWT Persistence subfield set to 99 transmitted by the Co-RTWT coordinating AP.

[0459] Meanwhile, it may be impossible for a Co-RTWT coordinating AP to indicate a value specified through the Broadcast TWT Persistence subfield transmitted by the Co-RTWT coordinating AP via the Broadcast TWT Persistence subfield it transmits. This is because the maximum duration of the Broadcast TWT SP that can be indicated via the Broadcast TWT Persistence subfield is limited to 255 times the Beacon Interval of the BSS operated by the AP transmitting the subfield. In other words, if the duration of the R-TWT schedule specified by the Co-RTWT coordinating AP is longer than 255 times the Beacon Interval of the BSS operated by the Co-RTWT coordinating AP, the Co-RTWT coordinating AP cannot set the Broadcast TWT Persistence subfield to a value corresponding to the duration of the R-TWT scheduled specified by the Co-RTWT coordinating AP. As a specific example, if a Co-RTWT mediated AP with a Beacon Interval of 200 ms transmits with the Broadcast TWT Persistence subfield set to 199, the duration of the R-TWT SP indicated through that subfield is 200 ms * (199+1), which is 400 seconds. However, if the Beacon Interval of the Co-RTWT mediated AP is 100 ms, the Co-RTWT mediated AP cannot indicate a duration of 400 seconds through the Broadcast TWT Persistence subfield it transmits. This is because the maximum duration that a Co-RTWT mediated AP with a Beacon Interval of 100 ms can indicate through the Broadcast TWT Persistence subfield is limited to 100 ms * 255(254+1), which is approximately 25.5 seconds.

[0460] According to one embodiment of the present invention, when the value of the Broadcast TWT Persistence subfield received from the Co-RTWT Coordinating AP is 255 times (or 254 times) or more than the Beacon Interval of the BSS operated by itself, the Co-RTWT Coordinating AP may set the value of the Broadcast TWT Persistence subfield it transmits to 254 in order to protect the Co-RTWT SP.

[0461] That is, as explained above, if the BI, which is the interval at which the beacon frame of the R-TWT SP scheduled by the coordinating AP is transmitted, is 1000 ms, and the value of the broadcast TWT persistence subfield of the frame transmitted by the coordinating AP to the coordinated AP is 5 (i.e., if the number of remaining TBTTs in the interval where the R-TWT SP appears (or persists) is 5), the coordinated AP can set the value of the broadcast TWT persistence subfield included in the management frame (e.g., beacon frame) to 50 based on its own BI. That is, the coordinated AP can set the value of the broadcast TWT persistence subfield to a value set based on its own BI, which is the number of remaining TBTTs in the interval where the R-TWT SP scheduled by the coordinating AP appears (or persists). At this time, if the BI of the adjusting AP is greater than the BI of the adjusted AP, the number of remaining TBTTs of the adjusting AP may exceed the number of broadcast TWT persistence subfields when converting based on its own BI, and in this case, a problem arises with setting the value of the broadcast TWT persistence subfield set by the adjusted AP.

[0462] In this case, if the BI of the R-TWT SP (Co-RTWT) scheduled by the coordinating AP is greater than the BI of the mediated AP (the BI of the Co-RTWT), and the number of TBTTs of the mediated AP based on the number of TBTTs in the interval where the R-TWT SP scheduled by the coordinating AP exists is greater than the maximum value that can be indicated by the broadcast TWT persistence subfield, the mediated AP may set the value of the broadcast TWT persistence subfield to a specific value and transmit it. Subsequently, if the number of TBTTs of the mediated AP based on the number of TBTTs in the interval where the R-TWT SP scheduled by the coordinating AP exists becomes smaller than the maximum value that can be indicated by the broadcast TWT persistence subfield, the mediated AP may start decreasing the value of the broadcast TWT persistence subfield.

[0463] In other words, the BI of the coordinating AP can be set longer than the beacon period of the coordinated AP. In this case, due to the limitations of the range of values ​​that the broadcast TWT persistence field can represent (e.g., 0 to 254), the coordinated AP may be unable to accurately indicate the number of its remaining TBTTs through said field until the R-TWT schedule ends. To overcome this limitation, if the number of remaining TBTTs of the coordinated AP exceeds 254 until the end of the R-TWT schedule, the coordinated AP may set the value of the broadcast TWT persistence field to a specific indicator value of 255 and transmit it. The value of 255 can be used to indicate that the number of remaining TBTTs exceeds the representation range of said field. Subsequently, the controlled AP may transmit by decreasing the value of the broadcast TWT duration field according to the calculated number, starting from the point when the time remaining until the end of the above R-TWT schedule through continuous monitoring falls within 254 times based on the beacon cycle of the controlled AP (i.e., the point when the number of remaining TBTTs is calculated to be 254 or less).

[0464] In other words, the Broadcast TWT Persistence subfield transmitted by the Co-RTWT harmonizing AP to protect the Co-RTWT SP can be set to 254 to mean 255 Beacon Intervals (TBTTs), or it can mean Beacon Intervals (TBTTs) exceeding 255. The method for setting and interpreting the Broadcast TWT Persistence subfield transmitted by the Co-RTWT harmonizing AP to protect the Co-RTWT SP is briefly summarized as follows.

[0465] - Broadcast TWT Persistence subfield value (0 to 253): Broadcast TWT SP (R-TWT SP corresponding to Co-RTWT SP) is valid for a Beacon Interval (number of TBTTs) corresponding to Broadcast TWT Persistence subfield value + 1.

[0466] - Broadcast TWT Persistence subfield value (254): Broadcast TWT SP (R-TWT SP corresponding to Co-RTWT SP) is valid for 254 or more Beacon Intervals (number of TBTTs).

[0467] - Broadcast TWT Persistence subfield value (255): The Broadcast TWT SP (R-TWT SP corresponding to the Co-RTWT SP) remains valid until an explicit release instruction is given.

[0468] The Co-RTWT mediated AP must set the duration for which the R-TWT SP configured to protect the Co-RTWT SP is maintained based on the remaining duration of the Co-RTWT SP from the time it transmits the Broadcast TWT Persistence subfield for the said R-TWT SP. Accordingly, the value of the Broadcast TWT Persistence subfield for the Co-RTWT SP transmitted by the Co-RTWT mediated AP through each beacon frame (more precisely, the R-TWT indicated through its own beacon frame for the protection of the Co-RTWT SP) gradually decreases. Additionally, regarding the duration of the Co-RTWT SP indicated by the Broadcast TWT Persistence subfield being set to 254, if the remaining duration decreases to 254 times (or 253 times) the Co-RTWT mediated AP's Beacon Interval or less, the number of remaining TBTTs is directly indicated through the Broadcast TWT Persistence subfield.

[0469] FIG. 20 is a flowchart illustrating an example of the operation of a controlled AP according to an embodiment of the present invention.

[0470] Referring to FIG. 20, the first AP, which is the coordinated AP, can receive a management frame related to an R-TWT SP (restricted target wake time service period) scheduled by the second AP, which is the coordinated AP, for Co-RTWT (coordinated restricted target wake time) operation (S20010).

[0471] The management frame includes a Multi-AP coordination (MAPC) element that includes a first parameter field for indicating parameters for the R-TWT SP, and the first parameter field may include a first Broadcast Target Wake Time Persistence field that indicates the interval during which the R-TWT SP appears (or persists) as the number of the first TBTT (Target beacon transmission Time) of the second AP.

[0472] Subsequently, the first AP can transmit a beacon frame based on a management frame (S20020), and the beacon frame may include a second parameter field related to the R-TWT SP scheduled by the second AP.

[0473] The second parameter field may include a second broadcast TWT duration field that indicates the interval during which an R-TWT SP scheduled by the second AP appears (or persists) as the number of the second TBTT of the first AP, and the value of the second broadcast TWT duration field may be set to the number of the second TBTT based on the number of the first TBTT.

[0474] i) If the beacon interval, which is the period during which the beacon frame of the second AP is transmitted, is greater than the beacon interval of the first AP, and ii) if the number of the second TBTT based on the number of the first TBTT exceeds the maximum value of the number of TBTT that can be indicated by the second broadcast TWT persistence field, the value of the second broadcast TWT persistence field may be set to a specific value.

[0475] When the value of the second broadcast TWT persistence field is set to a specific value and the number of second TBTTs falls below the maximum value, the first AP may decrease the value of the broadcast TWT persistence field included in the beacon frame. At this time, the maximum value may be '254'.

[0476] The first AP may receive a request frame for MAPC from the second AP, and the request frame may include a MAPC function field indicating at least one scheme supported by the second AP for MAPC and a MAPC parameter field indicating one or more schemes for which the second AP intends to perform negotiation. Subsequently, the first AP may transmit a response frame for the request frame.

[0477] i) at least one method and ii) one or more methods of a request frame transmitted from the second AP may be at least one of Coordinated Beamforming (Co-BF), Coordinated Spatial Reuse (Co-SR), Coordinated Time Division Multiple Access (Co-TDMA), and Coordinated Restricted Target Wake Time (Co-RTWT).

[0478] The MAPC parameter field includes one or more Agreement Establishment Enabled fields that correspond individually to each of the one or more methods, and the value of the field corresponding to the method to be negotiated among the one or more Agreement Establishment Enabled fields can be set to '1'.

[0479] The first AP and the second AP can perform negotiations on all or part of the one or more methods based on the above MAPC parameter fields.

[0480] The MAPC element may further include instruction information indicating that the R-TWT SP is an R-TWT SP scheduled by the second AP.

[0481] In addition, the maximum number of first TBTTs that can be indicated by the first broadcast TWT persistence field is '254'.

[0482]

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

[0484]

[0485] The scope of the present invention is defined by the claims set forth below rather than by the detailed description above, and all modifications or variations derived from the meaning and scope of the claims and equivalent concepts thereof should be interpreted as being included within the scope of the present invention.

Claims

1. As the first AP (access point), Transmitter / receiver; and Includes a processor, The above processor is, To operate Co-RTWT (coordinated restricted target wake time), receive a management frame related to the R-TWT SP (restricted target wake time service period) scheduled by the second AP, The above management frame includes a Multi-AP coordination (MAPC) element comprising a first parameter field for indicating parameters for the R-TWT SP, and The first parameter field above includes a first broadcast TWT persistence field (Broadcast Target Wake Time Persistence field) that indicates the duration of the R-TWT SP as the number of first TBTT (Target beacon transmission Time) of the second AP, and Transmit a beacon frame based on the above management frame, The above beacon frame includes a second parameter field associated with the R-TWT SP scheduled by the above second AP, and The second parameter field above includes a second broadcast TWT duration field that indicates the duration of the R-TWT SP as the number of the second TBTT of the first AP, and The value of the second broadcast TWT persistence field is set to the number of the second TBTT based on the number of the first TBTT, and A first AP in which, if the beacon interval, which is the period during which the beacon frame of the second AP is transmitted, is greater than the beacon interval of the first AP, and the number of the second TBTT based on the number of the first TBTT exceeds the maximum value of the number of TBTT that can be indicated by the second broadcast TWT persistence field, the value of the second broadcast TWT persistence field is set to a specific value.

2. In Paragraph 1, When the value of the second broadcast TWT persistence field is set to the specific value and the number of the second TBTTs falls below the maximum value, the first AP reduces the value of the broadcast TWT persistence field included in the beacon frame.

3. In Paragraph 1, The first AP, with the above maximum value being '254'.

4. In claim 1, the processor, Receive a request frame for MAPC from the above second AP, The above request frame includes a MAPC function field indicating at least one scheme supported by the second AP for the MAPC and a MAPC parameter field indicating one or more schemes for which the second AP intends to perform negotiation, and A first AP that transmits a response frame for the above request frame.

5. In Paragraph 4, i) at least one method and ii) a first AP in which the one or more methods are at least one of Coordinated Beamforming (Co-BF), Coordinated Spatial Reuse (Co-SR), Coordinated Time Division Multiple Access (Co-TDMA), and Coordinated Restricted Target Wake Time (Co-RTWT).

6. In Paragraph 4, The above MAPC parameter field includes one or more Agreement Establishment Enabled fields that correspond individually to each of the one or more methods, and A first AP in which the value of the field corresponding to the method of performing negotiation among the above one or more agreement-configurable fields is set to '1'.

7. In Paragraph 4, The first AP and the second AP are a first AP that performs negotiation on all or part of the one or more methods based on the MAPC parameter field.

8. In Paragraph 1, The above MAPC element further includes a first AP comprising instruction information indicating that the R-TWT SP is the R-TWT SP scheduled by the second AP.

9. In Paragraph 1, The first AP, in which the maximum number of the first TBTTs that can be indicated by the first broadcast TWT persistence field is '254'.

10. In a method performed by the first AP (access point), the method comprises: A step of receiving a management frame associated with an R-TWT SP (restricted target wake time service period) scheduled by the second AP for Co-RTWT (coordinated restricted target wake time) operation, The above management frame includes a Multi-AP coordination (MAPC) element comprising a first parameter field for indicating parameters for the R-TWT SP, and The first parameter field above includes a first broadcast TWT persistence field (Broadcast Target Wake Time Persistence field) that indicates the duration of the R-TWT SP as the number of the first TBTT (Target beacon transmission Time) of the second AP; and The method includes the step of transmitting a beacon frame based on the above management frame, The above beacon frame includes a second parameter field associated with the R-TWT SP scheduled by the above second AP, and The second parameter field above includes a second broadcast TWT duration field that indicates the duration of the R-TWT SP as the number of the second TBTT of the first AP, and The value of the second broadcast TWT persistence field is set to the number of the second TBTT based on the number of the first TBTT, and A method in which, when the beacon interval, which is the period during which the beacon frame of the second AP is transmitted, is greater than the beacon interval of the first AP, and the number of the second TBTT based on the number of the first TBTT exceeds the maximum value of the number of TBTTs that can be indicated by the second broadcast TWT persistence field, the value of the second broadcast TWT persistence field is set to a specific value.

11. In Paragraph 10, A method in which, when the value of the second broadcast TWT persistence field is set to the specific value and the number of the second TBTTs falls below the maximum value, the first AP reduces the value of the broadcast TWT persistence field included in the beacon frame.

12. In Paragraph 10, The method where the maximum value above is '254'.

13. In claim 10, the above method is, The step of receiving a request frame for MAPC from the second AP, The above request frame includes a MAPC function field indicating at least one scheme supported by the second AP for the MAPC and a MAPC parameter field indicating one or more schemes for which the second AP intends to perform negotiation; and A method further comprising the step of transmitting a response frame for the above request frame.

14. In Paragraph 13, i) at least one method and ii) at least one method of which is one of Coordinated Beamforming (Co-BF), Coordinated Spatial Reuse (Co-SR), Coordinated Time Division Multiple Access (Co-TDMA), and Coordinated Restricted Target Wake Time (Co-RTWT).

15. In Paragraph 13, The above MAPC parameter field includes one or more Agreement Establishment Enabled fields that correspond individually to each of the one or more methods, and A method in which the value of the field corresponding to the method of performing negotiation among the above one or more agreement-configurable fields is set to '1'.

16. In Paragraph 13, A method in which the first AP and the second AP perform negotiation on all or part of the one or more methods based on the MAPC parameter field.

17. In Paragraph 10, A method in which the above MAPC element further includes instruction information indicating that the above R-TWT SP is the R-TWT SP scheduled by the second AP.

18. In Paragraph 10, A method in which the maximum number of the first TBTTs that can be indicated by the first broadcast TWT persistence field is '254'.

Images