Wireless communication method using coordination between aps, and wireless communication terminal using same

Abstract

Disclosed is a second access point (AP) that coordinates an operation with a first AP. The second AP includes a transmission and reception unit and a processor. The processor receives, from the first AP, a request frame indicating a coordination request for a multi-AP coordination (MAPC) scheme, and when a response frame accepting the coordination request for the MAPC scheme is transmitted in response to the request frame, carries out an operation according to the coordination request.

Description

Wireless communication method utilizing cooperation between APs and a wireless communication terminal using the same

[0001] The present invention relates to a wireless communication method that supports cooperation between APs and a wireless communication terminal using the same.

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

[0003] 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 to up to 54Mbps using OFDM 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.

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

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

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

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

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

[0009] One embodiment of the present invention aims to provide a wireless communication method utilizing cooperation between APs and a wireless communication terminal using the same.

[0010] According to one embodiment of the present invention, a second access point (AP) that coordinates operations with a first AP includes a transceiver; and a processor. The processor receives a request frame from the first AP instructing a coordination request for a multi-AP coordination (MAPC) scheme, and when it transmits a response frame accepting the coordination request for the MAPC scheme in response to the request frame, it performs an operation according to the coordination request.

[0011] When the MAPC scheme is R-TWT (restricted-target wake time), the processor may set a second R-TWT in the BSS operated by the second AP according to the schedule of the first R-TWT of the first AP, and may not allow transmission in the second R-TWT.

[0012] The processor can set the value of all bits of a bitmap indicating low-latency traffic that is allowed to be transmitted to the second R-TWT to 0.

[0013] The processor can set a quiet interval that overlaps with the second R-TWT schedule.

[0014] The processor can set a quiet interval that overlaps with the second R-TWT schedule when the first AP sets a quiet interval that overlaps with the first R-TWT schedule.

[0015] When the second AP transmits a response frame to the request frame that directs the rejection of the coordination request for the MAPC scheme, the response frame may indicate the reason for the rejection of the coordination request for the MAPC scheme.

[0016] The request for coordination regarding the above MAPC scheme is a request for R-TWT (restricted-target wake time), and the reason for the rejection is that the schedule of the R-TWT indicated by the above MAPC scheme and the R-TWT schedule of the above second AP may overlap.

[0017] According to an embodiment of the present invention, a first access point (AP) that coordinates operations with a second AP includes a transceiver; and a processor. The processor transmits a request frame instructing the second AP to request coordination for a multi-AP coordination (MAPC) scheme, and receives a response frame which is a response to the request frame.

[0018] When the above MAPC scheme is R-TWT (restricted-target wake time), the second AP sets a second R-TWT in the BSS operated by the second AP according to the schedule of the first R-TWT of the first AP, and may not set low-latency traffic that is allowed to be transmitted in the second R-TWT.

[0019] The processor may request the second AP to set a quiet interval that overlaps with the first R-TWT schedule.

[0020] When the first AP sets a quiet interval that overlaps with the first R-TWT schedule, the processor may request the second AP to set a quiet interval that overlaps with the first R-TWT schedule.

[0021] The processor receives a response frame for the request frame from the second AP that indicates a rejection of the coordination request for the MAPC scheme, and the response frame may indicate the reason for the rejection of the coordination request for the MAPC scheme.

[0022] The request for coordination regarding the above MAPC scheme is a request for R-TWT (restricted-target wake time), and the reason for the rejection is that the schedule of the R-TWT indicated by the above MAPC scheme and the R-TWT schedule of the above second AP may overlap.

[0023] According to an embodiment of the present invention, a method of operation of a second access point (AP) coordinating operations with a first AP comprises: receiving a request frame from the first AP instructing a coordination request for a multi-AP coordination (MAPC) scheme; and, when a response frame accepting the coordination request for the MAPC scheme is transmitted in response to the request frame, performing an operation according to the coordination request.

[0024] The step of performing an operation in accordance with the above adjustment request may include, when the MAPC scheme is R-TWT (restricted-target wake time), the step of setting a second R-TWT in the BSS operated by the second AP according to the schedule of the first R-TWT of the first AP.

[0025] The step of setting the second R-TWT may include a step of not allowing transmission in the second R-TWT.

[0026] The step of not allowing transmission in the second R-TWT above may include the step of setting the value of all bits of a bitmap indicating low-latency traffic that is allowed to be transmitted in the second R-TWT to 0.

[0027] The step of performing an operation in accordance with the above adjustment request may include the step of setting a quiet interval that overlaps with the second R-TWT schedule.

[0028] The step of setting a quiet interval that overlaps with the second R-TWT schedule may include the step of setting a quiet interval that overlaps with the second R-TWT schedule when the first AP sets a quiet interval that overlaps with the first R-TWT schedule.

[0029] The above method of operation may further include the step of, when the second AP transmits a response frame to the request frame instructing the rejection of the coordination request for the MAPC scheme, the response frame instructing the reason for the rejection of the coordination request for the MAPC scheme.

[0030] According to an embodiment of the present invention, a method of operation of a first access point (AP) coordinating operation with a second AP comprises the steps of: transmitting a request frame instructing the second AP to request coordination for a multi-AP coordination (MAPC) scheme; and receiving a response frame which is a response to the request frame.

[0031] One embodiment of the present invention provides a wireless communication method that efficiently supports cooperation between APs and a wireless communication terminal using the same.

[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 the individual TWT operation of the AP and the station according to an embodiment of the present invention.

[0043] FIG. 12 shows a broadcast TWT operation between an AP and a plurality of stations according to an embodiment of the present invention.

[0044] FIG. 13 shows the format of a TWT element according to an embodiment of the present invention.

[0045] FIG. 14 shows the R-TWT operation between an AP and a plurality of stations according to an embodiment of the present invention.

[0046] FIG. 15 shows the format of a TWT element indicating information regarding an R-TWT according to an embodiment of the present invention.

[0047] Figure 16 shows that interference occurs in frame exchange within the R-TWT due to OBSS.

[0048] FIG. 17 shows the R-TWT protection operation between coordinated APs according to an embodiment of the present invention after Co-RTWT consultation.

[0049] FIG. 18 shows a Co-RTWT negotiation process according to an embodiment of the present invention.

[0050] FIG. 19 shows a method for a Co-RTWT coordinated AP to transmit information regarding Co-RTWT when the Co-RTWT service period prior to TBTT of the Co-RTWT coordinated AP begins after Co-RTWT consultation according to an embodiment of the present invention.

[0051] FIG. 20 shows an operation in which a Co-RTWT request AP instructs a Co-RTWT response AP to a Co-RTWT service period end event according to an embodiment of the present invention.

[0052] FIG. 21 shows the multi-link operation of a multi-link device (MLD) according to an embodiment of the present invention.

[0053] FIG. 22 shows a Co-RTWT consultation between a Co-RTWT request AP MLD and a Co-RTWT response AP MLD according to an embodiment of the present invention.

[0054] FIG. 23 shows the format of elements exchanged in a Co-RTWT consultation according to an embodiment of the present invention.

[0055] FIG. 24 shows a MAPC framework according to an embodiment of the present invention.

[0056] FIG. 25 shows the format of a MAPC element and the format of a field included in the element format according to an embodiment of the present invention.

[0057] FIG. 26 shows the format of a MAPC discovery request / response frame and a MAPC consultation request / response frame according to an embodiment of the present invention.

[0058] FIG. 27 shows the operation of the MAPC response AP when the MAPC response AP proposes an alternative during the Co-RTWT consultation process according to an embodiment of the present invention.

[0059] FIG. 28 shows that in the frame exchange between the MAPC request AP and the MAPC response AP in the MAPC consultation procedure according to an embodiment of the present invention, the MAPC response AP indicates the reason for rejection of the MAPC consultation request.

[0060] FIG. 29 shows the MAPC Request Control format of a MAPC element according to an embodiment of the present invention.

[0061] Figure 30 shows the format of the Per-Scheme Profile subelement of the MAPC discovery request / response frame.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0090] <Examples of Various PPDU Formats>

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

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

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

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

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

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

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

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

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

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

[0101]

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

[0103]

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

[0105]

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

[0107] 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 largely divided into the VI (Version Independent) field and the VD (Version Dependent) field.

[0108] 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 when a subsequent generation of PPDUs is 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 non-000b value. 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.

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

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

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

[0112]

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

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

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

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

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

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

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

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

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

[0122]

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

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

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

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

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

[0128]

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

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

[0131]

[0132] <EDCA와 TXOP>

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

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

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

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

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

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

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

[0140]

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

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

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

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

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

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

[0147]

[0148] 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 to notify other terminals so that they can recognize the acquired TXOP segment may be necessary.

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

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

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

[0152]

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

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

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

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

[0157]

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

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

[0160]

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

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

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

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

[0165]

[0166] <Target Wake Time>

[0167] TWT is one of the power saving operations defined in the 802.11 wireless LAN standard, in which a station performs power saving operations by switching between a doze state and an awake state. In TWT, the station enters the awake state during the service period (SP) to exchange frames with the AP. The station may enter the doze state outside of the service period. A station can perform TWT operations through negotiation with the AP. TWTs can include individual TWTs and broadcast TWTs. A station intending to perform a broadcast TWT operation must negotiate with the AP. If an agreement is reached, the AP can set the station as a member of the broadcast TWT. A station intending to perform an individual TWT operation can send a TWT setup request frame to the AP. The TWT setup frame includes an action frame and TWT elements. A TWT element may include at least one of the start time of the next service period, the interval between service periods, the duration of the service period, or a TWT Setup Command field. The TWT Setup Command field may indicate that the frame containing the TWT Setup Command field is for a request, a suggestion, or a demand. An AP that receives a TWT setup frame may accept the TWT, make an alternative request, or reject the request. An AP may have one or more TWT agreements. Each of the multiple TWT agreements may be a TWT agreement established between the AP and multiple different stations. Additionally, the TWT service periods of multiple TWT agreements operated by the AP may overlap.

[0168] FIG. 11 shows the individual TWT operation of the AP and the station according to an embodiment of the present invention.

[0169] In the embodiment of FIG. 11, the first station (STA 1) and the AP are connected. The first station (STA 1) transmits a TWT setup request frame to the AP to establish an individual TWT agreement. The first station (STA 1) may specify parameters for the TWT agreement to be established. At this time, the parameters for the TWT agreement may include at least one of trigger-enabled information, the start time of the next TWT service period, the interval of the service period, or the duration of the service period. The AP transmits a TWT setup response frame instructing acceptance of the TWT agreement request from the first station (STA 1). The first station (STA 1) may remain in a sleep state before the TWT service period. During the service period, the AP transmits a trigger frame to the first station (STA 1) after successfully completing the channel access procedure. The first station remains active at the start of the service period and receives the trigger frame from the AP. The first station (STA 1) transmits a PS-Poll frame in response to the trigger frame. The PS-Poll frame indicates that the first station (STA 1) is active. Upon receiving the PS-Poll frame, the AP performs frame exchange with the first station (STA 1). After the TWT service period, the first station (STA 1) can enter a power-saving state.

[0170]

[0171] In a broadcast TWT, multiple stations may operate according to a single TWT schedule. Additionally, each of the multiple TWT schedules may have an identifier (ID) that identifies them. The AP may include a TWT element in the beacon frame that indicates information regarding the broadcast TWT. If a station that receives the beacon frame wishes to participate in the broadcast TWT, the station may request participation by sending a TWT setup request frame to the AP. The TWT setup request frame may include the identifier of the broadcast TWT that the station wishes to join. The AP may accept this, request an alternative, or reject the request. The station may negotiate the next beacon interval during the TWT negotiation. Specifically, if the beacon requires reception by the station, the station may negotiate the next beacon interval during the TWT negotiation. In this case, the beacon requiring reception by the station may include a beacon indicating that the broadcast TWT information has changed. In this specification, the request frame and the response frame may be frames of the same format. In this case, the information indicated by the frame in the request frame may indicate a request, and the information indicated by the frame in the response frame may indicate a response. The TWT setup request frame and the TWT setup response frame may use the same frame format, the TWT setup frame, and may be distinguished as the TWT setup request frame and the TWT setup response frame depending on the values ​​of the fields included. Specifically, if the value of the TWT Request field in the TWT setup frame is 1, the value of the Negotiation Type field is 0, 1, or 3, and the value of the TWT Setup Command field is 0, 1, or 2, the TWT setup frame may be a TWT setup request frame.In addition, if the TWT setup frame has a value of 0 in the TWT Request field, a value of 0, 1, or 3 in the Negotiation Type field, and a value of 4, 5, or 6 in the TWT Setup Command field, the TWT setup frame may be a TWT setup response frame. In addition, if the TWT setup frame has a value of 0, 1, or 3 in the Negotiation Type field and a value of 7 in the TWT Setup Command field, the TWT setup frame may be a TWT setup response frame that indicates rejection.

[0172] A station or AP can release TWT consensus by sending a TWT teardown frame. A station can send a TWT teardown frame at any time, and an AP cannot release TWT consensus with a station that is active during the broadcast TWT service period it intends to release.

[0173] An AP can manage broadcast TWT information using the broadcast TWT identifier and the AP's MAC address. A station can determine whether the information indicated by the Broadcast TWT Parameter Set field concerns the broadcast TWT consensus to which the station belongs by using the identifier indicated by the Broadcast TWT ID subfield of the Broadcast TWT Parameter Set field of the TWT element of the beacon frame received by the station, the MAC address of the station that transmitted the beacon frame, and the TA field. The broadcast TWT service period operated by the AP can be managed by the AP, but the broadcast TWT service period operated by the OBSS cannot be managed by the AP. Therefore, if the broadcast TWT service period operated by the AP overlaps with the broadcast TWT service period operated by the OBSS, the efficiency of TWT operation may decrease.

[0174] FIG. 12 shows a broadcast TWT operation between an AP and a plurality of stations according to an embodiment of the present invention.

[0175] In the embodiment of FIG. 12, the AP operates a broadcast TWT with the second station (STA 2). At this time, the identifier of the broadcast TWT is 1. The first station (STA 1) transmits a TWT setup request frame (TWT req.) to participate in the broadcast TWT having an identifier value of 1. The AP transmits a TWT setup response frame (TWT resp.) in which the first station (STA 1) accepts participation in the broadcast TWT. The AP transmits a beacon frame containing information about the broadcast TWT. The first station (STA 1) and the second station (STA 2) switch to an active state to receive the beacon frame. The beacon frame indicates that only UL transmissions triggered by a trigger frame are allowed during the broadcast TWT service period. The AP transmits a trigger frame during the broadcast TWT service period. The first station (STA 1) and the second station (STA 2) receive a trigger frame, and the first station (STA 1) transmits a PS-Poll frame in response to the trigger frame. Additionally, the second station (STA 2) transmits a QoS Null frame in response to the trigger frame.

[0176] AP and the first station (STA 1) and the second station (STA 2) perform frame exchange during the broadcast TWT service period. When the TWT service period ends, the first station (STA 1) and the second station (STA 2) may enter a power-saving state.

[0177] FIG. 13 shows the format of a TWT element according to an embodiment of the present invention.

[0178] FIG. 13(a) shows the format of a TWT element. FIG. 13(b) shows the format of the Control field of a TWT element. FIG. 13(c) shows the format of the Individual TWT Parameter Set field of a TWT element. FIG. 13(d) shows the format of the Request Type subfield of the Individual TWT Parameter Set field of a TWT element. FIG. 13(e) shows the format of the Broadcast TWT Parameter Set field of a TWT. FIG. 13(f) shows the format of the Request Type subfield of the Broadcast TWT Parameter Set field of a TWT element. FIG. 13(g) shows the format of the Broadcast TWT Info subfield of the Broadcast TWT Parameter Set field of a TWT element.

[0179] The TWT element indicates TWT-related information. Specifically, the TWT element may indicate information regarding the parameters of a TWT session. It can be used for TWT consultation between an AP and a station. The TWT element may include a one-octet Element ID field, a one-octet Length field, a one-octet Control field, and a TWT Parameter Information field. The Element ID field is 216, which is the identifier of the TWT element. The Control field indicates specific information indicated by the TWT element. For example, the Control field may include information for requesting TWT configuration or setting the unit of time for TWT configuration. The parameters included in the Control field may be determined based on the Negotiation Type subfield of the Control field. Specifically, the Control field may include either an Individual TWT Parameter Set field or a Broadcast TWT Parameter Set field.

[0180] The Control field indicates specific information indicated by the TWT element. The Control field may include a 1-bit NDP Paging Indicator / Unavailability Mode subfield, a 1-bit Responder PM Mode subfield, a 2-bit Negotiation Type subfield, a 1-bit TWT Information Frame Disabled subfield, a 1-bit Wake Duration Unit subfield, and a 2-bit Reserved subfield. The NDP Paging Indicator / Unavailability Mode subfield may indicate that the TWT Parameter Information field includes the NDP Paging field when the TWT element is transmitted to a station operating in the sub-1 GHz band. The Responder PM Mode subfield may indicate whether the station's power saving mode is enabled. The Negotiation Type subfield may indicate whether the TWT information contained in the corresponding TWT element is a broadcast TWT, an individual TWT, or a negotiation regarding parameters for the Wake TBTT period. The TWT Information Frame Disabled subfield indicates whether the TWT information frame can be received at the station receiving the TWT element. The Wake Duration Unit subfield may indicate the time unit of the Nominal Minimum TWT Wake Duration subfield of the TWT Parameter Information field. The Wake Duration Unit subfield may indicate 256 µs or 1 TU (Time Unit, 1024 µs).

[0181] The Individual TWT Parameter Set field indicates the information required for Individual TWT configuration. The Individual TWT Parameter Set field may include a 2-octet Request Type field, a 0 or 9-octet Target Wake Time field, a 0, 3, or 9-octet TWT Group Assignment field, a 1-octet Nominal Minimum TWT Wake Duration field, a 2-octet TWT Wake Interval Mantissa field, a 1-octet TWT Channel field, and a 0 or 4-octet NDP Paging field. The Request Type field may indicate whether the TWT element requests a TWT or responds by accepting or rejecting the TWT. The information indicated by the Target Wake Time field may vary depending on the value of the Negotiation Type subfield in FIG. 13 (b). The Target Wake Time field may indicate the start time of the individual TWT service period to be initiated later in the individual TWT parameter set. The TWT Group Assignment field can specify parameters regarding the TWT group. The Nominal Minimum TWT Wake Duration field can specify the minimum time a TWT requesting station must remain awake to complete the frame exchange procedure during the duration of the TWT wake interval, using the unit specified in the Wake Duration Unit subfield. The duration of the TWT wake interval can represent the expected average interval of consecutive TWT service periods for the TWT requesting station. The TWT Wake Interval Mantissa field can be combined with the TWT Wake Interval Exponent subfield of the Request Type field to specify the duration of the TWT wake interval between TWT service periods.The duration of the TWT activation interval can be calculated using the following mathematical formula.

[0182] D TWT_Wake_Interval = (TWT Wake Interval Mantissa) x 2(TWT Wake Interval Exponent)

[0183] D TWT_Wake_Interval represents the duration of the TWT activation interval. Additionally, TWT Wake Interval Mantissa represents the value specified in the TWT Wake Interval Mantissa field. TWT Wake Interval Exponent represents the value specified by the TWT Wake Interval Exponent subfield of the Request Type field. The unit of the TWT activation interval can be specified in microseconds.

[0184] The TWT Channel field can specify the channel to be used by the station in P2P TWT or HE Subchannel Selective Transmission (SST).

[0185] The Request Type field is a field configured when requesting or responding to an individual TWT, and it can indicate operational information during the TWT service period. Specifically, the Request Type field can indicate acceptance or rejection regarding which operations to support during the TWT service period. The Request field is 16 bits in total and may include a 1-bit TWT Request subfield, a 3-bit TWT Setup Command subfield, a 1-bit Trigger subfield, a 1-bit Implicit subfield, a 1-bit Flow Type subfield, a 3-bit TWT Flow Identifier subfield, a 5-bit TWT Wake Interval Exponent subfield, and a 1-bit TWT Protection subfield. The TWT Request subfield can indicate whether a frame containing TWT elements is a TWT setup request frame or a TWT setup response frame. The TWT Setup Command subfield can indicate the type of TWT setup command. There are 8 TWT setup commands. A TWT request station can set the value of the TWT Setup Command subfield to any one of 0 to 2. In this case, 0 indicates that the TWT element requests an individual TWT, 1 indicates that the TWT element suggests a TWT, and 2 indicates that the TWT element demands a TWT. A TWT response station can set the value of the TWT Setup Command subfield to any one of 4 to 7. In this case, 4 indicates that the TWT element accepts an individual TWT, 5 indicates that the TWT element suggests an alternative, 6 indicates that the TWT element dictates a TWT, and 7 indicates that the TWT element rejects a TWT.The Trigger field indicates whether the AP will transmit one or more trigger frames during the TWT service period. If the AP transmits one or more trigger frames during the TWT service period, it may be recommended that the station perform uptransmissions based on the trigger frames during the TWT service period. The Implicit field indicates whether a method is applied where the AP sets the TWT schedule without explicit negotiation and the station follows it. The Flow Type field indicates the type of interaction between stations within the TWT. If the value of the Flow Type field is 0, the station may indicate to the AP that it is in an awake state by transmitting a PS-Poll frame or a QoS Null frame. The TWT Flow Identifier field indicates the identifier of the TWT agreement. An AP can have up to eight individual TWT agreements. The TWT Protection field indicates whether the station requests that the TWT service period be protected from the service periods of other TWTs. If the value of the TWT Protection field is 1, the AP can request NAV protection for other TWTs during the service period of the TWT.

[0186] The description of parts of the Broadcast TWT Parameter Set field format that are identical or corresponding to the format of the Individual TWT Parameter Set field is omitted. When an AP transmits the Broadcast TWT Parameter Set field, the Broadcast TWT Parameter Set field may represent information about the broadcast TWT. When a station transmits the Broadcast TWT Parameter Set field, the Broadcast TWT Parameter Set field may represent information about the broadcast TWT that the station intends to subscribe to. The Broadcast TWT Parameter Set field may include a 2-octet Request Type field, a 2-octet Target Wake Time field, a 1-octet Nominal Minimum TWT Wake Duration field, a 2-octet TWT Wake Interval Mantissa field, and a 2-octet Broadcast TWT Info field. The Broadcast TWT Info field may indicate the identifier of the broadcast TWT and the duration for which the broadcast TWT is maintained.

[0187] The description of the Request Type subfield of the Broadcast TWT Parameter Set field that corresponds to or is identical to the Individual TWT Parameter Set field is omitted. The Request Type field of the Broadcast TWT Parameter Set field may include a 1-bit TWT Request subfield, a 3-bit TWT Setup Command subfield, a 1-bit Trigger subfield, a 1-bit Last Broadcast Parameter Set subfield, a 1-bit Flow Type subfield, a 3-bit Broadcast TWT Recommendation subfield, a 5-bit TWT Wake Interval Exponent subfield, and a 1-bit Reserved subfield. The Last Broadcast Parameter Set subfield may indicate whether the corresponding field is the last broadcast TWT Parameter Set field among multiple broadcast TWT Parameter Set fields. The Broadcast TWT Recommendation subfield may indicate the conditions of the frame that the station must transmit or respond to during the service period of the broadcast TWT.

[0188] The Broadcast TWT Info subfield may include a 3-bit Reserved subfield, a 5-bit Broadcast TWT ID subfield, and an 8-bit Broadcast TWT Persistance subfield. The Broadcast TWT ID subfield may indicate the identifier of the Broadcast TWT corresponding to the Broadcast TWT Info subfield among the multiple Broadcast TWTs held by the AP. If the Broadcast TWT ID subfield is 0, the Broadcast TWT ID subfield may indicate that all stations within the BSS are included in the membership. The Broadcast TWT Persistence subfield may indicate how long the service period of the Broadcast TWT will last, and may indicate the duration of the TWT's service period in units of Beacon Interval (TBTT).

[0189]

[0190] <TWT 서비스 기간 종료>

[0191] During the TWT service period, the AP and the station may terminate the TWT service period before the end of the TWT service period. A TWT requesting station or a TWT responding station operating during an individual TWT service period may trigger a TWT service period termination event by transmitting a frame indicating the termination of the TWT service period. A TWT requesting station or a TWT responding station may determine that the termination of the TWT service period is indicated when any one of the following conditions is satisfied.

[0192] 1. If the value of the EOSP (End-Of-Service-Period) subfield in the individually addressed QoS data or QoS null frame transmitted from the TWT responding station is 1, and the TWT requesting station responds with an ack for the QoS data or QoS null frame

[0193] 2. When the value of the EOSP (End-Of-Service-Period) subfield in individually addressed QoS data or a QoS null frame transmitted from a TWT scheduling AP is 1, and the TWT scheduled station responds with an ack for the QoS data or QoS null frame

[0194] 3. An individual address frame transmitted from the TWT response station, which is not QoS data or a QoS null frame, where the value of the frame's More Data field is 0, and the TWT requesting station responds to the frame with an ack

[0195] 4. An individual address frame transmitted from a TWT scheduling AP, which is not QoS data or a QoS null frame, where the value of the frame's More Data field is 0, and the TWT scheduled station responds to the frame with an ack.

[0196] 5. When a QoS data or QoS Null frame is received from a TWT response station or TWT scheduling AP that is set not to receive an immediate response, and the value of the EOSP subfield is 1. In this case, the QoS data or QoS Null frame may be an individual address or a broadcast.

[0197] 6. When set not to receive immediate response from the TWT response station or TWT scheduling AP, and a frame other than QoS data or a QoS Null frame with an EOSP subfield value of 1 is received

[0198] 7. If a TWT responding station or TWT scheduling AP receives a trigger frame in which the value of the More TF field is 0, and the trigger frame does not trigger the TWT responding station or TWT scheduled station, and the TWT responding station or TWT scheduling AP is active during an unknown Trigger-enabled TWT service period, or is active during a known Trigger-enabled TWT service period but has not notified the peer station that the station is active

[0199] A TWT requesting station or a TWT scheduled station may receive a frame corresponding to the above case within the TWT service period while in an enabled state of sleep mode. In this case, if the station notifies the peer station that it is active but fails to receive the expected frame from the peer station during a pre-specified time (AdjustedMinimumTWTWakeDuration) from the start of the TWT service period, it may enter a sleep state. In the service period of a Trigger-enabled TWT, if a station fails to receive a trigger frame during a pre-specified time (AdjustedMinimumTWTWakeDuration) from the start of the TWT service period, the station may enter a sleep state. If the station determines that a TWT service period end event has occurred within the station's TWT service period, the station may enter sleep mode even before notifying the AP that it is active and receiving a response.

[0200]

[0201] Limited Target Wake Time

[0202] Restriced TWT (R-TWT) was introduced to guarantee low-latency traffic. Additionally, APs supporting multiple BSSIDs support actions to protect R-TWT schedules for the AP's nontransmitted / co-hosted BSSIDs. The AP and the station can perform R-TWT negotiations according to the negotiation method of Broadcast TWT. At this time, additional instructions for R-TWT scheduling may be executed. A station can request R-TWT scheduling from the AP using a TWT configuration request frame. The AP can accept or reject the R-TWT scheduling request. The AP can generate one or more R-TWT schedules and broadcast information regarding the generated R-TWT schedules. Specifically, the AP can include information regarding the R-TWT schedule in a beacon frame. A station can transmit a TWT configuration request frame to become a member of the R-TWT.

[0203] During the R-TWT membership setup process, the AP sets the value of the Trigger field in the Restricted TWT Parameter Set field to 1 to operate the R-TWT during the service period of a Trigger-enabled TWT. Additionally, for the individual address management frame transmitted by the station for R-TWT membership setup, the station must set the value of the Restricted TWT Traffic Info Present subfield to 1. The station can determine whether the TWT Parameter Set field indicates information for a Broadcast TWT or information for a Restricted TWT. Furthermore, during the R-TWT negotiation process, the AP and the station set the TID of the low-latency traffic to be transmitted during the R-TWT service period. The traffic TID may apply to both the uplink and downlink. The AP and the station can set the TID using the subfield of the Restricted TWT Traffic Info field. Additionally, the DL / UL R-TWT TID set by the AP and the station must be included within the set of DL / UL TIDs mapped to the link where each R-TWT membership is established. After the R-TWT consultation, at the start of the R-TWT service period, a station that is a member of the R-TWT may pause the operation of decreasing the backoff counter of an AC that is not mapped to an R-TWT TID until all buffered frames with the R-TWT TID have been transmitted. After all traffic corresponding to the R-TWT TID has been transmitted, or after the R-TWT service period has ended, the station may resume the operation of decreasing the backoff counter.

[0204] A non-AP station may terminate a TXOP, for which the non-AP EHT station is the TXOP holder, before the start time of the service period of the active R-TWT advertised by the connected AP. Before initiating frame exchange, the non-AP station may determine whether there is sufficient time to complete the frame exchange before the start of the R-TWT's service period and decide whether to perform the frame exchange based on this determination. Specifically, if the non-AP station determines before initiating frame exchange that it cannot complete the frame exchange before the start of the R-TWT's service period, the non-AP station may defer the channel access procedure. In this case, the non-AP station may reset the initial value of the backoff counter.

[0205] If the AP is the TXOP holder, the AP may terminate the TXOP before the R-TWT service period begins. However, if the reaming TXOP is used for a request for a DL transmission of the R-TWT DL TID or a UL transmission of the R-TWT UL TID during the R-TWT service period, the AP may not terminate the TXOP.

[0206] Additionally, the AP may set a quiet interval overlapping the R-TWT to protect the R-TWT from legacy stations that do not support R-TWT. The AP may set a quiet interval for 1 TU from the start of the R-TWT's service period. During the quiet interval, legacy stations that do not support R-TWT may not perform channel access procedures, including the decrement of the backoff counter. The AP may transmit a beacon frame or a probe response frame containing information regarding the quiet interval. Stations that support R-TWT may ignore the quiet interval overlapping the R-TWT.

[0207] FIG. 14 shows the R-TWT operation between an AP and a plurality of stations according to an embodiment of the present invention.

[0208] In the embodiment of FIG. 14, the first station (STA1) transmits a TWT setup request frame to the AP to join the R-TWT scheduled by the AP. In response to the TWT setup request frame, the AP transmits a TWT setup response frame instructing acceptance of the R-TWT subscription. After the R-TWT consultation, the AP broadcasts a beacon frame containing information about the R-TWT to the first TBTT. The information about the R-TWT may include information about the start time or interval of the service period of the R-TWT.

[0209] The second station (STA 2), which does not participate in the R-TWT, performs frame exchange as a TXOP holder and terminates the TXOP early before the start of the R-TWT service period. During the R-TWT service period, the AP transmits a trigger frame to the first station (STA 1). The first station (STA 1) transmits a PS-Poll frame in response to the trigger frame to indicate that it is active. The AP and the first station (STA 1) perform low-latency traffic exchange during the R-TWT service period.

[0210] FIG. 15 shows the format of a TWT element indicating information regarding an R-TWT according to an embodiment of the present invention.

[0211] Descriptions of content identical to or corresponding to the TWT element explained through Fig. 13 are omitted. Fig. 15(a) shows the format of the TWT element. Fig. 15(b) shows the format of the Control field of the TWT element. Fig. 15(c) shows the Restricted TWT Parameter Set field of the TWT element. Fig. 15(d) shows the format of the Request Type subfield of the Restricted TWT Parameter Set field of the TWT element. Fig. 15(e) shows the format of the Broadcast TWT Info subfield of the Restricted TWT Parameter Set field of the TWT element. Fig. 15(f) shows the format of the Restricted TWT Traffic Info field of the Restricted TWT Parameter Set field of the TWT element. Fig. 15(g) shows the format of the Traffic Info Control field of the Restricted TWT Traffic Info field of the TWT element.

[0212] The Control field may include a 1-bit Link ID Bitmap Present subfield and a 1-bit Aligned TWT subfield instead of the 2-bit Reserved subfield of FIG. 13 (b). The Link ID Bitmap Present field may indicate that the Link ID Bitmap field is included in the Individual TWT Parameter Set field. If the value of the Link ID Bitmap Present field is 1, the Individual TWT Parameter Set field may include a 2-octet Link ID Bitmap field. If the value of the Link ID Bitmap Present field is 0, the Individual TWT Parameter Set field may not include the Link ID Bitmap field. The Aligned TWT field may indicate whether alignment of the individual TWT is requested or applied to two or more setup links when the MLD (multi-link device) transmits a TWT element containing an individual TWT parameter set. Alignment of the individual TWT may mean that the start times of the individual TWTs are aligned across multiple links and that the same TWT parameters are used.

[0213] Unlike (e) of FIG. 13, the Restricted TWT Parameter Set field may include a Restricted TWT Traffic Info field that indicates the TID of the traffic to be transmitted when the Restricted TWT is created. When the value of the Restricted TWT Traffic Info Present subfield of the Broadcast TWT Info field is 1, the Restricted TWT Parameter Set field may include a 3-octet Restricted TWT Traffic Info field. When the value of the Restricted TWT Traffic Info Present subfield of the Broadcast TWT Info field is 0, the Restricted TWT Parameter Set field may not include a 3-octet Restricted TWT Traffic Info field.

[0214] If the value of the Broadcast TWT Recommendation subfield is 4, the TWT indicated by the Broadcast TWT Recommendation subfield is an R-TWT, and the Broadcast TWT Parameter Set field containing the Broadcast TWT Recommendation subfield may indicate that it is a Restricted TWT Parameter Set field. The Aligned subfield may indicate whether the schedules of broadcast TWTs on links other than the link where the R-TWT is set in the AP MLD are aligned within 1 TU.

[0215] The Broadcast TWT Info subfield of the TWT element may include a 1-bit Restricted TWT Traffic Info Present subfield, a 2-bit Restricted TWT Schedule Info subfield, a 5-bit Broadcast TWT ID subfield, and an 8-bit Broadcast TWT Persistence subfield. If the value of the Restricted TWT Traffic Info Present subfield is 1, the Restricted TWT Parameter Set field may include the Restricted TWT Traffic Info field. If the value of the Restricted TWT Traffic Info Present subfield is 0, the Restricted TWT Parameter Set field may not include the Restricted TWT Traffic Info field. The Restricted TWT Schedule Info subfield may indicate the status of the R-TWT. If the value of the Restricted TWT Schedule Info subfield is 0, it may indicate that the R-TWT does not exist for any member station or is suspended from all member stations. This may be referred to as an idle R-TWT. If the value of the Restricted TWT Schedule Info subfield is 1, it indicates that at least one member station is operating in the R-TWT. This can be referred to as an active R-TWT. If the value of the Restricted TWT Schedule Info subfield is 2, it indicates that the AP will not accept any further member joining to the R-TWT schedule. If the AP determines that sufficient resources have been allocated to the R-TWT and there are no more resources to allocate to new member stations, it may set the value of the Restricted TWT Schedule Info subfield to 2.This state can be referred to as a full R-TWT schedule. If the value of the Restricted TWT Schedule Info subfield is 3, it indicates that the R-TWT is active but is an R-TWT of a nontransmitted BSSID. An AP with a nontransmitted BSSID may be restricted to being a member of a multiple BSSID set or a co-hosted BSSID set. Additionally, if the value of the Restricted TWT Schedule Info subfield is 3, the value of the Broadcast TWT ID subfield can always be 31.

[0216] The Restricted TWT Traffic Info field may include a Traffic Info Control field of one octet, a Restricted TWT DL TID Bitmap field of one octet, and a Restricted TWT UL TID Bitmap field of one octet. The Traffic Info Control field is a field for indicating whether the Restricted TWT DL TID Bitmap field and the Restricted TWT UL TID Bitmap field are valid. The Restricted TWT DL TID Bitmap field and the Restricted TWT UL TID Bitmap field indicate the TID of low-latency traffic that an AP or station participating in the R-TWT will transmit in the Downlink and Uplink of the R-TWT. If the value of the k-th bit of the bitmap is 1, it may indicate that the TID corresponding to the k-th bit in that direction is low-latency traffic to be exchanged in the R-TWT. In addition, if the value of the k-th bit of the bitmap is 0, it may indicate that the TID corresponding to the k-th bit in that direction is not low-latency traffic to be exchanged in the R-TWT.

[0217] The Traffic Info Control field may include a 1-bit DL TID Bitmap Valid subfield, a 1-bit UL TID Bitmap Valid subfield, and a 6-bit Reserved subfield. If the value of the DL TID Bitmap Valid subfield is 1, it may indicate that the value indicated by the Restricted TWT DL TID Bitmap field is valid. If the value of the DL TID Bitmap Valid subfield is 0, all Downlink TID traffic on the corresponding link may be considered low-latency traffic. The Restricted TWT DL TID Bitmap field may be reserved. If the value of the UL TID Bitmap Valid subfield is 1, it may indicate that the value indicated by the Restricted TWT UL TID Bitmap field is valid. If the value of the UL TID Bitmap Valid subfield is 0, all Uplink TID traffic on the corresponding link may be considered low-latency traffic. The Restricted TWT UL TID Bitmap field may be reserved.

[0218] R-TWT can protect frame exchanges between the AP and a station from stations belonging to the BSS operated by the AP, but it has the limitation of not being able to protect against interference from OBSS.

[0219] Figure 16 shows that interference occurs in frame exchange within the R-TWT due to OBSS.

[0220] In the embodiment of FIG. 16, the first AP (AP 1), the second AP (AP 2), and the third AP (AP 3) each operate a respective BSS. The first AP (AP 1) and the second AP (AP 2) set an R-TWT schedule. Additionally, the first AP (AP 1), the second AP (AP 2), and the third AP (AP 3) each have an operating bandwidth and a primary 20 MHz subchannel at the same location. At this time, the primary 20 MHz subchannel may be a PHY preamble detection channel. To protect the R-TWT service period, the station of the BSS of the first AP (AP 1) allows the TXOP holder to adjust the end time of their TXOP before the R-TWT service period begins. If the TXOP of the second AP (AP 2) occupies the medium before the R-TWT SP of the first AP (AP 1) begins, the first AP (AP 1) may be unable to transmit within the R-TWT service period even after the R-TWT service period begins. In A-1 of FIG. 16, the TXOP holder terminates the ongoing TXOP early to protect the R-TWT service period in the BSS of the first AP (AP 1). The second AP (AP 2), which is an OBSS AP, cannot know whether the first AP (AP 1) has started the R-TWT service period. Therefore, the first AP (AP 1) does not terminate the ongoing TXOP early. Due to the medium occupancy by the second AP (AP 2), the first AP (AP 1) cannot transmit data during the R-TWT service period. In A-2 of FIG. 16, the station of the BSS of the second AP (AP 2) terminates the TXOP early before the start of the R-TWT service period by the TXOP holder of the ongoing TXOP to protect the R-TWT. The second AP (AP 2) attempts to access the channel to access the medium during its R-TWT service period, but the BSS of the third AP (AP 3) occupies the medium first, so the second AP (AP 2) cannot transmit any low-latency traffic during the R-TWT service period.

[0221] As explained earlier, R-TWT can protect the exchange of low-latency traffic from stations within the BSS. However, it cannot resolve transmission delays caused by OBSS.

[0222]

[0223] <Coordinated R-TWT>

[0224] When an AP's R-TWT is protected through consultation between APs, the R-TWT is referred to as the coordinated R-TWT, or Co-RTWT. Specifically, one AP transmits information regarding the AP's R-TWT to the OBSS AP, and the OBSS AP may coordinate channel access based on the service period of the Co-RTWT. At this time, the OBSS AP may accept or reject the request for R-TWT protection. Specifically, the AP, acting as the Co-RTWT requesting AP, may transmit a frame requesting consultation on the Co-RTWT to the OBSS AP. Through this, the AP can initiate Co-RTWT consultation. The frame requesting consultation on the Co-RTWT may contain information regarding the Co-RTWT. Additionally, the frame requesting consultation on the Co-RTWT may be a pre-designated management frame. Furthermore, the recipient address of the frame requesting consultation on the Co-RTWT may be the MAC address of the OBSS AP. The AP of the OBSS acts as a Co-RTWT response AP and can transmit a response frame to a frame requesting consultation with the Co-RTWT. The response frame may be a pre-designated management frame. Additionally, the response frame may indicate whether to protect the Co-RTWT, request modification of the Co-RTWT, or deny protection of the Co-RTWT. The frame requesting consultation with the Co-RTWT and the response frame may contain one or more TWT elements. Additionally, the response frame may be an individually addressed management frame.

[0225] When a Co-RTWT agreement is established, the Co-RTWT responding AP may be referred to as a Co-RTWT coordinated AP and must protect the agreed-upon R-TWT schedule. Specifically, the Co-RTWT coordinated AP can terminate the TXOP early before the start of the Co-RTWT requesting AP's R-TWT service period. All Co-RTWT coordinated APs participating in Co-RTWT have Time Synchronization Function (TSF) timers with different values. Therefore, the Co-RTWT requesting AP can exchange information regarding TSF timers with the previously coordinated APs during the consultation process. Through this, the Co-RTWT coordinated AP can calculate the TSF timer offset between other APs.

[0226] FIG. 17 shows the R-TWT protection operation between coordinated APs according to an embodiment of the present invention after Co-RTWT consultation.

[0227] In the embodiment of FIG. 17, the first AP (AP 1) establishes a Co-RTWT agreement with the second AP (AP 2) and the third AP (AP 3). Before the start of the R-TWT service period of the first AP (AP 1), which is the Co-RTWT requesting AP, the second AP (AP 2) and the third AP (AP 3), which are the Co-RTWT coordinated APs, may terminate their remaining TXOPs while the frame switching procedure is in progress to protect the R-TWT of the first AP (AP 1). The first AP (AP 1) exchanges low-latency traffic during the R-TWT service period. To protect the R-TWT service period of the first AP (AP 1), the second AP (AP 2) and the third AP (AP 3) notify that non-AP stations connected to each of the second AP (AP 2) and the third AP (AP 3) do not perform channel access procedures during the R-TWT service period of the first AP (AP 1). Specifically, the second AP (AP 2) and the third AP (AP 3) may include information regarding the R-TWT service period corresponding to the R-TWT service period of the first AP (AP 1) in the beacon frame. Additionally, the second AP (AP 2) and the third AP (AP 3) may set membership registration to be disallowed for the R-TWT.

[0228]

[0229] <Co-RTWT 협의 규칙>

[0230] As previously explained, the AP may initiate Co-RTWT consultation by sending an individually addressed management frame to the OBSS AP. At this time, the management frame may include information regarding the AP's R-TWT schedule. The Co-RTWT responding AP, which is the OBSS AP that receives the management frame, may send a response frame to the Co-RTWT requesting AP instructing it to accept, propose, or reject the request of the Co-RTWT requesting AP. When the Co-RTWT responding AP determines that the Co-RTWT requesting AP's R-TWT schedule does not have a serious impact on the BSS operated by the Co-RTWT responding AP, the Co-RTWT responding AP may accept the request of the Co-RTWT requesting AP. When a Co-RTWT responding AP determines that the R-TWT schedule of the Co-RTWT requesting AP does not have a serious impact on the BSS operated by the Co-RTWT responding AP, it can be determined based on whether the R-TWT schedule of the Co-RTWT responding AP needs to be changed due to the R-TWT of the Co-RTWT requesting AP, or whether there is no impact on the transmission of low-latency traffic even if the R-TWT schedule of the Co-RTWT responding AP is changed.

[0231] Additionally, if the R-TWT of the Co-RTWT request AP affects the BSS of the Co-RTWT response AP, the Co-RTWT response AP may propose an alternative to the R-TWT of the Co-RTWT request AP. Furthermore, the Co-RTWT response AP may determine that the R-TWT schedule of the Co-RTWT request AP has a serious impact on the BSS operated by the Co-RTWT response AP based on whether the R-TWT schedule of the Co-RTWT response AP overlaps with the received R-TWT schedule of the Co-RTWT request AP, or whether the frame exchange procedure within the BSS of the Co-RTWT response AP cannot proceed smoothly due to the R-TWT schedule of the Co-RTWT request AP. In this case, the response frame may include a TWT element instructing the proposal. In this case, the TWT Setup Command field of the Restricted TWT Parameter Set field of the TWT element may be set to 5, a value indicating an Alternative TWT. Additionally, restrictions may apply to changes to the R-TWT schedule for which the Co-RTWT responding AP requested protection. Specifically, the Co-RTWT responding AP may propose a change to the duration of the R-TWT service period in the R-TWT schedule of the Co-RTWT requesting AP, but may not be allowed to propose a change to the interval for the start time of the R-TWT service period. Specifically, the Co-RTWT responding AP may propose a change to the value of the Nominal Minimum TWT Wake Duration subfield to reduce the duration of the R-TWT service period in the received R-TWT schedule, but may not be allowed to propose a change to the value of the TWT Wake Interval Mantissa subfield and the value of the TWT Wake Interval Exponent subfield, which indicate the interval for the start time of the R-TWT SP.This allows the Co-RTWT responding AP to guarantee the opportunity to send low-latency traffic to the Co-RTWT requesting AP if low-latency traffic to be transmitted by the Co-RTWT requesting AP occurs periodically at the start of the R-TWT service period.

[0232] A Co-RTWT responding AP may reject an R-TWT protection request transmitted from a Co-RTWT requesting AP. A Co-RTWT responding AP may reject the request by transmitting a response frame to the Co-RTWT request frame transmitted by the Co-RTWT requesting AP. In this case, the value of the TWT Setup Command subfield of the Request Type field in the Restricted TWT Parameter Set field of the response frame may be set to a value indicating Reject TWT. A Co-RTWT responding AP may reject an R-TWT protection request transmitted from a Co-RTWT requesting AP if the R-TWT schedule for which protection was requested restricts the operation of all legacy stations within the Co-RTWT responding AP's BSS, thereby significantly degrading throughput within the BSS; if the Co-RTWT responding AP cannot protect the R-TWT schedule; or if the Co-RTWT responding AP determines that excessive overhead occurs during the consultation process with the Co-RTWT responding AP.

[0233] Furthermore, legacy stations that do not support the R-TWT of the BSS operated by the Co-RTWT responding station cannot recognize the R-TWT of the Co-RTWT requesting station. Therefore, a method to protect against this is also required.

[0234] The Co-RTWT requesting AP may request the Co-RTWT responding AP to set a quiet interval that overlaps the R-TWT in order to protect the Co-RTWT requesting AP's R-TWT schedule from legacy stations in the Co-RTWT responding AP's BSS. During the Co-RTWT consultation process, the Co-RTWT requesting AP may request the Co-RTWT responding AP to set a quiet interval that overlaps the R-TWT. In this case, the start time of the quiet interval may be restricted to be the same as the start time of the Co-RTWT service period. During the quiet interval, legacy non-AP stations that do not support R-TWT may stop accessing the medium. Additionally, the Co-RTWT requesting AP may request the Co-RTWT responding AP to set the duration to be greater than 1 TU, which is the duration of the quiet interval defined in the 802.11 standard. At this time, if the Co-RTWT requesting AP requests a quiet period setting for a period greater than 1 TU, the Co-RTWT requesting AP can specify the duration of the quiet period using the Quiet element within the request frame for Co-RTWT consultation.

[0235] Only when the Co-RTWT requesting AP has set a quiet period that overlaps with the Co-RTWT schedule to the station of the BSS operated by the Co-RTWT requesting AP, the Co-RTWT requesting AP may be allowed to request the Co-RTWT responding AP to set a quiet period that overlaps with the Co-RTWT schedule.

[0236] A Co-RTWT responding AP that receives a request to set a quiet period may not set a quiet period. In this case, the Co-RTWT responding AP's refusal to accept the request to set a quiet period may not affect the Co-RTWT consultation. A Co-RTWT responding AP that has not received a request to set a quiet period may not be allowed to set a quiet period that overlaps with the Co-RTWT schedule.

[0237] In the embodiments described above, the Co-RTWT request AP may request protection of the R-TWT and the setting of a quiet interval by using a pre-specified field of the TWT element corresponding to the Co-RTWT service period of the Co-RTWT request frame, such as the Quiet Interval Setup Request subfield. At this time, the Co-RTWT request AP may set the pre-specified field to a pre-specified value, such as 1. At this time, if the pre-specified field is set to an unspecified value, such as 0, the TWT element may not request the setting of a quiet interval. Additionally, the Co-RTWT response AP may instruct whether to set a quiet interval by setting the value of the pre-specified field of the TWT element corresponding to the Co-RTWT service period of the Co-RTWT response frame to a pre-specified value. The pre-specified value indicating to set a quiet interval may be 1. At this time, the pre-specified value indicating not to set a quiet interval may be 0. If the Co-RTWT request AP does not request a quiet interval setting, the Co-RTWT response AP may not be allowed to set the value of a pre-specified field to a pre-specified value that instructs to set a quiet interval.

[0238] The TWT element referred to in this specification may refer to an element containing information regarding a broadcast TWT or information regarding an R-TWT. Additionally, the TWT element referred to in this specification may refer to an element containing information regarding a Co-RTWT. Additionally, a pre-specified field indicating to set a quiet interval may be a 1-bit field of the TWT element.

[0239]

[0240] The Co-RTWT Response AP may set the scope for performing Co-RTWT protection actions during the Co-RTWT consultation process. Specifically, the Co-RTWT Response AP may determine that only the Co-RTWT Response AP performs Co-RTWT channel access actions for Co-RTWT protection. Additionally, the Co-RTWT Response AP may determine that stations supporting R-TWT in the Co-RTWT Response AP and the Co-RTWT Response AP's BSS perform Co-RTWT channel access actions for Co-RTWT protection. Furthermore, the Co-RTWT Response AP may determine that all non-AP stations within the Co-RTWT Response AP and the Co-RTWT Response AP's BSS perform Co-RTWT channel access actions for Co-RTWT protection. Co-RTWT channel access actions may include the Co-RTWT coordinated AP or non-AP stations connected to that AP terminating remaining TXOPs before the end of the TXOPs prior to the start of the Co-RTWT service period for Co-RTWT protection. If the Co-RTWT responding AP decides that all non-AP stations within the Co-RTWT responding AP and the Co-RTWT responding AP's BSS perform Co-RTWT channel access operations for Co-RTWT protection, the Co-RTWT responding AP may accept Co-RTWT requests and accept requests for quiet interval settings.

[0241] If the Co-RTWT responding AP decides that only the Co-RTWT responding AP performs Co-RTWT channel access operations, or if it decides that the Co-RTWT responding AP and non-AP stations supporting R-TWT within the Co-RTWT responding AP's BSS perform Co-RTWT channel access operations, the Co-RTWT responding AP may accept only Co-RTWT protection requests and reject quiet interval establishment requests. If the Co-RTWT requesting AP does not request quiet interval establishment, the Co-RTWT responding AP may not be permitted to establish a quiet interval for Co-RTWT. The response to a quiet interval establishment request may not affect the outcome of the Co-RTWT consultation.

[0242] In the embodiments described above, the Co-RTWT requesting AP may request the Co-RTWT responding AP to set the legacy station to determine that it is busy during medium time instead of setting a quiet period. Setting the legacy station to determine that it is busy during medium time may be the AP notifying the legacy station within the AP's BSS that there is data transmission scheduled for a specific time period. Additionally, setting the legacy station to determine that it is busy during medium time may be the AP causing the legacy station to stop channel access including backoff actions. Additionally, setting the legacy station to determine that it is busy during medium time may be the AP sending a PPDU before the start of the Co-RTWT service period so that the legacy station in the AP's BSS sets the NAV. In this case, the AP may set the value of the signaling field indicating the TOXP of the PPDU, such as the TXOP field of U-SIG or HE-SIG-A, or the Duration field of the MAC frame included in the PPDU to the maximum.

[0243] The Co-RTWT request AP may provide medium access opportunities to non-AP stations connected to the Co-RTWT response AP, such as stations that support Co-RTWT operations, during the Co-RTWT service period. Specifically, the Co-RTWT request AP may indicate whether medium access is available during Co-RTWT for non-AP stations connected to the Co-RTWT response AP in a frame directing the Co-RTWT request. In this case, the request frame may include a field, such as a 1-bit field, indicating whether medium access is available during Co-RTWT for non-AP stations connected to the Co-RTWT response AP. Additionally, the Co-RTWT response AP may indicate to non-AP stations connected to the Co-RTWT response AP that they can perform medium access procedures during the Co-RTWT service period directed by the Co-RTWT response AP. After Co-RTWT agreement is established, the Co-RTWT coordinated AP transmits a beacon frame containing the Co-RTWT schedule to cause all R-TWT-supporting stations within the Co-RTWT coordinated AP's BSS to perform Co-RTWT protection actions. At this time, the Co-RTWT coordinated AP may indicate whether non-AP stations are allowed to perform medium access during Co-RTWT. Specifically, the Co-RTWT coordinated AP may indicate whether R-TWT-supporting non-AP stations are allowed to perform medium access during Co-RTWT in a pre-specified field of the TWT element. In this case, the pre-specified field may be a reserve bit. If R-TWT-supporting non-AP stations are allowed to perform medium access during Co-RTWT, R-TWT-supporting non-AP stations connected to the Co-RTWT coordinated AP may perform medium access in Co-RTWT.At this time, non-AP stations supporting R-TWT connected to the Co-RTWT coordinated AP may perform medium access for traffic corresponding to the UL TID of the R-TWT. Additionally, non-AP stations supporting R-TWT connected to the Co-RTWT coordinated AP may set a TXOP with a duration that allows for a single frame exchange during Co-RTWT. In this case, the TXOP may not be allowed to exit the quiet period set for Co-RTWT. If a quiet period is not set for Co-RTWT, non-AP stations supporting R-TWT connected to the Co-RTWT coordinated AP may perform medium access from the start of the Co-RTWT service period.

[0244] FIG. 18 shows a Co-RTWT negotiation process according to an embodiment of the present invention.

[0245] In the embodiment of FIG. 18, the first AP (AP 1) transmits a request frame (Co-RTWT Setup Request) instructing the second AP (AP 2), which is the Co-RTWT response AP, to request Co-RTWT as a Co-RTWT request AP. The request frame includes a TWT element instructing information regarding Co-RTWT. Additionally, the request frame may include a Quiet element instructing whether to request a quiet interval setup during Co-RTWT. Additionally, the request frame may include a field (Coordinated BSS Medium Access Allowed) instructing whether medium access is allowed for RTWT-supporting non-AP stations connected to the second AP (AP 2) during Co-RTWT. If the first AP (AP 1) sets a quiet interval that overlaps with Co-RTWT, the first AP (AP 1) may request the second AP (AP 2) to set a quiet interval for Co-RTWT.

[0246] The second AP (AP 2) receives a request frame (Co-RTWT Setup Request) and can transmit a response frame (Co-RTWT Setup Response) indicating acceptance, alternative, or rejection. If the second AP (AP 2) transmits a response frame (Co-RTWT Setup Response) indicating acceptance, the second AP (AP 2) can transmit a response frame (Co-RTWT Setup Response) indicating the same conditions requested by the first AP (AP 1). In this case, the second AP (AP 2) can broadcast a management frame, such as a beacon frame, indicating information regarding the Co-RTWT. If the second AP (AP 2) transmits a response frame (Co-RTWT Setup Response) indicating an alternative, the second AP (AP 2) can transmit a response frame (Co-RTWT Setup Response) indicating an option for the proposed Co-RTWT. For example, if the second AP (AP 2) rejects the quiet interval setting requested by the first AP (AP 1), the second AP (AP 2) may include the Quiet element in the response frame (Co-RTWT Setup Response) or may not include the Quiet element in the response frame (Co-RTWT Setup Response).

[0247]

[0248] <Co-RTWT 공지(announcement)>

[0249] After Co-RTWT consensus is established, the Co-RTWT coordinated AP may announce the R-TWT schedule corresponding to Co-RTWT in the BSS of the Co-RTWT coordinated AP. At this time, the Co-RTWT coordinated AP may transmit a pre-designated frame announcing the R-TWT schedule corresponding to Co-RTWT. The pre-designated frame may be a broadcast frame and may be a management frame. For example, the pre-designated frame may be a beacon frame. Additionally, when the Co-RTWT coordinated AP sets a quiet period for Co-RTWT according to the embodiment described above, the Co-RTWT coordinated AP may transmit a pre-designated frame indicating the quiet period for Co-RTWT. The pre-designated frame may be a broadcast frame and may be a management frame. For example, the pre-designated frame may be a beacon frame. Additionally, the pre-designated frame may include a Quiet element indicating the quiet period.

[0250] As in the embodiments described above, the Co-RTWT coordinated AP may announce that non-AP stations of the Co-RTWT coordinated AP's BSS are not allowed to participate in the R-TWT. Specifically, the Co-RTWT coordinated AP may announce the R-TWT for Co-RTWT but may indicate that membership in the R-TWT for Co-RTWT is not possible. In this case, the Co-RTWT coordinated AP may set the value of the Restricted TWT Schedule Info subfield of the Broadcast TWT Parameter Set field, which indicates the R-TWT for Co-RTWT, to 2 or 3. In this case, if a non-AP station of the Co-RTWT coordinated AP's BSS operates on a link corresponding to the DL TWT TID or UL TWT TID indicated in the R-TWT, it may perform channel access for traffic corresponding to that TID. Accordingly, there is a possibility that the Co-RTWT may not be protected.

[0251] A Co-RTWT-controlled AP may prohibit all medium access in the R-TWT for Co-RTWT. Specifically, a Co-RTWT-controlled AP may not set the TID of low-latency traffic that is allowed to be transmitted in the R-TWT for Co-RTWT. For example, a Co-RTWT-controlled AP may set the value of all bits in the bitmap indicating low-latency traffic that is allowed to be transmitted in the R-TWT for Co-RTWT to 0. In a specific embodiment, a Co-RTWT-controlled AP may set the values ​​of both the DL TID Bitmap Valid subfield and the UL TID Bitmap Valid subfield of the Traffic Info Control field in the Restricted TWT Traffic Info subfield of the Broadcast TWT Parameter Set field to 1, and set both the values ​​of the Restricted TWT DL TID Bitmap subfield and the Restricted TWT UL TID Bitmap subfield of the Restricted TWT Traffic Info field to 0. Through this, non-AP stations belonging to the BSS of a Co-RTWT coordinated AP may not perform channel access procedures and may not perform medium access during the Co-RTWT service period.

[0252]

[0253] <Co-RTWT Protection 동작>

[0254] A Co-RTWT coordinated AP performs actions to protect the Co-RTWT service period. When a Co-RTWT coordinated AP is a TXOP holder and performs frame exchange procedures during a TXOP, it may terminate its remaining TXOP before the start of the Co-RTWT service period and before the end of the TXOP. Additionally, if a non-AP station connected to the Co-RTWT coordinated AP is a TXOP holder, it may terminate its remaining TXOP before the end of the TXOP due to the R-TWT set for Co-RTWT.

[0255] Additionally, if a Co-RTWT mediated AP receives a frame from a non-AP station during the Co-RTWT service period, the Co-RTWT mediated AP may not send a response frame for the received frame. This allows a non-AP station connected to a Co-RTWT mediated AP that does not support R-TWT to send a UL frame, and a non-AP station not connected to a Co-RTWT mediated AP to send management frames for connection, such as probe request frames and connection request frames, to the Co-RTWT mediated AP. Through this, the Co-RTWT mediated AP can protect the Co-RTWT service period.

[0256] Additionally, if a Co-RTWT-coordinated AP receives two consecutive frames from a non-AP station during the Co-RTWT service period, the Co-RTWT-coordinated AP may transmit a pre-designated frame. This is because a non-AP station that transmitted a frame during the Co-RTWT service period may determine that the transmission failed and attempt to continue transmission. Specifically, if a Co-RTWT-coordinated AP receives a frame from a non-AP station during the Co-RTWT service period in which the value of the Retry field is 1, the Co-RTWT-coordinated AP may aggregate and transmit a pre-designated frame and an Ack frame. The pre-designated frame may be a management frame. In this case, the management frame may include a TWT element indicating information regarding Co-RTWT. This action may be permitted only if the Co-RTWT-coordinated AP is allowed to perform medium access during the Co-RTWT service period. If a Co-RTWT coordinated AP is not allowed to perform medium access during the Co-RTWT service period, the Co-RTWT coordinated AP may not be allowed to transmit a response frame for a received frame.

[0257] As previously explained, if medium access is allowed for non-AP stations supporting R-TWT connected to a Co-RTWT-coordinated AP during the Co-RTWT service period, the non-AP stations supporting R-TWT connected to the Co-RTWT-coordinated AP may transmit frames to the Co-RTWT-coordinated AP. In this case, the non-AP stations supporting R-TWT connected to the Co-RTWT-coordinated AP may perform channel access and transmission for traffic corresponding to the UL TID specified in the R-TWT configured for Co-RTWT, but channel access and transmission for other traffic may not be allowed. Additionally, the Co-RTWT-coordinated AP may transmit a response to a frame received from a non-AP station supporting R-TWT connected to the Co-RTWT-coordinated AP.

[0258] If the service period of the Co-RTWT begins before the Co-RTWT-coordinated AP announces the R-TWT for the Co-RTWT, it may be difficult for the Co-RTWT-coordinated AP to protect the Co-RTWT. Therefore, it can be guaranteed that the Co-RTWT-coordinated AP announces the R-TWT for the Co-RTWT before the service period of the Co-RTWT begins.

[0259] When Co-RTWT consultation and the Co-RTWT service period begin prior to the TBTT interval of a Co-RTWT coordinated AP, the Co-RTWT coordinated AP may broadcast a pre-designated frame indicating the Co-RTWT service period before the start of the Co-RTWT service period. In this case, the pre-designated frame may be a management frame. In this case, the pre-designated frame may be a beacon frame. Specifically, the beacon frame may include a TWT element. Additionally, the pre-designated frame may be a management frame containing only a TWT element. In this case, the management frame may be an action frame, a probe response frame, or a newly defined frame. In these embodiments, the TWT element may include information regarding the R-TWT of the Co-RTWT requesting AP.

[0260] To protect this, the corresponding Co-RTWT schedule information may be indicated using the aforementioned Co-RTWT announcement method or a new definition method. Additionally, in these embodiments, the Co-RTWT coordination AP may transmit a pre-specified frame using a transmission method for low-latency traffic. Specifically, the Co-RTWT coordination AP may transmit a pre-specified frame by performing a backoff procedure using the channel access parameter of the AC having the smallest CW size among the plurality of ACs.

[0261] A non-AP station that receives a pre-specified frame may terminate the remaining TXOP before the TXOP end time before the Co-RTWT service period. A non-AP station that receives a pre-specified frame may not perform medium access during the Co-RTWT service period.

[0262] FIG. 19 shows a method for a Co-RTWT coordinated AP to transmit information regarding Co-RTWT when the Co-RTWT service period prior to TBTT of the Co-RTWT coordinated AP begins after Co-RTWT consultation according to an embodiment of the present invention.

[0263] In the embodiment of FIG. 19, the first AP (AP 1), which is the Co-RTWT request AP, transmits a Co-RTWT request to the second AP (AP 2), which is the Co-RTWT response AP. The service period of the Co-RTWT of the first AP (AP 1) begins before the TBTT of the second AP (AP 2). Before the start of the Co-RTWT service period, the second AP (AP 2) transmits a management frame (Mgmt) containing Co-RTWT information. At this time, the management frame (Mgmt) includes a TWT element. Additionally, the management frame (Mgmt) may further include a Quiet element. Non-AP stations (STA 2-1, STA 2-2) connected to the second AP (AP 2) that received the management frame (Mgmt) may terminate the remaining TXOP before the TXOP end time before the Co-RTWT service period. Non-AP stations (STA 2-1, STA 2-2) connected to the second AP (AP 2) may not perform medium access during the Co-RTWT service period.

[0264]

[0265] <Co-RTWT 서비스 기간 조기 종료>

[0266] During the R-TWT service period, the AP can transmit buffered low-latency data to non-AP STAs. Additionally, non-AP stations can transmit buffered low-latency data from non-AP stations to the AP. If both the AP and the non-AP station have transmitted all their buffered low-latency data before the end of the R-TWT service period, the medium may remain idle. In this case, during the remaining service period, the AP not harmonized with Co-RTWT and the non-AP station connected to the AP can perform frame exchanges regardless of the TID allowed in the R-TWT. Conversely, the Co-RTWT harmonized AP does not attempt medium access during the remaining service period to protect the Co-RTWT service period. Therefore, there is a possibility that the Co-RTWT harmonized AP may suffer a loss in transmission opportunities.

[0267] A TWT scheduling AP can generate an event to terminate the remaining R-TWT. However, the event to terminate the R-TWT generated by the TWT scheduling AP can only be delivered to the TWT scheduling AP's BSS. Therefore, the event to terminate the R-TWT generated by the Co-RTWT requesting AP may not be delivered to the BSS where the Co-RTWT coordinated AP is operating. To resolve this, a method is required for the Co-RTWT requesting AP to notify the Co-RTWT coordinated AP of the termination of the Co-RTWT.

[0268] When the Co-RTWT service period of the Co-RTWT ends, the Co-RTWT requesting AP may notify the corresponding Co-RTWT coordinated AP of the fact that the Co-RTWT service period has ended. At this time, the Co-RTWT requesting AP may transmit a frame to the Co-RTWT coordinated AP indicating the fact that the Co-RTWT service period has ended. When the Co-RTWT coordinated AP receives the frame indicating the fact that the Co-RTWT service period has ended, the Co-RTWT coordinated AP may determine that the Co-RTWT service period has ended. In another specific embodiment, when the Co-RTWT coordinated AP receives a frame transmitted by the Co-RTWT requesting AP to terminate the Co-RTWT service period from the Co-RTWT requesting AP's BSS, the Co-RTWT coordinated AP may determine that the Co-RTWT service period has ended.

[0269] If the Co-RTWT coordinated AP determines that the Co-RTWT service period has ended, the Co-RTWT coordinated AP may release the R-TWT for the Co-RTWT.

[0270] Specifically, if the Co-RTWT requesting AP has transmitted all buffered low-latency traffic before the end of the Co-RTWT requesting AP's R-TWT service period, the Co-RTWT requesting AP may transmit a frame instructing an R-TWT service termination event to the R-TWT scheduled station to terminate the R-TWT service period before the service period duration expires. At this time, the Co-RTWT requesting AP may perform the TWT service period termination operation used for TWT service termination. At this time, the Co-RTWT requesting AP may transmit a pre-specified frame to the Co-RTWT coordinated AP in the remaining TXOP within the Co-RTWT service period to notify the end of the Co-RTWT service period. The pre-specified frame may be a frame that terminates both the TXOP and the TWT service period simultaneously. In this case, the pre-specified frame may be a CF-End frame. Additionally, the value of the More Data field of the pre-specified frame may be 0.

[0271] A Co-RTWT-coordinated AP that receives a pre-specified frame may perform channel access and broadcast information instructing the termination of the R-TWT to non-AP stations connected to the Co-RTWT-coordinated AP. The information instructing the termination of the TWT may be a frame in which a termination event of the TWT service period is indicated. In this embodiment, too much time may be elapsed from the termination of the Co-RTWT to the Co-RTWT-coordinated AP broadcasting the information instructing the termination of the R-TWT.

[0272] If the Co-RTWT requesting AP has transmitted all buffered low-latency traffic before the end of the Co-RTWT requesting AP's R-TWT service period, the Co-RTWT requesting AP may share the remaining TXOPs with the Co-RTWT coordinated AP. In this case, the Co-RTWT requesting AP transmits a frame for TXOP sharing to the Co-RTWT coordinated AP. The frame for TXOP sharing may be a MU-RTW TXS trigger frame. Specifically, the Co-RTWT requesting AP may transmit a MU-RTW TXS trigger frame to the Co-RTWT coordinated AP via Co-TDMA without transmitting a polling frame. This allows the Co-RTWT requesting AP to notify the early termination of Co-RTWT. If the Co-RTWT coordinated AP receives the frame for TXOP sharing, the Co-RTWT coordinated AP may transmit a response to the frame for TXOP sharing. A non-AP station connected to a Co-RTWT coordinated AP that has received a response may determine that the R-TWT for Co-RTWT has been terminated. In this embodiment, the duration of the TXOP shared by the Co-RTWT requesting AP may be sufficient time for the Co-RTWT coordinated AP to transmit the response. Additionally, the Co-RTWT coordinated AP that has transmitted the response may broadcast information indicating the termination of the R-TWT, such as a frame in which the value of the More Data field is 0, in accordance with the embodiments described above.

[0273] FIG. 20 shows an operation in which a Co-RTWT request AP instructs a Co-RTWT response AP to a Co-RTWT service period end event according to an embodiment of the present invention.

[0274] In the embodiment of FIG. 20, the first AP (AP 1), which is the Co-RTWT request AP, transmits a Co-RTWT request to the second AP (AP 2), which is the Co-RTWT response AP. The service period of the Co-RTWT of the first AP (AP 1) begins before the TBTT of the second AP (AP 2). During the Co-RTWT service period, the first AP (AP 1) and the non-AP station connected to the first AP (AP 1) perform frame exchange for the exchange of low-latency traffic. When the first AP (AP 1) and the non-AP station connected to the first AP (AP 1) have exchanged all buffered low-latency traffic, the first AP (AP 1) transmits a MU-RTS TXS frame to the second AP (AP 2) instructing the termination of the Co-RTWT. At this time, the second AP (AP 2) determines that the Co-RTWT is terminated. The second AP (AP 2) transmits a CTS frame to the first AP (AP 1) in response to the MU-RTS TXS frame. Upon receiving the CTS frame, the non-AP station (STA 2-1) connected to the second AP (AP 2) determines that the Co-RTWT is terminated. Accordingly, the non-AP station (STA 2-1) connected to the second AP (AP 2) begins the channel access procedure.

[0275]

[0276] <Multi-link operation>

[0277] In Wi-Fi 7's EHT (Extremely High Throughput), MLDs are defined. An MLD refers to a logical entity containing one or more STAs, and an AP MLD may be affiliated with one or more APs (AP STAs), and a non-AP (STA) MLD may be affiliated with one or more non-AP STAs.

[0278] FIG. 21 shows the multi-link operation of a multi-link device (MLD) according to an embodiment of the present invention.

[0279] In the embodiment of FIG. 21, the AP MLD and the non-AP MLD have three wireless network interfaces. The wireless network interfaces are, respectively, APs belonging to the AP MLD (the first AP, the second AP, and the third AP) or non-AP stations belonging to the non-AP MLD (the first non-AP station, the second non-AP station, and the third non-AP station). The AP MLD and the non-AP MLD operate on multiple links and are connected via three links in the embodiment of FIG. 21. The AP and non-AP stations operating on each link can perform channel access and PPDU transmission / reception in the same manner as a wireless LAN terminal. The AP MLD and the non-AP MLD connected via multiple links can achieve a higher maximum transmission speed by performing communication more frequently than AP and non-AP stations connected via a single link, or by performing communication using multiple links simultaneously. The AP MLD and the non-AP MLD set up multiple links through a multi-link setup process.

[0280] <AP MLD와 non-AP MLD 간 링크 설정>

[0281] Each AP belonging to an AP MLD can operate an independent Basic Service Set (BSS), and the operating bandwidth and operating channels of the BSSs operated by the APs may differ. When an AP MLD and a non-AP MLD are associated, setup can be performed between multiple APs belonging to a single AP MLD and multiple non-AP STAs belonging to a single non-AP MLD. In this case, since each AP belonging to the AP MLD operates a BSS on its own link (operating channel), the non-AP MLD connected to each of the multiple APs belonging to the single AP MLD performs a Multi-Link setup. The AP MLD and non-AP MLD defined in Wi-Fi 7 can perform a Multi-Link setup connected across multiple links.

[0282] Each MLD can have up to 15 STAs (AP STAs, non-AP STAs) attached. That is, 15 APs can be attached to an AP MLD, and each of the 15 APs operates an independent BSS. In this case, each AP attached to the AP MLD provides a level of service equivalent to that of a conventional Wi-Fi AP. That is, each AP attached to the AP MLD functions as an independent AP and can perform services for non-AP STAs not attached to the MLD (e.g., legacy non-AP STAs). In this case, each AP attached to the AP MLD operates on a mutually independent Link, and the meaning of the Link refers only to the operating channel in which each AP operates, not a Link that distinguishes between 2.4 / 5 / 6 GHz. That is, the first AP attached to the AP MLD operates on the first Link, and the second AP can operate on the second Link. At this time, the first Link where the first AP is operated and the second Link where the second AP is operated can both be located in the 6 GHz band.

[0283] Furthermore, AP MLDs and non-AP MLDs can complete setup on multiple links through a Multi-Link setup procedure performed on a specific link. In this context, the Multi-Link setup procedure refers to the exchange of Multi-Link Probe Request / Response and Multi-Link Association Request / Response frames, etc., performed to establish a connection for one or more links.

[0284] When two MLDs are connected via multiple links, it is possible for the two MLDs to operate the traffic transmitted and received through each link separately. This may be achieved through TID-to-Link mapping negotiations performed between the two MLDs or by applying the TID-to-Link mapping status instructed by the AP MLD. In this case, the TID-to-Link mapping status instructed by the AP MLD to non-AP MLDs is indicated by management frames (e.g., Beacon or Probe Response frames) transmitted by the AP MLD, and non-AP MLDs associated with the AP MLD through at least one link must operate each link according to the TID-to-Link mapping instructed by the AP MLD. However, if a new TID-to-Link mapping negotiation is performed between the AP MLD and the non-AP MLD, the traffic (MPDU) of each TID may be transmitted and received through different links according to the method determined by the new TID-to-Link mapping negotiation. For example, if an AP MLD and a non-AP MLD are connected through two links, and TIDs 0 to 3 are mapped to Link 1 and TIDs 4 to 7 are mapped to Link 2, then the AP MLD and the non-AP MLD must transmit and receive only MPDUs with TIDs 0 to 3 through Link 1, and transmit and receive MPDUs with TIDs 4 to 7 through Link 2.

[0285] If the AP MLD has not indicated a separate TID-to-Link mapping state and there is no TID-to-Link mapping performed between the AP MLD and the non-AP MLD, the AP MLD and the non-AP MLD have a Default TID-to-Link mapping state. The Default TID-to-Link mapping state means that all TIDs are mapped to each Link, and in this case, the AP MLD and the non-AP MLD send and receive MPDUs of all TIDs (TID = 0 to 7) on each Link.

[0286]

[0287] <Cross-Link Co-RTWT Consultation>

[0288] The Co-RTWT consultation process described below is described as an operation performed between Co-RTWT request / response APs for the sake of convenience of explanation, but the Co-RTWT consultation process can be performed by the Co-RTWT request AP MLD (the AP MLD to which the Co-RTWT request AP belongs) and the Co-RTWT response AP MLD (the AP MLD to which the Co-RTWT response AP belongs).

[0289] An AP that wishes to strengthen protection for the Limited Target Wake Time (Restricted TWT, R-TWT) SP operated by the AP's BSS may attempt Co-RTWT negotiation with other APs. At this time, Co-RTWT agreement may be performed between AP MLDs. For example, the first AP of the first AP MLD and the fourth AP of the second AP MLD may perform frame exchange to carry out multi-AP coordination operations. In this case, the coordination operations may include Co-RTWT, Co-TDMA, Co-SR, and Co-BF. Through this, coordination operations can be performed not only between the first AP and the fourth AP, but also between an AP other than the first AP included in the first AP MLD and an AP other than the fourth AP included in the second AP MLD. In this case, coordination between AP MLDs may require operations and information other than those performed during link establishment between the AP MLD and the non-AP MLD. For the sake of convenience of explanation, the AP MLD transmitting the coordination action request is referred to as the coordination request AP MLD, and the MLD responding to the coordination action request is referred to as the coordination response AP MLD.

[0290] Specifically, Co-RTWT negotiation and Co-RTWT operation can be performed only if the coordination request AP MLD and the coordination response AP MLD operate on links within the same band. However, the AP MLD performing the coordination operation does not know information regarding the link of the counterpart AP MLD. Therefore, the AP MLD intending to perform the coordination operation may exchange operational information between AP MLDs prior to the coordination operation. The operational information may include information regarding the links performing multi-AP coordination with the coordination response AP MLD, such as the ID of each link, the operating band of each link, the operating bandwidth of each link, or whether each link supports coordination operation.

[0291] When the coordination request AP MLD and the coordination response AP MLD operate on the same link, and the AP of the coordination request AP MLD and the AP of the coordination response AP MLD on that link support coordination operations, coordination operations can be performed. Additionally, when the coordination request AP MLD and the coordination response AP MLD operate on the same link, the coordination request AP MLD can proceed with coordination negotiation. The fact that the links of the coordination request AP MLD and the coordination response AP MLD are the same may indicate that the primary 20 MHz location of one AP belonging to the coordination request AP MLD is the same as the primary 20 MHz location of one AP belonging to the coordination response AP MLD. In another specific embodiment, the fact that the links of the coordination request AP MLD and the coordination response AP MLD are the same may indicate that the operating band (BW) of one AP belonging to the coordination request AP MLD, e.g. 2.4 GHz, 5 GHz, or 6 GHz, is the same as the operating band of the AP belonging to the coordination response AP MLD, and that the operating bands overlap. In a specific embodiment, the coordination request AP MLD may transmit a coordination operation request for a link other than the link transmitting the coordination operation request, such as a Co-RTWT request. At this time, the coordination request AP MLD may transmit a request for a coordination operation performed on one or more links. Accordingly, coordination operation consultation for multiple links may be performed on a single link. For example, the first AP of the first AP MLD operating in the 5 GHz band may transmit a Co-RTWT consultation request to the third AP of the second AP MLD operating in the 5 GHz band. At this time, the Co-RTWT consultation may be for the second AP of the first AP MLD operating in the 6 GHz band and the fourth AP of the second AP MLD operating in the 6 GHz band.

[0292] The coordination request AP MLD can obtain the previously described operational information of the coordination response AP MLD through multi-AP discovery prior to coordination consultation. Additionally, the coordination request AP MLD can obtain operational information from the broadcast management frame transmitted by the coordination response AP MLD. The broadcast management frame may be a beacon frame or a probe response frame in which the RA field is a wildcard. Furthermore, the broadcast management frame may include an element containing operational information. In this case, the element may be a Neighbor Report element or a Multi-Link element.

[0293] The coordination request AP MLD can send a coordination request after checking the operation information of the coordination response AP MLD. This is because coordination is impossible if there are no overlapping links between the link where the coordination request AP MLD operates and the link where the coordination response MLD operates, or if the coordination response AP MLD does not support coordination.

[0294] When the coordination request AP MLD transmits a coordination request to the coordination response AP MLD, it may indicate the link on which coordination is to be performed. At this time, the coordination request AP MLD may indicate the link on which coordination is to be performed using an ID from the link ID set of the coordination response AP MLD. Specifically, the coordination request AP MLD may obtain operational information of the coordination response AP MLD according to the embodiments described above. Based on the obtained operational information, the coordination request AP MLD may determine whether the coordination response AP MLD can perform a coordination operation and the link on which the coordination operation will be performed. If the coordination response AP MLD can perform a coordination operation, the coordination request AP MLD may transmit information indicating the link on which the coordination operation will be performed and the coordination request to the coordination response AP MLD. The information indicating the link on which the coordination operation will be performed may be an ID indicating the corresponding link from the link ID set of the coordination response AP MLD. Other coordination negotiation operations may be applied using the embodiments regarding the Co-RTWT negotiation operations described above. If Co-RTWT consensus is established, the coordination response AP MLD may include a TWT element indicating the R-TWT for Co-RTWT in the beacon of the link specified in the consultation request.

[0295] FIG. 22 shows a Co-RTWT consultation between a Co-RTWT request AP MLD and a Co-RTWT response AP MLD according to an embodiment of the present invention.

[0296] In the embodiment of FIG. 22, the first AP MLD (AP ML1) includes a first AP (AP 1-1), a second AP (AP 1-2), and a third AP (AP 1-3), and each of the first AP (AP 1-1), the second AP (AP 1-2), and the third AP (AP 1-3) operates in a first link (Link 1) in the 2.4 GHz band, a second link (Link 2) in the 5 GHz band, and a third link (Link 3) in the 6 GHz band. The second AP MLD (AP ML2) includes the fourth AP (AP 2-1), the fifth AP (AP 2-2), and the sixth AP (AP 2-3), and each of the fourth AP (AP 2-1), the fifth AP (AP 2-2), and the sixth AP (AP 2-3) of the second AP MLD (AP ML2) operates on the fourth link (Link 4) in the 2.4 GHz band, the fifth link (Link 5) in the 5 GHz band, and the sixth link (Link 6) in the 6 GHz band. The first AP (AP 1-1) and the fourth AP (AP 2-1) have overlapping operating bandwidths in the 2.4 GHz band. Additionally, the second AP (AP 1-2) and the fifth AP (AP 2-2) have overlapping operating bandwidths in the 5 GHz band. In addition, the second AP (AP 1-2) and the fifth AP (AP 2-2) support Co-RTWT operation.

[0297] The first AP (AP 1-1) transmits a Co-RTWT request frame to the fourth AP (AP 2-1). At this time, the Co-RTWT request frame requests a Co-RTWT consultation between the second AP (AP 1-2) and the fifth AP (AP 2-2), and directs the fifth link (Link 5) using the link ID defined by the link ID set of the second AP MLD (AP MLD2). Upon receiving the Co-RTWT request frame, the fourth AP (AP 2-1) transmits a Co-RTWT response frame to the first AP (AP 1-1) instructing it to accept the Co-RTWT. The fifth AP (2-2) transmits a beacon frame containing a TWT element instructing the R-TWT for the Co-RTWT.

[0298] Additionally, even if the coordination request AP MLD does not know the operational information of the coordination response AP MLD, the coordination request AP MLD may transmit a coordination request. In this case, the coordination request may include information regarding the link for which the coordination request AP MLD requests the performance of a coordination operation. The information regarding the link may include at least one of information regarding the bandwidth where the link is established or the operating bandwidth of the link. The coordination response AP MLD may determine whether it can perform the requested coordination operation based on the received information regarding the link. Specifically, the coordination response AP MLD may determine whether the link indicated by the coordination operation request overlaps with the bandwidth of the link on which the coordination response AP MLD operates. Additionally, the coordination response AP MLD may determine whether the coordination response AP MLD supports the coordination operation on the link indicated by the coordination operation request. If the requested coordination operation cannot be performed, the coordination response AP MLD may transmit a coordination response instructing a rejection. If the requested coordination operation can be performed, the coordination response AP MLD may transmit a coordination response instructing an acceptance.

[0299]

[0300] <Co-RTWT 파라미터>

[0301] Fig. 23 explains the method of indicating information exchanged between the Co-RTWT request AP and the Co-RTWT response AP in the Co-RTWT consultation. The embodiment explained in Fig. 23 can be applied in the same way to the Co-RTWT request AP MLD and Co-RTWT response AP MLD described above.

[0302] FIG. 23 shows the format of elements exchanged in a Co-RTWT consultation according to an embodiment of the present invention.

[0303] Specifically, the Co-RTWT request AP may transmit a negotiation request frame requesting Co-RTWT negotiation. In this case, the negotiation request frame may be an individually addressed management frame. Additionally, the request frame may include information regarding the R-TWT that is the target of the Co-RTWT request, information instructing actions necessary for the protection of the Co-RTWT, such as setting a quiet interval, or information regarding the link on which the Co-RTWT will be performed. To this end, the request frame may include an element that modifies the format of a TWT element.

[0304] FIG. 23(a) shows the format of a TWT element used in a Co-RTWT consultation according to an embodiment of the present invention. FIG. 23(b) shows the format of a Control field of a TWT element used in a Co-RTWT consultation according to an embodiment of the present invention. FIG. 23(c) also shows the format of a Co-RTWT Parameter Set field that indicates information regarding Co-RTWT parameters in the TWT Parameter Set included in the TWT Parameter Information of the TWT element used in the Co-RTWT consultation. FIG. 23(d) shows the format of a Request Type field of the Co-RTWT Parameter Set field. In the embodiment of FIG. 23, descriptions of parts identical to or corresponding to the embodiments of FIG. 13 and FIG. 15 are omitted.

[0305] The Control field of a TWT element may include a field indicating whether it contains information regarding Co-RTWT. In this case, this field may be a field not used in Co-RTWT, such as the NDP Paging Indicator / Unavailability Mode field, or a field designated as a reserved field. If the field is a pre-specified value, such as 1, the field may indicate that the TWT element contains information regarding Co-RTWT. Additionally, the Broadcast field, which is the MSB of the Negotiation Type field of the Control field, may be set to 1. This is because Co-RTWT is established based on a broadcast TWT. In another specific embodiment, if the value of the Negotiation Type field is 2 or 3, a value indicating that it is a broadcast, and the value of the Link ID Bitmap Present field is 1, the Control field may indicate that the TWT element contains information regarding Co-RTWT. In another specific embodiment, if the value of the Negotiation Type field is 3, the value of the TWT Information Frame Disabled field is 1, and the value of the Reserved field is 1, it may indicate that the TWT element contains information regarding Co-RTWT.

[0306] The Co-RTWT requesting AP can transmit a Co-RTWT consensus request frame with a value of 3 in the Negotiation Type field. This value (Negotiation Type: 3) is set to manage the membership of the broadcast TWT, and is configured when the TWT scheduling AP transmits existing Broadcast TWT information to the TWT scheduling station or when the TWT scheduling station transmits a management frame specifying an individual address to the TWT scheduling AP. Since the Co-RTWT requesting AP transmits a management frame specifying an individual address to the Co-RTWT responding AP to protect the Co-RTWT, the value of the Negotiation Type field can be set to 3.

[0307] The Co-RTWT Parameter Set field may be used to indicate information regarding the Co-RTWT specified by the Co-RTWT requesting AP or information regarding the Co-RTWT specified by the Co-RTWT responding AP in Co-RTWT consultation. The Co-RTWT Parameter Set field may include at least one of the following: a Request Type field, a 2-octet Target Wake Time field, a 1-octet Nominal Minimum TWT Wake Duration field, a 2-octet TWT Wake Interval Mantissa field, a 2-octet Broadcast TWT Info field, or a 0- or 2-octet Link ID Bitmap field. The Co-RTWT Requesting AP may indicate time information for the R-TWT schedule for which it requests protection. This may utilize methods defined in conventional Wi-Fi standards. The Co-RTWT requesting AP may indicate a TWT start time, which specifies the start time of the Co-RTWT service period, in the Target Wake Time field. The TWT start time may be obtained by adding the value of the TSF offset subfield. After the Co-RTWT consensus, when the Co-RTWT responding AP instructs a non-AP station belonging to the Co-RTWT responding AP's BSS to R-TWT for Co-RTWT using a beacon frame, it can set the value of the TWT Wake Time field based on the value of the TSF offset subfield. The unit of time for the value of the TWT Wake Time field can be obtained through the Wake Duration Unit subfield described in FIG. 13 and FIG. 15 (b). When the value of the Wake Duration Unit subfield is 0, the value of the TWT Wake Time field is 256 µs. When the value of the Wake Duration Unit subfield is 1, the value of the TWT Wake Time field is 1 TU.The Broadcast TWT Info field may include the field format described in FIG. 15 (e) or the field described in FIG. 13 (g). The value of the Broadcast TWT ID subfield may be indicated by the ID of the R-TWT schedule directed by the Co-RTWT requesting AP. Additionally, the Co-RTWT requesting AP may use the Broadcast TWT Persistence subfield to instruct the Co-RTWT responding AP to protect the R-TWT until a certain date. The Co-RTWT coordinated AP may calculate the protection period of the Co-RTWT requesting AP's R-TWT by multiplying the value of the Broadcast TWT Persistence subfield by TBTT. If the value of the Broadcast TWT Persistence subfield is 255, the Broadcast TWT Persistence subfield may indicate that the Co-RTWT responding AP is instructed to protect the R-TWT schedule until a Co-RTWT Teardown operation is performed.

[0308] In order to protect R-TWT schedules for multiple links, the Co-RTWT requesting AP MLD can conduct Co-RTWT consultation with the Co-RTWT responding AP MLD using an AP (belonging to the Co-RTWT requesting AP MLD) capable of communicating with the Co-RTWT responding AP MLD. At this time, the AP belonging to the Co-RTWT requesting AP MLD can request protection for R-TWT schedules of other links owned by the AP MLD to which it belongs, rather than its own links. The Co-RTWT requesting AP can indicate the link where Co-RTWT will be performed using the Link ID Bitmap field of FIG. 23 (c). The Link ID Bitmap field has two octets only when the value of the Link ID Bitmap Present subfield of the Control field is 1. The Co-RTWT requesting AP MLD can verify the link information of the Co-RTWT responding AP MLD and obtain the link ID set of the Co-RTWT responding AP MLD. The Co-RTWT request AP MLD can set the bit corresponding to the link of the Co-RTWT response AP MLD to perform Co-RTWT in the Link ID Bitmap field to 1. The Co-RTWT response AP MLD that receives the Co-RTWT Parameter Set field indicated by the Link ID Bitmap field can perform Co-RTWT on the link corresponding to the Link ID indicated by the Link ID Bitmap field. In another specific embodiment, the Link ID Bitmap subfield may be a subfield indicating a specific value rather than a bitmap format. For example, if the Co-RTWT response AP MLD requests R-RTWT schedule protection for a link with a Link ID of 14, the LLink ID Bitmap field substitution field may indicate 14. The Link ID field, which is the subfield, may be composed of 4 bits.

[0309] The Request Type field of the Co-RTWT Parameter Set field may include a 1-bit TWT Request field, a 3-bit TWT Setup Command field, a 1-bit Last Co-RTWT Parameter Set field, a 5-bit TWT Wake Exponent field, an m-bit Quit Interval Setup Request field, and a l-bit TSF Offset field. A Co-RTWT requesting AP may request protection for one or more R-TWT schedules. To protect multiple R-TWT schedules, the Co-RTWT requesting AP may include multiple Co-RTWT Parameter Set fields that indicate R-TWT information in the Co-RTWT consultation request frame. At this time, to indicate the end of the Co-RTWT Parameter Set, the Co-RTWT requesting AP may indicate the end of the TWT element to the Co-RTWT responding AP by setting the value of the Last Co-RTWT Parameter Set subfield to 1. As previously explained, when the Co-RTWT requesting AP requests protection of the Co-RTWT response AP's R-TWT schedule, it may request the setting of an overlapping quiet interval. In this case, the Co-RTWT requesting AP may specify a pre-specified value for the Quiet Interval Setup Request field to request the setting of an overlapping quiet interval. The pre-specified value may be 1. If the value of the Quiet Interval Setup Request field is a pre-specified value, the Co-RTWT response AP may set an overlapping quiet interval for 1 TU at the start of the Co-RTWT service period using the Quiet element.

[0310] The TSF Offset field is used to set a value for synchronizing TSF timers between APs. Since the TSF timers of APs belonging to an AP MLD are all different, the difference between them can be indicated by the value of the TSF Offset field. The Co-RTWT requesting AP can set the value of the TSF Offset field by overhearing the beacon frame transmitted by the AP, using the TSF timer value indicated during the M-AP discovery process, or using the value indicated in the broadcast management frame transmitted by the AP. The Co-RTWT responding AP that receives the above TSF Offset field can use the value obtained by adding the value of the TSF Offset subfield to the value of the Target Wake Time field, which indicates the TWT start time, in the TWT element indicating the R-TWT for Co-RTWT. The Co-RTWT coordinated AP can use the value obtained by adding the value of the TSF Offset subfield to the value of the Target Wake Time field to indicate the R-TWT in the beacon frame for the Co-RTWT announcement.

[0311]

[0312] Multi-AP Coordination (MAPC) Framework

[0313] MAPC is a technology designed to improve overall network performance and management efficiency through coordination among multiple APs. By coordinating APs operating on the same primary 20MHz channel, MAPC can reduce interference and improve network performance, such as enhancing medium utilization, increasing wireless LAN reliability, and improving low latency.

[0314] An AP can use a MAPC scheme by establishing consensus on the MAPC scheme with other APs. Consensus on the MAPC scheme can be established through consultation between APs. There are various types of MAPC schemes. These may include Coordinated TDMA (Co-TDMA), which shares the AP's TXOP through coordination between APs; Coordinated Beamforming (Co-BF), in which an AP coordinates multiple transmission antennas (transmit chains, spatial streams) to provide services to non-AP stations connected to the AP; Coordinated Spatial Reuse (Co-SR), in which APs coordinate their transmission power to provide services to non-AP stations connected to the AP simultaneously; and Co-RTWT, which requests protection of the AP's R-TWT schedule from the OBSS AP to protect low-latency traffic.

[0315] The MAPC framework may include three stages. The MAPC framework may include MAPC discovery to verify the capability for the MAPC, MAPC consultation to consult on the MAPC scheme, and a scheme-specific procedure to perform the MAPC scheme.

[0316] FIG. 24 shows a MAPC framework according to an embodiment of the present invention.

[0317] The first AP (AP 1) and the second AP (AP 2) support MAPC. The first AP (AP 1) transmits a MAPC discovery request frame to find an AP that supports MAPC (1102). The discovery request frame may indicate the address of an individual AP, for example, the address of the second AP (AP 2), or it may be a broadcast frame. Upon receiving the discovery request frame, the second AP (AP 2) transmits a MAPC response frame to the first AP (AP 1) in response to the discovery request frame (1103). The exchange of the discovery request frame and the discovery response frame may be referred to as the MAPC discovery procedure (1101). Through the exchange of the discovery request frame and the discovery response frame, the first AP (AP 1) and the second AP (AP 2) can exchange information related to MAPC, including MAPC capabilities. Through this, the first AP (AP 1) and the second AP (AP 2) can determine which of the MAPC schemes they can consult on.

[0318] The first AP (AP 1) conducts consultation with the second AP (AP 2) regarding a MAC scheme. At this time, the first AP (AP 1) can determine the MAPC scheme to consult with the second AP (AP 2) based on the acquired information regarding the MAPC of the second AP (AP 2). The first AP (AP 1) transmits a MAPC consultation request frame to the second AP (AP 2) (1105). The MAPC consultation request frame indicates the address of the individual AP and the address of the second AP (AP 2). The MAPC consultation request frame includes information regarding the MAPC scheme for which the first AP (AP 1) requests consultation. The information regarding the MAPC scheme may include information regarding the MAPC scheme capability and the parameters of the requested MAPC scheme.

[0319] Upon receiving the MAPC consultation request frame, the second AP (AP 2) transmits the MAPC consultation response frame to the first AP (AP 1) (1106). The MAPC consultation response frame may indicate acceptance, rejection, or alternative. Accept indicates accepting the MAPC consultation request. Rejection indicates rejecting the MAPC consultation request. Alternate indicates proposing new MAPC scheme parameters for the MAPC consultation request. The exchange of the MAPC consultation request frame and the MAPC consultation response frame may be referred to as the MAPC consultation procedure (1104). In the MAPC consultation procedure (1104), the exchange of the MAPC consultation request frame and the MAPC consultation response frame may be performed one or more times. When MAPC consultation is performed and MAPC consensus is established, the first AP (AP 1) and the second AP (AP 2) perform the MAPC scheme specific procedure according to the MAPC consensus.

[0320] The first AP (AP 1) and the second AP (AP 2) may return to the MAPC consultation procedure (1104) to change parameters for the MAPC scheme or to tear down the MAPC consensus while performing the MAPC scheme-specific procedure. At this time, the first AP (AP 1) or the second AP (AP 2) may transmit a MAPC consultation request frame instructing the change of parameters for the MAPC scheme or the teardown of the MAPC consensus. Additionally, an AP that receives a MAPC consultation request frame instructing the change of parameters for the MAPC scheme and transmits a MAPC consultation response frame accepting it may apply the changed parameters while performing the MAPC scheme-specific procedure.

[0321] In a specific embodiment, the MAPC requesting AP transmitting the MAPC consultation request frame may request consultation only for MAPC schemes supported by the MAPC responding AP transmitting the MAPC consultation response frame. In this case, the MAPC requesting AP may not be allowed to request consultation for MAPC schemes not supported by the MAPC responding AP. Supported by the AP may include not only cases where the capability does not support it, but also cases where it instructs the refusal of the corresponding MAPC operation. For example, the second AP may transmit an MAPC discovery response frame indicating that Co-BF support is impossible and that consensus on Co-SR is impossible. In this case, the first AP may not be allowed to transmit an MAPC consultation request frame requesting Co-BF or Co-SR to the second AP.

[0322]

[0323] <MAPC 디스커버리 절차>

[0324] MAPC discovery is an action for an AP to find an AP capable of performing MAPC operations or to notify that an AP is capable of performing MAPC operations. Specifically, an AP may transmit a MAPC discovery request frame indicating at least one of MAPC capability, parameters common to MAPC, or MAPC scheme-specific parameters. The MAPC discovery request frame may be a frame indicating an individual address or a broadcast frame.

[0325] An AP that receives a MAPC discovery request frame transmits a MAPC discovery response frame. The MAPC discovery response frame may indicate the individual address of the AP that transmitted the MAPC discovery response frame, or it may be a broadcast frame. The MAPC discovery response frame may indicate at least one of the MAPC capabilities of the AP transmitting the MAPC discovery response frame, parameters that apply commonly to MAPC, or MAPC scheme-specific parameters.

[0326] MAPC capability may include which MAPC schemes the AP can perform. Specifically, MAPC capability may include at least one of whether it can respond with a TB PPDU during MAPC operation, whether it supports Co-BF, whether it supports Co-SR, whether it supports Co-TDMA, or whether it supports Co-RTWT.

[0327] Parameters commonly applicable to MAPC may include information commonly required when an AP performs MAPC operations. Specifically, parameters commonly applicable to MAPC may include information indicating whether the AP will establish consensus for a specific MAPC scheme. For example, parameters commonly applicable to MAPC may include information regarding at least one of whether the AP will establish consensus for Co-BF, Co-SR, Co-TDMA, or Co-RTWT. Additionally, parameters commonly applicable to APC may include information indicating the MAPC schemes that the AP can establish.

[0328] MAPC scheme-specific parameters can indicate the capabilities that an AP can perform in individual MAPC scheme operations. MAPC scheme-specific parameters may include information indicating the minimum length of a TXOP that an AP will be allocated during a Co-TDMA operation. This allows the AP to reduce the likelihood that it will receive a TXOP share but fail to complete the frame exchange.

[0329]

[0330] <MAPC 협의 절차>

[0331] An AP may perform MAPC consultation procedures. Specifically, an AP may perform MAPC consultation procedures after the MAPC discovery procedure or to update or release established MAPC consensus. As previously explained, an AP requesting an MAPC may transmit a MAPC consultation request frame based on the MAPC schemes supported by the AP responding to an MAPC. In this case, the AP requesting an MAPC may not be allowed to request consultation on a MAPC scheme that is not supported by the AP responding to an MAPC. Support by an AP may include not only cases where its capabilities do not support it, but also cases where it has instructed the refusal of the corresponding MAPC operation. This can reduce unnecessary MAPC consultation attempts.

[0332] A MAPC requesting AP may transmit a MAPC negotiation request frame instructing negotiation of one or more MAPC scheme actions. The MAPC negotiation request frame may include information regarding the parameters of the MAPC scheme actions requesting negotiation. Upon receiving the MAPC negotiation request frame, a MAPC responding AP must transmit a response to the MAPC negotiation request frame. In this case, the MAPC responding AP may transmit a MAPC negotiation response frame instructing acceptance, rejection, or proposal regarding the one or more MAPC scheme actions requested by the MAPC negotiation request frame. Additionally, the MAPC negotiation response frame may include a status code. If the MAPC negotiation response frame accepts one or more MAPC scheme actions, the status code may indicate success. If the MAPC negotiation response frame does not accept any of the MAPC scheme actions, the status code may indicate failure.

[0333] The MAPC negotiation response frame may include Profile sub-elements specific to the MAPC scheme indicated in the MAPC negotiation request frame. The Profile sub-element may indicate acceptance, rejection, or an alternative regarding the consensus request of the MAPC scheme to which it corresponds. If the MAPC negotiation response frame indicates acceptance or rejection of the MAPC scheme's consensus request, the MAPC negotiation response frame may not include information regarding the MAPC scheme. If the MAPC negotiation response frame indicates an alternative regarding the MAPC scheme's consensus request, the MAPC negotiation response frame may include information regarding the MAPC scheme. If the MAPC requesting AP accepts the MAPC scheme proposed as an alternative by the MAPC responding AP, negotiation regarding the MAPC scheme may be established. This can increase the efficiency of MAPC negotiation.

[0334] FIG. 25 shows the format of a MAPC element and the format of a field included in the element format according to an embodiment of the present invention.

[0335] FIG. 25(a) shows the MAPC element format. FIG. 25(b) shows the format of the MAPC Control field. FIG. 25(c) shows the format of the MAPC Common Info field. FIG. 25(d) shows the format of the MAPC Capabilities field of the MAPC Common Info field. FIG. 25(e) shows the format of the MAPC Parameters field of the MAPC Common Info field. FIG. 25(f) shows the format of the MAPC Scheme Info field. FIG. 25(g) shows the format of the MAPC Scheme Control field of the MAPC Scheme Info field. FIG. 25(h) shows the format of the MAPC Scheme Request field. FIG. 25(i) shows the format of the MAPC Request Control field of the MAPC Scheme request field.

[0336] A MAPC element may include a 1-octet Element ID field, a 1-octet Length field, a 1-octet Element ID Extension field, a 1-octet MAPC Control field, a MAPC Common Info field, and a MAPC Schemes Info field. The Element ID field and the Element ID Extension field are set to values ​​indicating that the element is a MAPC element. The Length field may indicate the total length of the MAPC element. The MAPC Control field may indicate common control information for managing behavior within the MAPC framework. The MAPC Common Info field may indicate at least one of the capabilities for MAPC schemes supported by the AP, the availability of TB PPDU responses, or MAPC schemes capable of establishing consensus. The MAPC Schemes Info field may include a field indicating information about at least one MAPC scheme. Specifically, the MAPC Schemes Info field may include a Per-schemes sub-element indicating information per MAC scheme.

[0337] The MAPC Control field may include a 1-bit AP ID Present field and a 7-bit Reserved field. The AP ID Present field is a field that indicates whether the AP ID field appears within the MAPC Common Info field.

[0338] The MAPC Common Info field may include a MAPC Common Info Length field of 1 octet, a MAPC Capabilities field of 2 octets, a MAPC Parameters field of 2 octets, and an AP ID field of 0 or 2 octets. The MAPC Common Info Length field may indicate the length of the MAPC Common Info field as the AP ID Present field of FIG. 25 (b) is indicated as 0 or 1. The MAPC Capabilities field may indicate the capabilities for the MAPC operations of the AP. The MAPC Parameters field may indicate which MAPC schemes the AP can establish consensus on.

[0339] The MAPC Capabilities field may include at least one of a 1-bit AP TB PPDU Response Supported field, a 1-bit Co-BF Supported field, a 1-bit Co-SR Supported field, a 1-bit Co-TDMA Supported field, a 1-bit Co-RTWT Supported field, a 1-bit Co-CR Supported field, or a 10-bit Reserved field. The AP TB PPDU Response Supported field may indicate whether the AP can transmit an initial control frame to multiple APs and receive a response to the initial control frame. The AP TB PPDU Response Supported field may apply only to pre-specified MAC schemes. The Co-BF / Co-SR / Co-TDMA / Co-RTWT / Co-CR Supported fields may indicate the MAPC schemes supported by the AP.

[0340] The MAPC Parameters field may include at least one of a 1-bit Co-BF Agreement Establishment Enabled subfield, a 1-bit Co-SR Agreement Establishment Enabled subfield, a 1-bit Co-TDMA Agreement Establishment Enabled subfield, a 1-bit Co-RTWT Agreement Establishment Enabled subfield, a 1-bit Co-CR Agreement Establishment Enabled subfield, or an 11-bit Reserved field. Each field may indicate whether the AP supports the establishment of consensus for the MAPC scheme corresponding to each field.

[0341] The MAPC Scheme Info field may include at least one Per-Scheme Profile subelement. Each subelement may include at least one of a one-octet Subelement ID field, a one-octet Length field, a one-octet MAPC Scheme Control field, a MAPC Scheme Parameter Set field, or a MAPC Scheme Request Set field. The Subelement field may indicate a Per-Scheme Profile subelement. The Length field may indicate the length of the element. The MAPC Scheme Control field may indicate which MAPC scheme the subelement belongs to. The MAPC Scheme Parameter Set field may indicate parameters for the MAPC scheme indicated in the MAPC Scheme Control field. Specifically, the MAPC Scheme Parameter Set field may indicate the capabilities of the AP for each MAPC scheme. The MAPC Scheme Request Set field may appear when a Per-Scheme Profile sub-element is included in the MAPC consensus frame. The MAPC Scheme Request Set field can direct a request for MAPC consensus establishment for the MAPC scheme specified in the MAPC Scheme Control field.

[0342] The MAPC Scheme Control field may include a 4-bit MAPC Scheme Type field or a 4-bit Reserved field. The MAPC Scheme Type field may indicate which MAPC scheme the corresponding Per-scheme Profile subelement is for. If the value of the MAPC Scheme Type field is 0, the Per-scheme Profile subelement may correspond to the Co-BF profile. If the value of the MAPC Scheme Type field is 1, the Per-scheme Profile subelement may correspond to the Co-SR profile. If the value of the MAPC Scheme Type field is 2, the Per-scheme Profile subelement may correspond to Co-TDMA. If the value of the MAPC Scheme Type field is 3, the Per-scheme Profile subelement may correspond to Co-RTWT. If the value of the MAPC Scheme Type field is 4, the Per-scheme Profile subelement may correspond to Co-CR.

[0343] The MAPC Scheme Request field may include at least one of a 1-octet MAPC Request Control field, a 0 or 1-inch MAPC Per-Scheme Info field, or a MAPC Request Parameter Set field. The MAPC Request Control field may indicate the type of action for consensus of the MAPC scheme corresponding to the MAPC Scheme Request field and the existence of the MAPC Per-Scheme Info field. The MAPC Per-Scheme Info field may indicate information for a MAPC scheme that requires some information to be indicated among the MAPC schemes. The MAPC Request Parameter Set field may indicate MAPC scheme information for a consensus establishment request or update for the MAPC scheme indicated in the MAPC scheme Type field.

[0344] The MAPC Request Control field may include at least one of the 3-bit MAPC Operation Type field, the 1-bit MAPC Per-Scheme Info Present field, or the 4-bit Reserved field. The MAPC Operation Type field may indicate which MAPC operation the MAPC scheme corresponding to the MAPC Request Control field is. The values ​​that can be set for the MAPC Operation Type field may be limited per MAPC negotiation frame. The case of the MAPC negotiation request frame is described first. If the value of the MAPC Operation Type field is 0, the MAPC Operation Type field may indicate that the MAPC negotiation request frame is a request to establish consensus for the MAPC scheme. If the value of the MAPC Operation Type field is 1, the MAPC Operation Type field may indicate that the MAPC negotiation request frame is a parameter update for the MAPC scheme. If the value of the MAPC Operation Type field is 2, the MAPC Operation Type field may indicate that the MAPC negotiation request frame is a release request for the MAPC scheme. The case of the MAPC negotiation response frame is described next. If the value of the MAPC Operation Type field is 3, the MAPC Operation Type field may indicate that the MAPC consultation response frame is an acceptance of a request to establish consensus for the MAPC scheme or a parameter update. If the value of the MAPC Operation Type field is 4, the MAPC Operation Type field may indicate that the MAPC consultation response frame is a rejection of a request to establish consensus for the MAPC scheme or a parameter update.If the value of the MAPC Operation Type field is 5, the MAPC Operation Type field may indicate that the MAPC negotiation response frame is a request to establish consensus on the MAPC scheme or an alternative proposal for a parameter update. The MAPC negotiation response frame may include a MAPC request parameter set depending on the value of the MAPC Operation Type field. Specifically, if the value of the MAPC Operation Type field indicates acceptance or rejection as described above, the MAPC negotiation response frame may not include a MAPC request parameter set. If the value of the MAPC Operation Type field indicates an alternative proposal as described above, the MAPC negotiation response frame may include a MAPC request parameter set. In this case, the MAPC negotiation response frame may indicate that the MAPC responding AP can accept a MAPC negotiation that specifies a parameter set identical to the MAPC request parameter set included in the MAPC negotiation response frame.

[0345]

[0346] FIG. 26 shows the format of a MAPC discovery request / response frame and a MAPC consultation request / response frame according to an embodiment of the present invention.

[0347] FIG. 26(a) shows the format of the MAPC discovery request frame and the MAPC discovery response frame. FIG. 26(b) shows the format of the MAPC consultation request frame. FIG. 26(c) shows the format of the MAPC consultation response frame.

[0348] A MAPC Discovery Request / Response frame may include at least one of a 1-octet Category field, a 1-octet Public Action field, a 1-octet Dialog Token field, or a MAPC Discovery Info field. The Category field and the Public Action field are set to values ​​indicating the MAPC Discovery Request / Response frame. The Dialog Token field is set to any non-zero value set by the AP transmitting the MAPC Discovery Request frame. The value of the Dialog Token field in the MAPC Discovery Response frame must be indicated by the same value as the Dialog Token field in the MAPC Discovery Request frame. The MAPC Discovery Info field includes a MAPC element, and the MAPC Scheme Info field (Per-Scheme Profile sub-element) of the MAPC element may not include a MAPC Scheme Request Set field.

[0349] The MAPC negotiation request frame may include at least one of a 1-octet Category field, a 1-octet Public Action field, a 1-octet Dialog Token field, or a MAPC Negotiation Info field. The Category field and the Public Action field are set to a value indicating the MAPC negotiation request frame. The Dialog Token field is set to any non-zero value selected by the MAPC request AP. The MAPC Negotiation Info field includes a MAPC element, and the MAPC element may include at least one Per-Scheme Profile sub-element. Additionally, the Per-Scheme Profile sub-element may be limited to necessarily including a MAPC Scheme Request set field.

[0350] The MAPC negotiation response frame may include at least one of the following: a Category field of one octet, a Public Action field of one octet, a Dialog Token field of one octet, a Status Code field of two octets, or a MAPC Negotiation Info field. The Dialog Token field must be specified with the same value as the Dialog Token value specified in the MAPC negotiation request frame received by the MAPC response AP. The Status Code field may indicate acceptance or rejection of the MAPC scheme. If at least one MAPC scheme is successfully negotiated, the Status Code field may indicate success. Additionally, the MAPC Negotiation Info field may include MAPC elements. The MAPC elements may include all Per-Scheme Profile sub-elements specified in the MAPC negotiation request frame received by the MAPC response AP. Depending on the value set in the MAPC Operation Type field within each Per-Scheme Profile sub-element, the Per-Scheme Profile sub-element may or may not include the MAPC Request Parameter Set field.

[0351]

[0352] <MAPC Consultation Procedure Using Alternative Proposals>

[0353] The previously described approach of the MAPC responding AP proposing an alternative to perform MAPC negotiation may be difficult to apply to some MAPC schemes. Co-RTWT is intended to ensure the stability of established existing schedules and the low-latency transmission of low-latency traffic. Due to these characteristics, the MAPC negotiation process for Co-RTWT may become significantly more complex or difficult to establish if the MAPC responding AP proposes an alternative to the negotiation request. For example, if the MAPC responding AP proposes an alternative and the MAPC requesting AP accepts it, the MAPC requesting AP must adjust the R-TWT schedule to match the alternative proposal or create a new R-TWT schedule. Consequently, the MAPC requesting AP requires frame exchanges to modify or reconfigure the R-TWT, which may compromise the objective of low-latency traffic transmission.

[0354] FIG. 27 shows the operation of the MAPC response AP when the MAPC response AP proposes an alternative during the Co-RTWT consultation process according to an embodiment of the present invention.

[0355] The first AP (AP 1) transmits a MAPC negotiation request frame instructing a Co-RTWT negotiation request to the second AP (AP 2). Upon receiving the MAPC negotiation request frame (1401), the second AP (AP 2) obtains information regarding the parameters of the Co-RTWT instructed by the Co-RTWT negotiation request and transmits a MAPC negotiation response frame (1402) to the first AP (AP 1) proposing a Co-RTWT having parameters different from those of the proposed Co-RTWT. The first AP (AP 1) receives the MAPC negotiation response frame (1403). If the first AP (AP 1) accepts the alternative proposed Co-RTWT, the first AP (AP 1) transmits a beacon frame (1403) to set the R-TWT according to the proposed Co-RTWT. The time at which the R-TWT is set is when the value indicated by the Broadcast TWT Persistence field of the beacon frame becomes 0. Therefore, a considerable amount of time may be required. Additionally, a membership registration process for the newly established R-RTWT may also be required. The first AP (AP 2) transmits a MAPC consultation request frame (1404) to the second AP (AP 2) instructing a Co-RTWT request corresponding to the parameters of the proposed Co-RTWT. The second AP (AP 2) transmits a MAPC consultation response frame (1405) to the first AP (AP 1) instructing acceptance of the Co-RTWT request. To prevent such problems, the following embodiments may be applied.

[0356]

[0357] A MAPC responding AP may not be permitted to respond to a MAPC consultation request frame requesting consultation of a pre-specified MAPC scheme with a MAPC consultation response frame indicating an alternate proposal. A pre-specified MAPC scheme may be Co-RTWT. In this case, the MAPC responding AP may only be permitted to transmit a MAPC consultation response frame indicating acceptance or rejection.

[0358] In another specific embodiment, if a MAPC response AP transmits a MAPC consultation response frame directing a proposal and receives a MAPC consultation request frame directing the MAPC scheme exactly as directed by the MAPC consultation response frame directing the proposal, the MAPC response AP may not be allowed to transmit a MAPC consultation response frame directing an alternative proposal for the said MAPC scheme. In this case, if the MAPC response AP receives a request directing parameters identical to those of the alternative proposal for the said MAPC scheme, the MAPC response AP may be restricted to accepting the request.

[0359] In another specific embodiment, when the MAPC responding AP transmits a MAPC consultation response frame directing a proposal, the MAPC responding AP may include a reason for rejection in the MAPC consultation response frame while directing an alternative proposal. In this case, the MAPC responding AP may include a reason for rejection in the MAPC consultation response frame instead of the MAPC scheme proposed as an alternative. This can help the MAPC requesting AP determine the next action. The reason for rejection may include resource conflicts between APs or inconsistencies with the internal behavior of the MAPC consultation responding AP. In this case, the inconsistency with internal behavior may include at least one of an overlap between the service periods of the R-TWT's TBTT and the Co-RTWT, or an overlap between the service periods of the Co-RTWT and the R-TWT.

[0360] Additionally, when the AP transmits an MAPC consultation response frame directing a proposal, the MAPC response AP may include the reason for rejection in the MAPC consultation response frame while directing a rejection.

[0361] In the embodiments of the alternative proposal or rejection instructions described above, the MAPC response AP may indicate the reason for rejection using the reason code or status code of the MAPC consultation response frame. The MAPC response AP may indicate that the Co-RTWT scheme is rejected due to the R-TWT schedule of the MAPC response AP by indicating a value of a pre-specified code, e.g., 0. In this case, the MAPC response AP may indicate information regarding the R-TWT schedule that constitutes the reason for rejection in the MAPC consultation response frame. The information regarding the R-TWT schedule may include at least one of the interval of the R-TWT service period, the duration of the R-TWT service period, or information regarding the period during which the service period of the Co-RTWT and the service period of the R-TWT overlap. In this case, the information regarding the period during which the service period of the Co-RTWT and the service period of the R-TWT overlap may include information regarding at least one of the start time or end time of the period during which the service period of the Co-RTWT and the service period of the R-TWT overlap. In addition, if the MAPC consultation response frame indicates the reason for rejection and alternatives, the value of the MAPC Operation Type of the MAPC consultation response frame may be 5.

[0362] The MAPC response AP may indicate that the TBTT of the MAPC response AP overlaps with the service period of Co-RTWT and that the Co-RTWT scheme is rejected by indicating a value of a pre-specified code, e.g., 1. In this case, the MAPC response AP may indicate information regarding the TBTT that is the reason for rejection in the MAPC consultation response frame. The information regarding the TBTT may include the TBTT period of the MAPC response AP. In this embodiment, the MAPC response AP may indicate the presentation of an alternative or rejection of the Co-RTWT request when the TBTT of the MAPC response AP overlaps with the service period of Co-RTWT more than a pre-specified number of times.

[0363] The MAPC response AP may indicate that the requested Co-RTWT scheme is rejected because the TWT wake interval of the Co-RTWT is too short by indicating a value of a pre-specified code, e.g., 2. This is because if the TWT wake interval is too short, protection actions for the R-TWT schedule must be performed too frequently. If the start time of the service period of the Co-RTWT schedule occurs more than a pre-specified number of times within the MAPC response AP's beacon interval, the MAPC response AP may determine that the TWT wake interval of the requested Co-RTWT is too short. The pre-specified number can be determined by the MAPC response AP. For example, the pre-specified number may be 2.

[0364] The MAPC response AP may indicate that the requested Co-RTWT scheme is rejected because the protection period of the Co-RTWT is too long by indicating a value of a pre-specified code, e.g., 3. This is because if the protection period is too long, the operational efficiency of the MAPC response AP's BSS may become excessively low. The protection period may be indicated by the value of the Broadcast TWT Persistence field in the MAPC consultation request frame. If the value of the Broadcast TWT Persistence field is greater than or equal to a pre-specified value, the MAPC response AP may determine that the protection period of the requested Co-RTWT is too long. The pre-specified value may be determined by the MAPC response AP. For example, the pre-specified value may be 50 TBTT.

[0365] The MAPC response AP may indicate that the Co-RTWT scheme is rejected for reasons other than those previously described or for reasons not predefined by indicating a value other than a pre-specified value for a specific rejection reason.

[0366] In the embodiments described above, the MAPC Request Parameter Set field of the MAPC consultation response frame may indicate the reason for rejection. Specifically, the Co-RTWT Profile field of the MAPC Request Parameter Set field may indicate information regarding the R-TWT schedule that is the reason for rejection described above. In addition, the Beacon Interval field of the MAPC Request Parameter Set field, or the Co-RTWT Profile and TWT Wake Interval Mantissa field and the TWT Wake Interval Exponent field may indicate information regarding the TBTT that is the reason for rejection described above.

[0367] The field indicating the previously described pre-specified code may be referred to as the Reason Code field. The MAPC Per-Scheme Info field within the MAPC Scheme Info field of the MAPC consultation response frame may include the Reason Code field. Specifically, the MAPC Per-Scheme Info field within the MAPC Scheme Request field of the Per-Scheme Profile sub-element may include the Reason Code field. In another specific embodiment, the MAPC Request Control field within the MAPC Scheme Request field of the MAPC consultation response frame may include the Reason Code field.

[0368] When the value of the MAPC Operation Type field of the MAPC negotiation response frame is 4 or 5, the MAPC negotiation response frame may include a Reason Code field. When the value of the MAPC Operation Type field of the MAPC negotiation response frame is 4, the Reason Code field of the MAPC negotiation response frame may indicate that the MAPC negotiation request is rejected for the reason specified in the Reason Code field. This may indicate that the reason for rejection is that negotiation is impossible. When the value of the MAPC Operation Type field of the MAPC negotiation response frame is 5, the Reason Code field of the MAPC negotiation response frame may indicate that an alternative proposal for the MAPC negotiation request is made for the reason specified in the Reason Code field. This may indicate that the reason for rejection is that negotiation is possible. Additionally, when the value of the MAPC Operation Type field of the MAPC negotiation response frame is 3, the Reason Code field may be a reserved field.

[0369] In another specific embodiment, the MAPC consultation response frame may include a Reason Code Present field indicating the presence or absence of a Reason Code field. If the value of the Reason Code Present field is 1, the MAPC consultation response frame may include the Reason Code field according to the embodiments described above. If the value of the Reason Code Present field is 0, the MAPC consultation response frame may not include the Reason Code field. If the value of the MAPC Operation Type field is 3 or 4, the value of the Reason Code Present field may be 1. Additionally, if the value of the MAPC Operation Type field is 5, the value of the Reason Code Present field may be 0.

[0370] In addition, the Reason Code field can be a 1-octet field.

[0371] Additionally, the Reason Code field may be a bitmap field. In this case, each bit of the bitmap may indicate a reason for rejection corresponding to that bit. In a specific embodiment, the MAPC response AP may use a bitmap to indicate multiple reasons for rejection. In another specific embodiment, even if the MAPC response AP rejects the MAPC consultation request with multiple reasons for rejection, the MAPC response AP may indicate only one reason for rejection. In this case, the MAPC response AP may indicate only the reason for rejection with the highest priority among the multiple reasons for rejection according to a predetermined priority. In yet another specific embodiment, the MAPC response AP may indicate only the reason for rejection with the smallest value among the multiple reasons for rejection.

[0372] The MAPC requesting AP can obtain specific information regarding the reason for rejection from the broadcast management frame transmitted by the MAPC responding AP. The broadcast management frame can be a beacon frame or a probe response frame.

[0373] The MAPC requesting AP may transmit a MAPC negotiation request frame instructing a new Co-RTWT negotiation request based on the reason for rejection. For example, if the reason for rejection is that the Co-RTWT service period and the MAPC response AP's TBTT overlap, the MAPC requesting AP may change the R-RTWT service period and transmit a MAPC negotiation request frame instructing the changed Co-RTWT negotiation request.

[0374] The MAPC request AP obtains the reason for rejection and specific information regarding it to reduce unnecessary renegotiation attempts, and the MAPC response AP can efficiently determine the MAPC schemes and parameters that can be accepted.

[0375] In the embodiments described above, the MAPC response frame may include only information that is the reason for rejection, such as information regarding the R-TWT schedule that is the reason for rejection or information regarding the TBTT that is the reason for rejection, without explicit indication of the reason for rejection.

[0376] FIG. 28 shows that in the frame exchange between the MAPC request AP and the MAPC response AP in the MAPC consultation procedure according to an embodiment of the present invention, the MAPC response AP indicates the reason for rejection of the MAPC consultation request.

[0377] In FIG. 28 (a), the R-TWT service period of the MAPC request AP and the R-TWT service period of the MAPC response AP partially overlap (1501). Therefore, in FIG. 28 (b), the MAPC response AP transmits a MAPC consultation response frame indicating a rejection of the Co-RTWT consultation request.

[0378] Specifically, the MAPC requesting AP transmits a MAPC negotiation request frame requesting Co-RTWT negotiation to the MAPC responding AP. The Per-Scheme Profile sub-element of the MAPC negotiation request frame indicates a Co-RTWT Profile that indicates the MAPC requesting AP's R-TWT schedule. Additionally, the value of the MAPC Operation Type in the Per-Scheme Profile sub-element indicates 0, a value indicating the establishment of consensus. The MAPC responding AP transmits a MAPC negotiation response frame to the MAPC requesting AP. At this time, the MAPC negotiation response frame may include a Per-Scheme Profile sub-element that indicates information regarding the MAPC responding AP's R-TWT schedule and has a MAPC Operation Type field value of 5, indicating an agreement alternate. At this time, the MAPC Request Parameter Set field indicates information regarding the MAPC responding AP's R-TWT scheduling. At this time, the MAPC negotiation response frame may include a field indicating the reason for rejection. A field indicating the reason for rejection may be included in the MAPC element or the Per-Scheme Profile sub-element of the MAPC element.

[0379] The MAPC requesting AP receives the MAPC consultation response frame and can determine the reason for rejection indicated by the MAPC consultation response frame. At this time, the MAPC requesting AP can modify the R-TWT schedule of the MAPC requesting AP (1502) and transmit a MAPC consultation request frame instructing a Co-RTWT consultation request for the modified R-TWT. Alternatively, the MAPC requesting AP can transmit a MAPC consultation request frame instructing a Co-RTWT consultation request for another R-TWT of the MAPC requesting AP. The MAPC response AP receives the MAPC consultation request frame. At this time, the MAPC response AP determines that the Co-RTWT service period indicated by the newly received MAPC consultation request frame does not overlap with the R-TWT service period of the MAPC response AP. The MAPC response AP transmits a MAPC consultation response frame accepting the MAPC consultation request. At this time, the value of the MAPC Operation Type field of the Per-Scheme Profile sub-element of the MAPC consultation response frame is 3.

[0380]

[0381] As previously explained, if an MAPC responding AP transmits a MAPC consultation response frame instructing a rejection and an alternative, and receives a MAPC consultation request frame that contains the MAPC scheme as is or within the scope of the MAPC consultation response frame instructing a proposal, the MAPC responding AP may not be permitted to transmit a MAPC consultation response frame instructing an alternative proposal or a rejection for the said MAPC scheme. In this case, if the MAPC responding AP receives a proposal instructing parameters identical to the alternative for the said MAPC scheme, the MAPC responding AP may be restricted to accepting that proposal. For example, the MAPC responding AP may transmit a MAPC consultation response frame instructing an R-TWT for a proposal while rejecting a Co-RTWT consultation request. In this case, if the MAPC requesting AP requests a Co-RTWT corresponding to the R-TWT instructed by the MAPC responding AP, the MAPC responding AP may not be permitted to propose an alternative or reject the Co-RTWT consultation request. In this case, if the broadcast TWT ID indicated by the MAPC request frame is the same as that indicated by the MAPC responding AP in the MAPC consultation response frame, the MAPC responding AP may not be allowed to propose or reject an alternative to the Co-RTWT consultation request.

[0382] In another specific embodiment, if the MAPC responding AP transmits a MAPC consultation response frame instructing a rejection or an alternative proposal, receives a MAPC consultation request frame back from the MAPC requesting AP, and cannot accept the MAPC scheme instructed by the MAPC consultation frame, the MAPC responding AP may be allowed to reject only the said MAPC scheme. In this case, the MAPC responding AP may not be allowed to transmit a MAPC consultation response frame instructing an alternative proposal for the said MAPC scheme.

[0383] The number of times MAPC consultation request frames and MAPC consultation response frames are exchanged during the MAPC consultation request procedure may be limited. Specifically, the MAPC response AP may limit the number of times MAPC consultation request frames and MAPC consultation response frames are exchanged to the MAPC request AP for consultation of a specific MAPC scheme. In this case, the MAPC request AP may instruct the limit value for the number of frame exchanges per MAPC scheme using the MAPC discovery procedure, for example, the exchange of MAPC discovery request frames and MAPC discovery response frames. This prevents the operation of the AP from being restricted due to repetitive consultation proceedings.

[0384] In the embodiments described above, the MAPC responding AP, while transmitting a MAPC negotiation response frame instructing an alternative proposal, may instruct the mandatory maintenance of specific parameters among the parameters of the proposed MAPC scheme within the MAPC negotiation response frame. Mandatory maintenance of specific parameters may involve maintaining the value of a specific field in the MAPC negotiation response frame identically in the corresponding field of the MAPC negotiation request frame transmitted by the MAPC requesting AP. For example, when the MAPC responding AP transmits a MAPC response frame instructing an alternative to a MAPC negotiation response frame instructing a Co-RTWT negotiation request, the MAPC negotiation response frame may instruct the Co-RTWT profiles that the MAPC responding AP can accept in the Per-Scheme Profile sub-element. In this case, the MAPC negotiation response frame may also instruct the MAPC requesting AP to not modify information. The MAPC requesting AP may transmit the MAPC negotiation request frame by changing the remaining parameters among those instructed by the Per-Scheme Profile sub-element of the MAPC negotiation response frame, excluding the parameters that cannot be modified. For example, the MAPC negotiation response frame may indicate at least one of Broadcast TWT Persistence, TWT Wake Interval, or Target Wake Time being unchangeable. In these embodiments, if the MAPC requesting AP directs the MAPC negotiation request frame again without changing the unchangeable parameter, the MAPC responding AP may be required to transmit a MAPC negotiation response frame indicating acceptance. Specifically, the MAPC responding AP may not be allowed to propose an alternative to the MAPC scheme or transmit a MAPC negotiation response frame indicating rejection.

[0385] Information indicating the mandatory retention of specific parameters among the parameters of the MAPC scheme may be included in the MAPC consultation response frame instead of the Reason Code field described earlier. Additionally, it may be included in the MAPC consultation response frame only when the MAPC Operation Type is 5.

[0386] FIG. 29 shows the MAPC Request Control format of a MAPC element according to an embodiment of the present invention.

[0387] The MAPC Request Control field may include a 3-bit MAPC Operation Type field, a 1-bit MAPC Per-Scheme Info Present field, or a 4-bit Reason Code field. The Reason Code field is a field that may be included in the MAPC consultation response frame. The method of indicating the Reason Code field may follow the embodiments described above.

[0388] For example, if the value of the Reason Code field is 0, the Reason Code field may indicate that the Co-RTWT scheme is rejected due to the R-TWT schedule of the MAPC response AP. Specifically, if the value of the Reason Code field is 0, the Reason Code field may indicate that the R-TWT schedule of the MAPC response AP overlaps with the Co-RTWT schedule. In this case, the Per-Scheme Profile sub-element may indicate information regarding the R-TWT schedule that is the reason for rejection to the MAPC consultation response frame. The information regarding the R-TWT schedule may include at least one of the interval of the R-TWT service period, the duration of the R-TWT service period, or information regarding the period during which the Co-RTWT service period and the R-TWT service period overlap. In this case, the information regarding the period during which the Co-RTWT service period and the R-TWT service period overlap may include information regarding at least one of the start time or end time of the period during which the Co-RTWT service period and the R-TWT service period overlap.

[0389] If the value of the Reason Code field is 1, the Reason Code field may indicate that the Co-RTWT scheme is rejected because the TBTT of the MAPC response AP overlaps with the service period of Co-RTWT. In this case, the Per-Scheme Profile sub-element may indicate information regarding the TBTT that is the reason for rejection to the MAPC consultation response frame. The information regarding the TBTT may include the period of the TBTT. In this embodiment, the MAPC response AP may indicate the presentation of alternatives or rejection of the Co-RTWT request when the TBTT of the MAPC response AP overlaps with the service period of Co-RTWT more than a predetermined number of times.

[0390] If the value of the Reason Code field is 2, the Reason Code field may indicate that the Co-RTWT scheme is rejected because the TWT wake interval of the R-TWT schedule of the MAPC requesting AP exceeds a value pre-specified by the MAPC responding AP. In this case, the Per-Scheme Profile sub-element may indicate information regarding the TWT wake interval that serves as the reason for rejection in the MAPC consultation response frame. The information regarding the TWT wake interval may include the number of times the start time of the service period of the maximum Co-RTWT schedule within the beacon interval pre-specified by the MAPC responding AP occurs. In this embodiment, the MAPC responding AP may indicate the presentation of an alternative or rejection of the Co-RTWT request when the start time of the service period of the Co-RTWT schedule within the beacon interval of the MAPC responding AP occurs more than a pre-specified number of times.

[0391] If the value of the Reason Code field is 3, the Reason Code field may indicate that the Co-RTWT scheme is rejected because the protection period of the R-TWT schedule of the MAPC requesting AP exceeds a value pre-specified by the MAPC responding AP. In this case, the Per-Scheme Profile sub-element may indicate information regarding the Broadcast TWT persistence that serves as the reason for rejection in the MAPC consultation response frame. The information regarding the Broadcast TWT persistence may include the maximum protection period pre-specified by the MAPC responding AP. In this case, the maximum protection period pre-specified by the MAPC responding AP may be indicated in TBTT units. In this embodiment, the MAPC responding AP may indicate the presentation of an alternative or rejection of the Co-RTWT request when the protection maintenance period of the Co-RTWT exceeds a pre-specified period. Additionally, as previously described, the Reason Code field may indicate that the Co-RTWT scheme is rejected due to reasons other than those previously described or reasons that are not pre-defined. In this case, the value of the Reason Code field may be set to a value other than the pre-specified value to indicate a specific reason for rejection. Furthermore, the pre-specified code value of the reason for rejection described above and the pre-set value of the Reason Code field are used for convenience of explanation, and in the implementation of the present invention, values ​​different from the example values ​​used in the description may be used.

[0392]

[0393] <Co-BF 스킴>

[0394] Co-BF enables two APs with multiple transmit chains to simultaneously transmit data to non-AP stations connected to each AP in order to increase medium usage efficiency. Through Co-BF, each AP can minimize interference to OBSS stations by using the CSI of the channel between non-AP stations.

[0395] The Co-BF process may include an AP with established Co-BF consensus, a Co-BF sounding process, and a Co-BF sounding process. The Co-BF sounding process involves two APs conducting a sounding process with non-AP stations participating in the Co-BF transmission. Each AP conducts a sounding process separately, and can exchange information between APs or exchange information with stations participating in the transmission, including stations connected to the other AP. There are two APs that can participate in a Co-BF transmission. The AP that acquires the TXOP and invites another AP to the Co-BF transmission is referred to as the Co-BF Coordinating AP, and the AP that receives the Co-BF transmission invitation is referred to as the Co-BF Coordinated AP. A Co-BF transmission is initiated when one AP acquires the TXOP and transmits a Co-BF invitation frame to invite the other AP to the Co-BF transmission. At this time, the Co-BF invitation frame may include information to be applied to the PPDU to be transmitted by the Co-BF coordinating AP in the Co-BF transmission. At this time, the information to be applied may include at least one of the following: the minimum / maximum number of data OFDM symbols, the PHY version of the PPDU to be transmitted, the bandwidth to be used for transmission, the puncturing pattern to be used for transmission, the GI and LTF size of the PPDU to be transmitted, the maximum number of spatial streams allowed to the Co-BF coordinating AP, the number of non-AP stations to communicate with the Co-BF coordinating AP, the STA ID of the non-AP station to communicate with the Co-BF coordinating AP, or the number of spatial streams to be allocated to each station by the Co-BF coordinating AP in the Co-BF transmission.

[0396] A Co-BF coordinated AP invited to a Co-BF transmission may send a Co-BF response frame to the Co-BF coordinating AP in response to the Co-BF invitation frame. The Co-BF response frame may indicate information to be applied to the PPDU to be transmitted by the Co-BF coordinated AP in the Co-BF transmission. Specifically, the information to be applied may include at least one of the following: a proposal for the number of data OFDM symbols to be included in the PPDU to be transmitted by the Co-BF coordinated AP in the Co-BF transmission, the PHY version of the PPDU to be transmitted, the number of non-AP stations to be communicated by the Co-BF coordinated AP in the Co-BF transmission, the STA ID of the non-AP stations to be communicated by the Co-BF coordinated AP in the Co-BF transmission, the MCS to be applied by the Co-BF coordinated AP in the Co-BF transmission, or whether the Co-BF coordinated AP will apply 2x LDPC to each non-AP station in the Co-BF transmission. The AP coordinating Co-BF can ignore the proposal regarding the number of OFDM symbols to be included in the PPDU to be transmitted in Co-BF from the information transmitted by the Co-BF-coordinated AP.

[0397] For medium synchronization in Co-BF transmission, a Co-BF coordinating AP that is a TXOP holder can transmit a Co-BF trigger frame to a Co-BF coordinating AP. After SIFS from the end of the transmission of the Co-BF trigger frame, the two Co-BF APs can communicate with non-AP stations connected to each. At this time, the start and end of the PPDUs transmitted by each Co-BF AP can be aligned, for example, matched.

[0398] Through Co-BF, two APs can share channel state information and determine the optimal transmission method to transmit more data without errors during the same period.

[0399]

[0400] <Co-SR 스킴>

[0401] Co-SR improves the efficiency of SR operations by controlling transmission power between two APs to increase medium usage efficiency. Each AP can minimize interference to OBSS stations by adjusting the transmission power for data to be transmitted to non-AP stations.

[0402] In Co-SR transmission, there are up to two APs capable of performing Co-SR transmission, and the AP that acquires the TXOP and transmits an initial control frame to start Co-SR transmission is called the Co-SR coordinating AP. The AP that receives the initial control frame to start Co-SR transmission from the Co-SR coordinating AP is called the Co-SR coordinating AP.

[0403] Co-SR transmission can be initiated by the Co-SR coordinating AP acquiring a TXOP and transmitting an initial control frame to start the Co-SR transmission. The Co-SR coordinating AP, which is the destination device of the initial control frame to start the Co-SR transmission, may indicate participation in the Co-SR transmission by transmitting a response to the initial control frame. The Co-SR coordinating AP transmits a Co-SR trigger frame for medium synchronization for simultaneous transmission. At this time, the Co-SR trigger frame may include information regarding the duration of the PPDU to be transmitted in the Co-SR transmission, information regarding the transmission power of the Co-SR coordinating AP, and information regarding the transmission power of the Co-SR coordinating AP. Information regarding the duration of the PPDU to be transmitted in the Co-SR transmission may be indicated by the UL Length field of the Common Info field of the Co-SR Trigger frame. The remaining information may be indicated by the User Info field of the Co-SR Trigger frame. At this time, the AID12 field of the User Info field indicating the remaining information may indicate the ID of the Co-SR coordinating AP. In another specific embodiment, the AID12 field of the User Info field indicating the remaining information may indicate a pre-specified value.

[0404] After SIFS from the time the Co-SR trigger frame is finished transmitting, the Co-SR coordinating AP and the Co-SR coordinating AP may each simultaneously transmit PPDUs to their respective non-AP stations. At this time, the PPDUs transmitted by each AP may have aligned start and end points, for example, identical. Additionally, the transmission power for each AP to transmit the PPDU may be limited to a value less than or equal to the transmission power value specified in the Co-SR trigger frame.

[0405] Through these embodiments, communication can be performed while minimizing interference from OBSS.

[0406]

[0407] <Co-TDMA 스킴>

[0408] Co-TDMA aims to improve wireless communication efficiency by having an AP, acting as a TXOP holder, allocate a portion of its TXOPs to at least one non-colocated AP. In this process, the AP allocated the TXOP can proceed with the frame exchange procedure with its associated non-AP STA during the TXOP period.

[0409] The Co-TDMA procedure may include a polling phase, a TXOP allocation phase, and a TXOP return phase in a single TXOP. The polling phase begins with the transmission of an Initial Control frame (ICF) by the AP that acquired the TXOP to at least one non-colocated AP sharing the Co-TDMA to confirm whether to participate in Co-TDMA. The Initial Control frame may be a BSRP trigger frame. The BSRP trigger frame may indicate one or more APs that the BSRP trigger frame triggers using one or more User Info fields. In this case, the User Info field may indicate the ID of the AP that the BSRP trigger frame triggers. Additionally, if the BSRP trigger frame triggers a single AP, the BSRP trigger frame may be a BSRP NTB (non-trigger based) trigger frame containing only the User Info field indicating the ID of the triggering AP. The initial control frame can indicate the duration of the TXOP allocated in the TXOP allocation phase.

[0410] When an AP that receives an initial control frame and is triggered by the initial control frame is a Co-TDMA shared AP and intends to participate in the Co-TDMA TXOP allocation phase, the AP may transmit a response frame to the initial control frame.

[0411] In this case, the response frame may be a pre-specified response frame. The pre-specified response frame may be a Multi-STA BlockAck frame. Additionally, the response frame may include feedback information related to Co-TDMA operation. The response frame may include a Per AID TID Info field where the value of the Feedback Type field is 3.

[0412] An AP that receives an initial control frame may not transmit a response to the initial control frame. In this case, the AP may implicitly indicate that it will not proceed with the Co-TDMA procedure. If the Co-TDMA sharing AP that transmitted the initial control frame does not receive a response to the initial control frame from another AP, it may not assign a TXOP to that AP during the TXOP allocation phase.

[0413] Through Co-TDMA, a Co-TDMA sharing AP can minimize idle resources and maximize overall channel utilization by sharing a portion of the remaining TXOP time it is not using with a Co-TDMA shared AP. Additionally, when a Co-TDMA sharing AP, which is the TXOP holder, monopolizes medium access rights for a specific period (TXOP), it can effectively reduce collisions and interference caused by other APs attempting to transmit indiscriminately by explicitly allocating a portion of that time to the other AP.

[0414]

[0415] <MAPC 스킴 캐퍼빌리티와 MAPC 디스커버리 절차>

[0416] In the MAPC discovery process, an AP participating in the MAPC discovery process may specify parameters for the AP's MAPC scheme. In this case, the parameters may include the capabilities that the AP can perform in each MAPC scheme.

[0417] The MAPC element included in the MAPC discovery request / response frame can indicate the capabilities of the AP by MAPC scheme. In this case, the MAPC element includes a MAPC scheme Info field, and the MAPC Scheme Info field can indicate the capabilities by MAPC scheme. This allows for reducing unnecessary additional consultation during the MAPC consultation phase and increasing consultation efficiency.

[0418] First, the information regarding Co-RTWT included in the MAPC discovery request / response frame is described. The information regarding Co-RTWT included in the MAPC discovery request / response frame may be a minimum condition for proceeding with Co-RTWT negotiation. Specifically, the information regarding Co-RTWT may include at least one of the following: the maximum number of Co-RTWT consensuses supported by the corresponding AP in Co-RTWT, the maximum retention time of Co-RTWT consensus allowed by the AP in Co-RTWT, the minimum TWT service period interval of the Co-RTWT schedule allowed by the AP in Co-RTWT, or the TID of the Co-RTWT schedule allowed by the AP in Co-RTWT. The Co-RTWT Profile field may indicate information regarding Co-RTWT.

[0419] The maximum number of Co-RTWT consensuses allowed by the AP specifies the maximum number of Co-RTWT consensuses permitted by the MAPC responding AP, in order to prevent the reception of Co-RTWT negotiation requests even when Co-RTWT consensuses cannot be added. If a MAPC request frame received by the MAPC responding AP specifies a number of Co-RTWT profiles greater than the maximum number of Co-RTWT consensuses allowed by the MAPC responding AP, the MAPC responding AP may establish Co-RTWT consensuses only up to the maximum number allowed by the MAPC responding AP and reject the remaining Co-RTWT profiles. The maximum duration of the Co-RTWT schedule allowed by the AP may be the maximum time the MAPC responding AP can maintain a Co-RTWT consensus. By specifying the maximum time for maintaining a Co-RTWT consensus, it is possible to prevent the operation of the Co-RTWT negotiation responding AP from being excessively restricted by Co-RTWT consensuses. The Broadcast TWT Persistence field of the Service Period Info field of the Co-RTWT Profile field included in the MAPC Discovery Request / Response frame can indicate the maximum Co-RTWT retention time among the MAPC consultation request conditions.

[0420] The minimum TWT service duration interval of the Co-RTWT schedule allowed by the MAPC response AP is intended to prevent the MAPC response AP from participating in Co-RTWT too frequently and limiting performance. At least one of the Target Wake Time field, Nominal Minimum TWT Wake Duration field, TWT Wake Interval Mantissa field, or TWT Wake Interval Exponent field of the Co-RTWT Profile field included in the MAPC discovery request / response frame may indicate the minimum TWT service duration interval of the Co-RTWT schedule allowed by the MAPC response AP.

[0421] The TID of an acceptable Co-RTWT schedule is intended to prevent the Co-RTWT response MAPC from executing an excessive number of Co-RTWT schedules. If the MAPC discovery response frame does not indicate the TID of an acceptable Co-RTWT schedule, the MAPC discovery response frame may indicate that the MAPC response AP does not have an R-TWT schedule or can establish Co-RTWT consensus for any TID. The TID of an acceptable Co-RTWT schedule may indicate that Co-RTWTs with TIDs less than the indicated TID value are allowed. In this case, the indicated TID value may be the TID of the R-TWT configured for the AP.

[0422] Figure 30 shows the format of the Per-Scheme Profile subelement of the MAPC discovery request / response frame.

[0423] Content identical or corresponding to what was previously explained in FIGS. 25 and FIGS. 26 is omitted.

[0424] FIG. 30(a) shows the format of a MAPC discovery request / response frame. FIG. 30(b) shows the format of the Per-Scheme Profile sub-element, which is the MAPC Scheme Info field of the MAPC element of the MAPC discovery request / response frame. FIG. 30(c) shows the format of the field indicating information regarding Co-RTWT in the MAPC Scheme Info field. FIG. 30(d) shows the Co-RTWT Profile format of the MAPC Scheme Parameter Set field.

[0425] The MAPC Scheme Info field format included in the MAPC Discovery Request / Response frame may not include the MAPC Scheme Request Set field, unlike the MAPC Scheme Info field included in the MAPC Consultation Request / Response frame. The MAPC Scheme Request Set field may be included in the MAPC element included in the MAPC Discovery Info field.

[0426] The MAPC Scheme Control field can indicate what type of MAPC scheme the MAPC Scheme Info field is. Figure 30 (C) shows a case where the MAPC Scheme Control field indicates that the MAPC scheme is Co-RTWT. The MAPC Scheme Control field may include at least one of the Number of Co-RTWT Agreements per AP field or the TID Limit field.

[0427] The Number of Co-RTWT Agreements per AP field may indicate the maximum number of Co-RTWT agreements that the AP can allow. For example, the Number of Co-RTWT Agreements per AP field may be a 1-bit field. In this case, if the value of the Number of Co-RTWT Agreements per AP field is 0, the maximum number of Co-RTWT agreements allowed by the AP may be 2. Also, if the value of the Number of Co-RTWT Agreements per AP field is 1, the maximum number of Co-RTWT agreements allowed by the AP may be 4.

[0428] The TID Limit field may be a field indicating the TIDs that the AP allows in Co-RTWTs. Specifically, the TID Limit field may indicate that the AP allows only Co-RTWTs for TIDs less than the TID indicated by the TID Limit field. The TID Limit field may be a 3-bit field. The TID value indicated by the TID Limit field may be the TID of the R-TWT configured in the AP.

[0429] The Number of Co-RTWT Agreements per AP field and the TID Limit field may be included in the Per-Scheme Profile sub-element according to specific embodiments.

[0430] The Co-RTWT Profile field can specify restrictions on the conditions under which an AP can establish a Co-RTWT consensus.

[0431] The Co-RTWT Profile field may include at least one of an 8-octet Target Wake Time field, a 1-octet Nominal Minimum TWT Wake Duration field, a 2-octet TWT Wake Interval Mantissa field, or a 2-octet Service Period Info field. The Service Period Info field may include at least one of a 5-bit TWT Wake Interval Exponent field, an 8-bit Broadcast TWT Persistence field, a 2-bit Restricted TWT Schedule Info field, or a 1-bit Reserved field.

[0432] The Broadcast TWT Persistence field may specify the maximum retention time for Co-RTWT consensus or the protection time for Co-RTWT consensus allowed by the AP. If the Broadcast TWT Persistence field specifies the maximum retention time for Co-RTWT consensus, the Co-RTWT requesting AP may only request Co-RTWT with a duration lower than the value specified by Broadcast TWT Persistence. If the Broadcast TWT Persistence field specifies the protection time for Co-RTWT consensus allowed by the AP, the Co-RTWT responding AP may protect the Co-RTWT consensus only up to the duration specified by the value in the Broadcast TWT Persistence field.

[0433] The TWT Wake Interval Mantissa field and the TWT Wake Interval Exponent field of the Co-RTWT Profile field may indicate the minimum TWT service period interval of the Co-RTWT schedule that the AP allows in Co-RTWT. An AP requesting Co-RTWT consultation may request consultation for Co-RTWT with an interval greater than the interval indicated by the TWT Wake Interval Mantissa field and the TWT Wake Interval Exponent field.

[0434] If the Restricted TWT Schedule Info field, Target Wake Time field, and Nominal Minimum TWT Wake Duration field are included in the MAPC discovery request / response frame, the Restricted TWT Schedule Info field, Target Wake Time field, and Nominal Minimum TWT Wake Duration field may be considered as reserved fields.

[0435]

[0436] The MAPC discovery request / response frame may indicate information related to Co-BF / Co-SR. The information related to Co-BF / Co-SR may indicate the minimum conditions and capabilities for proceeding with Co-BF / Co-SR consultation. The information related to Co-BF / Co-SR may include at least one of the following information.

[0437] 1. Support for Extended Timeout Period

[0438] 2. (Co-SR) Support for Co-SR Mode 1 and Mode 2

[0439] 3. (Co-SR) Minimum / Maximum Transmission Power in Co-SR Transmission

[0440] 4. (Co-BF) Support for Cross-BSS Co-BF Sounding

[0441] 5. (Co-BF) Joint NDP Sounding Support

[0442] 6. (Co-BF) Minimum / Maximum number of spatial streams in Co-BF transmission

[0443] 7. Minimum / Maximum duration of DL PPDU transmitted in Co-SR / Co-BF transmission

[0444] 8. Minimum duration of TXOP in Co-SR / Co-BF transmission

[0445] 9. Bandwidth used in Co-SR / Co-BF transmission

[0446] The extended timeout period may specify the time required for a non-AP station to switch back if the non-AP station communicating with the AP during the Co-BF / Co-SR transmission phase is a station requiring the reception of an initial control frame, such as an EMLSR station or a DPS station. During the period specified by the extended timeout period, the Co-BF / Co-SR AP may not be permitted to perform a transmission. This is because the opposing AP must also wait during the same period since it is unable to perform a transmission due to the non-AP station's switching back.

[0447] Co-SR Mode 1 is a mode in which both APs can transmit UHR PPDU and EHT PPDU during Co-SR transmission. Additionally, Co-SR Mode 2 is a mode in which both APs can transmit only UHR PPDU during the Co-SR transmission phase. In Co-SR Mode 2, both APs must transmit PPDUs with the same PHY version during the Co-SR transmission phase.

[0448] Cross-BSS Co-BF sounding is an operation in which an AP sequentially sends a UHR NDP Announcement frame, an EHT sounding NDP frame, and a BFRP trigger frame to obtain beamforming information of stations participating in Co-BF transmission. Cross-BSS Co-BF sounding can be performed in one or more TXOPs. Cross-BSS Co-BF sounding is a sequential NDP sounding procedure. When a joint NDP sounding procedure is supported, Cross-BSS Co-BF sounding is not supported.

[0449] Joint NDP sounding is a procedure in the Co-BF sounding process for two APs to collect beamforming information from non-AP stations belonging to a single AP from a single TXOP. The two APs participating in Co-BF require an invitation frame / response frame exchange procedure for inviting to the sounding process. After the TXOP holder transmits a UHR NDP Announcement frame, the two APs transmit an EHT sounding NDP after SIFS. After SIFS from the EHT sounding NDP, the TXOP holder transmits a BFRP trigger frame to obtain beamforming information from the TXOP holder's non-AP station.

[0450] As a condition for receiving guaranteed information exchange in Co-BF / Co-SR transmission, the AP may specify information related to Co-SR / Co-BF transmission. The information related to Co-SR / Co-BF transmission may be information for operations following the transmission of a Co-BF trigger frame. For example, the AP may specify a minimum value for the DL PPDU duration to be transmitted when performing Co-SR / Co-BF transmission. The minimum value for the DL PPDU duration is the minimum duration of the PPDU transmitted by the AP after the Co-BF / Co-SR trigger frame, and is information intended to guarantee the AP's data transmission. Additionally, the AP may specify a minimum value for the TXOP length to perform Co-SR / Co-BF transmission. The minimum value for the TXOP length may be the minimum time required for guaranteed data transmission while the AP performs Co-SR / Co-BF transmission. Furthermore, the AP may specify bandwidth information to perform Co-SR / Co-BF transmission. Bandwidth information may include at least one of the size of the bandwidth or a puncturing pattern. Bandwidth information is information for matching the preamble of the DL PPDU transmitted by two APs in Co-BF / Co-SR transmission, for example, for matching the shape of the preamble. This allows the two APs to prevent preamble amplification from occurring by using different puncturing patterns.

[0451] The MAPC discovery request / response frame may indicate Co-TDMA related information. The Co-TDMA related information may indicate minimum conditions for proceeding with Co-TDMA consultation. The Co-TDMA related information may include at least one of the following information.

[0452] 1. Minimum guaranteed length of the duration of the allocated TXOP

[0453] 2. Support for TXOP return

[0454] The AP can specify the minimum duration of the TXOP to be allocated in Co-TDMA. This allows the AP to guarantee the amount of data to be transmitted in Co-TDMA. The MAPC discovery request / response frame may specify at least one of the minimum duration of the TXOP to be allocated in Co-TDMA or whether TXOP return is supported in a field indicating information related to Co-TDMA.

[0455]

[0456] In the embodiments described above, the AP may transmit a MAPC discovery request / response frame indicating information about the MAPC scheme. The information about the MAPC scheme may include at least one of information regarding the capability or allowable parameters of the MAPC scheme. The AP that has obtained information about the MAPC scheme may determine information specific to the MAPC scheme. Accordingly, the AP may determine whether to initiate MAPC negotiation.

[0457] A MAPC requesting AP can perform a MAPC negotiation request based on information regarding the MAPC scheme obtained from the MAPC discovery request / response frame. Specifically, a MAPC requesting AP can perform a MAPC negotiation request based on information regarding the capabilities or allowed parameters of the MAPC responding AP described above. For example, a MAPC requesting AP requesting Co-RTWT negotiation may only request Co-RTWT negotiation for TIDs that have a value smaller than the minimum TID value specified by the MACP responding AP. A MAPC requesting AP requesting Co-RTWT negotiation may not be able to perform a Co-RTWT negotiation request for TIDs that have a value equal to or greater than the minimum TID value specified by the MACP responding AP. Additionally, a MAPC requesting AP requesting Co-RTWT negotiation may only request Co-RTWT negotiation for TIDs that have a value equal to or greater than the minimum TWT service period interval of the Co-RTWT schedule specified by the MACP responding AP.

[0458] This can increase the efficiency of MAPC consultations and reduce unnecessary repetition of MAPC consultations.

[0459] As previously explained, the two APs can establish an MAPC agreement through MAPC consultation. The framework for MAPC consultation may follow the embodiments described in the <Multi-AP Coordination Framework>. Additionally, the APs may perform a MAPC discovery procedure for MAPC consultation. Specifically, the APs<MAPC 디스커버리 절차> or><MAPC 스킴 캐퍼빌리티와 MAPC 디스커버리 절차> The MAPC discovery procedure can be performed in accordance with the embodiments described through at least one of the above. Additionally, the AP can perform the MAPC consultation procedure. Specifically, the AP<MAPC 협의 절차> Alternatively, the MAPC consultation procedure may be performed according to the embodiments described through at least one of the <MAPC consultation procedure using alternative proposals>.

[0460] In these embodiments, if the MAPC scheme is Co-RTWT, AP is<Co-RTWT 협의 규칙> ,<Co-RTWT 공지(announcement)> ,<Co-RTWT Protection 동작> ,<Co-RTWT 서비스 기간 조기 종료> , <Cross-Link Co-RTWT Consultation>, or<Co-RTWT 파라미터> It can operate according to the embodiments described through at least one of them.

[0461]

[0462] Although the present invention has been described above using wireless LAN communication as an example, the invention is not limited thereto and can be applied in the same way to other communication systems, such as cellular communication. Furthermore, while the method, apparatus, and system of the present invention have been described in relation to specific embodiments, some or all of the components and operations of the present invention may be implemented using a computer system having a general-purpose hardware architecture.

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

[0464] Although the above description has focused on exemplary embodiments, this is merely illustrative and does not limit the invention. Those skilled in the art will understand that various modifications and applications not exemplified above are possible within the scope of the essential characteristics of the embodiments. For example, each component specifically shown in the embodiments may be modified. Furthermore, differences related to such modifications and applications should be interpreted as being included within the scope of the invention as defined in the appended claims.

Claims

1. At the second AP (access point) coordinating operations with the first AP, Transmitter / receiver; and Includes a processor, The above processor Receive a request frame from the first AP directing a coordination request for a multi-AP coordination (MAPC) scheme, and When a response frame accepting a coordination request for the MAPC scheme is transmitted in response to the above request frame, an operation is performed according to the coordination request. 2nd AP.

2. In Paragraph 1, The above processor If the MAPC scheme is R-TWT (restricted-target wake time), a second R-TWT is set in the BSS operated by the second AP according to the schedule of the first R-TWT of the first AP, and The above second R-TWT does not allow transmission 2nd AP.

3. In Paragraph 2, The above processor Set the value of all bits of the bitmap indicating low-latency traffic allowed to be transmitted to the second R-TWT to 0. 2nd AP.

4. In Paragraph 2, The above processor Setting a quiet interval that overlaps with the above second R-TWT schedule 2nd AP.

5. In Paragraph 4, The above processor When the first AP sets a quiet interval that overlaps with the first R-TWT schedule, it sets a quiet interval that overlaps with the second R-TWT schedule. 2nd AP.

6. In Paragraph 1, When the second AP transmits a response frame to the request frame instructing the rejection of the coordination request for the MAPC scheme, the response frame instructs the reason for the rejection of the coordination request for the MAPC scheme. 2nd AP.

7. In Paragraph 6, The coordination request for the above MAPC scheme is a request for R-TWT (restricted-target wake time), and The reason for the above rejection is that the R-TWT schedule indicated by the above MAPC scheme and the R-TWT schedule of the above 2nd AP overlap. 2nd AP.

8. At the 1st AP (access point) coordinating operations with the 2nd AP, Transmitter / receiver; and Includes a processor, The above processor Transmitting a request frame instructing the second AP to request coordination for a multi-AP coordination (MAPC) scheme, and Receiving a response frame that is a response to the above request frame 1st AP.

9. In Paragraph 8, If the above MAPC scheme is R-TWT (restricted-target wake time), the second AP sets a second R-TWT in the BSS operated by the second AP according to the schedule of the first R-TWT of the first AP, and does not set low-latency traffic that is allowed to be transmitted in the second R-TWT. 1st AP.

10. In Paragraph 9, The above processor Requesting the second AP to set a quiet interval that overlaps with the first R-TWT schedule 1st AP.

11. In Paragraph 10, The above processor When the first AP sets a quiet interval that overlaps with the first R-TWT schedule, it requests the second AP to set a quiet interval that overlaps with the first R-TWT schedule. 1st AP.

12. In Paragraph 8, The above processor Receive a response frame for the request frame from the second AP that instructs the rejection of the coordination request for the MAPC scheme, and The above response frame indicates the reason for the rejection of the coordination request for the above MAPC scheme 2nd AP.

13. In Paragraph 12, The coordination request for the above MAPC scheme is a request for R-TWT (restricted-target wake time), and The reason for the above rejection is that the R-TWT schedule indicated by the above MAPC scheme and the R-TWT schedule of the above 2nd AP overlap. 1st AP.

14. In the operation method of a second AP (access point) coordinating operation with the first AP The step of receiving a request frame from the first AP directing a coordination request for a multi-AP coordination (MAPC) scheme; and When transmitting a response frame accepting a coordination request for the MAPC scheme in response to the above request frame, the method includes the step of performing an operation according to the coordination request. Method of operation.

15. In Paragraph 14, The step of performing an action according to the above adjustment request If the MAPC scheme is R-TWT (restricted-target wake time), the method includes the step of setting a second R-TWT in the BSS operated by the second AP according to the schedule of the first R-TWT of the first AP. The step of setting the second R-TWT above The above second R-TWT includes a step of not allowing transmission. Method of operation.

16. In Paragraph 15, In the above second R-TWT, the step that does not allow transmission The step of setting the value of all bits of a bitmap indicating low-latency traffic allowed to be transmitted to the second R-TWT to 0 Method of operation.

17. In Paragraph 15, The step of performing an action according to the above adjustment request A step comprising setting a quiet interval that overlaps with the second R-TWT schedule. Method of operation.

18. In Paragraph 17, The step of setting a quiet interval that overlaps with the above-mentioned second R-TWT schedule is When the first AP sets a quiet interval that overlaps with the first R-TWT schedule, the method includes the step of setting a quiet interval that overlaps with the second R-TWT schedule. Method of operation.

19. In Paragraph 14, The above method of operation When the second AP transmits a response frame to the request frame instructing the rejection of a coordination request for the MAPC scheme, the response frame further includes a step of instructing the reason for the rejection of the coordination request for the MAPC scheme. Method of operation.

20. The operation method of the 1st AP (access point) coordinating operation with the 2nd AP The step of transmitting a request frame instructing the second AP to request coordination for a multi-AP coordination (MAPC) scheme; and The step of receiving a response frame which is a response to the above request frame Method of operation.

Images