Multi-link device operating on multiple links and method of operation of the multi-link device

Abstract

A multi-link device comprising a plurality of stations each operating on a plurality of links is disclosed. The multi-link operating device comprises a transceiver; and a processor. The processor is one of the plurality of stations and transmits a target wake time (TWT) element from a first station coupled to a first AP on a first link to request a TWT agreement for a second station operating on a second link and a second AP coupled to the second station.

Description

Technology Field

[0001] The present invention relates to a multi-link device operating on a plurality of links and a method of operating the multi-link device. Background Technology

[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 up to 54Mbps using OFDM (orthogonal frequency division multiplexing) technology. However, IEEE 802.11a has the disadvantage of a shorter communication range compared to IEEE 802.11b. IEEE 802.11g, like IEEE 802.11b, uses the 2.4GHz band frequency to achieve a maximum communication speed of 54Mbps and has received considerable attention for satisfying backward compatibility, and it also has an advantage over IEEE 802.11a in terms of communication distance.

[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. The problem to be solved

[0008] One embodiment of the present invention aims to provide a wireless communication method using a multi-link and a wireless communication terminal using the same. means of solving the problem

[0009] A multi-link device comprising a plurality of stations each operating on a plurality of links according to an embodiment of the present invention includes a transceiver; and a processor. The processor is one of the plurality of stations and transmits a TWT (target wake time) element from a first station coupled to a first AP on a first link to request a TWT agreement for a second station operating on a second link and a second AP coupled to the second station.

[0010] The above TWT element may include a bitmap indicating information indicating the link to which the TWT consensus to be established by the above TWT element will be applied.

[0011] The TWT request station of the TWT consensus for the second station and the second AP is the second station, and the TWT response station of the TWT consensus for the second station and the second AP may be the second AP.

[0012] When the processor receives a TWT release frame from the second AP or successfully transmits the TWT release frame to the second AP, it may release the TWT agreement for the second station and the second AP.

[0013] The processor can release the TWT consensus for the second station and the second AP without receiving or transmitting a TWT release frame that releases the TWT consensus for the second station and the second AP when the second link is deactivated.

[0014] The above TWT element may request multiple TWT consensuses established on multiple links, including a second link.

[0015] Each of the multiple TWT agreements established on the above multiple links can be identified based on the link ID of each of the above multiple links.

[0016] Each of the plurality of TWT agreements established on the plurality of links can be identified based on the link ID of each of the plurality of links, the MAC (medium access control) address of the multi-link device, and the TWT Flow ID of each of the plurality of TWT agreements established on the plurality of links.

[0017] When the processor successfully transmits a TWT release frame or receives the TWT release frame, it may release at least one of a plurality of TWT consensuses established on a plurality of links based on the link ID indicated by the TWT release frame.

[0018] The processor may release the TWT agreement for the second station and the second AP, and transfer the TWT agreement for the second station and the second AP to the first station and the first AP.

[0019] When the processor succeeds to the TWT consensus for the second station and the second AP to the first station and the first AP, it may apply the TWT parameters of the TWT consensus for the second station and the second AP to the TWT consensus for the first station and the first AP.

[0020] A method of operation of a multi-link device comprising a plurality of stations each operating in a plurality of links according to an embodiment of the present invention includes the step of transmitting a target wake time (TWT) element at a first station, which is one of the plurality of stations and coupled to a first AP in a first link, to request a TWT consensus for a second station operating in a second link and a second AP coupled to the second station.

[0021] The above TWT element may include a bitmap indicating information indicating the link to which the TWT consensus to be established by the above TWT element will be applied.

[0022] The TWT request station of the TWT consensus for the second station and the second AP is the second station, and the TWT response station of the TWT consensus for the second station and the second AP may be the second AP.

[0023] The above operation method may further include the step of releasing the TWT consensus for the second station and the second AP when a TWT release frame is received from the second AP or when the TWT release frame is successfully transmitted to the second AP.

[0024] The above method of operation may further include the step of releasing the TWT consensus for the second station and the second AP without receiving or transmitting a TWT release frame that releases the TWT consensus for the second station and the second AP when the second link is deactivated.

[0025] The above TWT element may request multiple TWT consensuses established on multiple links, including a second link.

[0026] Each of the multiple TWT agreements established on the above multiple links can be identified based on the link ID of each of the above multiple links.

[0027] Each of the plurality of TWT agreements established on the plurality of links can be identified based on the link ID of each of the plurality of links, the MAC (medium access control) address of the multi-link device, and the TWT Flow ID of each of the plurality of TWT agreements established on the plurality of links.

[0028] The above operation method may further include the step of releasing at least one of a plurality of TWT consensuses established on a plurality of links based on a link ID indicated by the TWT release frame when the TWT release frame is successfully transmitted or the TWT release frame is received. Effects of the invention

[0029] One embodiment of the present invention provides a multi-link device operating on a plurality of links. In addition, one embodiment of the present invention provides a method for the multi-link device to efficiently perform TWT operation. Brief explanation of the drawing

[0030] FIG. 1 shows a wireless LAN system according to one embodiment of the present invention. FIG. 2 shows a wireless LAN system according to another embodiment of the present invention. FIG. 3 shows the configuration of a station according to one embodiment of the present invention. FIG. 4 shows the configuration of an access point according to one embodiment of the present invention. Figure 5 schematically illustrates the process of a station establishing a link with an access point. Figure 6 shows an example of a CSMA (Carrier Sense Multiple Access) / CA (Collision Avoidance) method used in wireless LAN communication. Figure 7 illustrates an example of a PPDU (PLCP Protocol Data Unit) format for various standard generations. FIG. 8 shows an example of various EHT (Extremely High Throughput) PPDU (Physical Protocol Data Unit) formats and a method for indicating them according to an embodiment of the present invention. FIG. 9 shows a multi-link device according to an embodiment of the present invention. FIG. 10 shows that transmission of different links is performed simultaneously in a multi-link operation according to an embodiment of the present invention. FIG. 11 shows a method for establishing a broadcast TWT between an AP and a station according to an embodiment of the present invention. FIG. 12 shows that AP sets a quiet interval according to an embodiment of the present invention. FIG. 13 illustrates a method for setting a TXOP in consideration of a limited service period for a station according to an embodiment of the present invention. FIG. 14 shows that a station according to an embodiment of the present invention performs the channel access procedure again considering the limited service period. FIG. 15 shows an operation in which an AP terminates a limited service period early according to an embodiment of the present invention. FIG. 16 shows the format of a TWT element according to an embodiment of the present invention. FIG. 17 shows a multi-link device according to an embodiment of the present invention performing TWT consensus. FIG. 18 shows that, according to an embodiment of the present invention, a station included in a multi-link device performs TWT consensus for another station included in the multi-link device that includes the station. FIG. 19 shows the operation of a multi-link device according to an embodiment of the present invention releasing a TWT agreement. FIG. 20 shows the format of the Individual TWT parameter set field of a TWT element according to an embodiment of the present invention. FIG. 21 shows the format of the remaining TWT Flow Identifier subfields, excluding the first TWT Flow Identifier subfield, according to an embodiment of the present invention. FIG. 22 shows the format of a Control field included in a TWT element transmitted by a multi-link device according to an embodiment of the present invention. FIG. 23 shows the format of the Action field of a TWT release frame transmitted by a multi-link device according to an embodiment of the present invention. FIG. 24 shows an MLD TWT Flow field according to an embodiment of the present invention. FIG. 25 shows the format of an MLD TWT Flow field according to another embodiment of the present invention. FIG. 26 shows a TWT release frame that releases a TWT consensus established in a multi-link device according to an embodiment of the present invention. FIG. 27 shows that a TWT agreement established between multi-link devices according to an embodiment of the present invention is implicitly released. Specific details for implementing the invention

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0059] <Examples of Various PPDU Formats>

[0060] FIG. 7 illustrates examples of various standard generational PPDU (PLCP Protocol Data Unit) formats. 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.

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

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

[0063] 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-SIG-A (Extremely High Throughput Signal A field), EHT-SIG-A (Extremely High Throughput Signal B field), EHT-STF (Extremely High Throughput Short Training field), and EHT-LTF (Extremely High Throughput Long Training field) in addition to the legacy preamble. In an embodiment of the present invention, 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 may be used in only some of the EHT PPDU formats.

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

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

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

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

[0068]

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

[0070]

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

[0072]

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

[0074] Referring to Fig. 7(e), the U-SIG (Universal SIG) field continues to exist in EHT PPDUs and subsequent generations of wireless LAN PPDUs, and serves to distinguish which generation of PPDU it is, including 11be. The 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.

[0075] The VI bits maintain the current bit configuration in the future, allowing current 11be terminals to obtain information about a PPDU through its VI fields even if 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 field is 3 bits long and serves to sequentially distinguish versions of 11be and subsequent generation wireless LAN standards. For 11be, it has a value of 000b. The UL / DL field distinguishes whether the PPDU is an uplink or downlink PPDU. 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, which was previously transmitted in the MAC header; by adding it to the PHY header, the length of the TXOP containing the PPDU can be inferred without the need to decode the MPDU, and it has a value of 7 bits or more.

[0076] The VD field contains signaling information useful only for PPDUs of version 11be and can be composed of fields common to any PPDU format, such as PPDU format and BW, as well as fields defined differently for each PPDU format. The PPDU format is a identifier that distinguishes between EHT SU (Single User), EHT MU (Multiple User), EHT TB (Trigger-based), and EHT ER (Extended Range) PPDUs. The BW field signals five basic PPDU BW options—20, 40, 80, 160 (80+80), and 320 (160+160) MHz (BWs that can be expressed in the form of 20*2 powers can be referred to as basic BWs)—and various remaining PPDU BWs configured through Preamble Puncturing. Additionally, it may be signaled in a form where a portion of 80 MHz is punctured after being signaled at 320 MHz. Additionally, the punctured and modified channel shape can be signaled directly in the BW field, or by using the BW field together with fields appearing after the BW field (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 the puncturing mode can signal a maximum of only 3. If the BW field is set to 4 bits, a total of 16 BW signals are possible, so the puncturing mode can signal a maximum of 11.

[0077] The fields located after the BW field vary depending on the form and format of the PPDU; MU PPDU and SU PPDU may be signaled in the same PPDU format, and a field to distinguish between MU PPDU and SU PPDU may be located before the EHT-SIG field, for which additional signaling may be performed. Both SU PPDU and MU PPDU contain the EHT-SIG field, but some fields not required in SU PPDU may be compressed. In this case, the information in the compressed fields may be omitted or have a size reduced compared to the original fields included in MU PPDU. For example, SU PPDU may have a different configuration, such as omitting or replacing common fields in EHT-SIG, or replacing or reducing user-specific fields to a single one.

[0078] Alternatively, SU PPDU may include a compression field indicating whether compression is required, and depending on the value of the compression field, some fields (e.g., RA field, etc.) may be omitted.

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

[0080] In the case of a SU PPDU, multiple RUs may be assigned to a STA, and the multiple RUs may be consecutive or non-contiguous. If the RUs assigned to the STA are non-contiguous, the STA must recognize the RUs that have been punctured in between to efficiently receive the SU PPDU. Therefore, the AP may transmit the SU PPDU by including information about the punctured RUs among those assigned to the STA (e.g., the puncturing patterns of the RUs). That is, in the case of a SU PPDU, a puncturing mode field containing information indicating whether a puncturing mode is applied and the puncturing pattern in a bitmap format, etc., may be included in the EHT-SIG field, and the puncturing mode field may signal the form of a discontinuous channel appearing within the bandwidth.

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

[0082] The reason only a limited form of discontinuous channel type is signaled is to reduce the signaling overhead of the SU PPDU. Since puncturing can be performed on a per-20 MHz subchannel basis, if puncturing is performed on bandwidths that have multiple 20 MHz subchannels, such as 80, 160, and 320 MHz, in the case of 320 MHz, the usage status of the 15 remaining 20 MHz subchannels (excluding the primary channel) must be indicated for each, thereby signaling the discontinuous channel type (where a form where only the edge 20 MHz is punctured is also considered discontinuous). Allocating 15 bits to signal the discontinuous channel type of a single-user transmission in this manner can act as an excessively large signaling overhead, considering the low transmission speed of the signaling portion.

[0083] The present invention proposes a technique for signaling the discontinuous channel shape of an SU PPDU and illustrates the discontinuous channel shape determined according to the proposed technique. In addition, the invention proposes a technique for signaling the puncturing shapes of the Primary 160 MHz and Secondary 160 MHz respectively in a 320 MHz BW configuration of an SU PPDU.

[0084] In addition, one embodiment of the present invention proposes a technique for varying the configuration of the PPDU indicated by the preamble puncturing BW values ​​according to the PPDU Format signaled in the PPDU Format field. Assuming the length of the BW field is 4 bits, in the case of an EHT SU PPDU or TB PPDU, one symbol of EHT-SIG-A may be additionally signaled after U-SIG or EHT-SIG-A may not be signaled at all; therefore, considering this, it is necessary to fully signal up to 11 puncturing modes through only the BW field of U-SIG. However, in the case of an EHT MU PPDU, EHT-SIG-B is additionally signaled after U-SIG, so up to 11 puncturing modes can be signaled in a different way than the SU PPDU. In the case of an EHT ER PPDU, the BW field can be set to 1 bit to signal whether it is a PPDU using a 20 MHz or 10 MHz band.

[0085] Figure 7(f) illustrates the configuration of the format-specific fields of the VD field when the PPDU Format field of U-SIG is indicated as EHT MU PPDU. In the case of MU PPDU, SIG-B, a signaling field for simultaneous reception by multiple users, is essential, and SIG-B can be transmitted after U-SIG without a separate SIG-A. To this end, U-SIG must signal information for decoding SIG-B. These fields include SIG-B MCS, SIG-B DCM, Number of SIG-B Symbols, SIG-B Compression, and Number of EHT-LTF Symbols fields.

[0086] FIG. 8 shows an example of various EHT (Extremely High Throughput) PPDU (Physical Protocol Data Unit) formats and a method for indicating them according to an embodiment of the present invention.

[0087] Referring to FIG. 8, a PPDU may consist of a preamble and a data portion, and the format of an EHT PPDU, which is one type, can be distinguished according to the U-SIG field included in the preamble. Specifically, whether the format of the PPDU is an EHT PPDU can be indicated based on the PPDU format field included in the U-SIG field.

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

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

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

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

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

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

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

[0095] For convenience of explanation, the terms frame or MAC frame may be used interchangeably with MPDU in this specification.

[0096] When a single wireless communication device communicates using multiple links, the communication efficiency of the wireless communication device can be increased. In this case, a link serves as a physical path and can be composed of a single wireless medium capable of transmitting an MSDU (MAC service data unit). For example, if the frequency band of a single link is being used by another wireless communication device, the wireless communication device can continue to communicate through another link. In this way, the wireless communication device can effectively utilize multiple channels. Furthermore, when a wireless communication device performs communication simultaneously using multiple links, the overall throughput can be increased. However, existing wireless LANs are defined on the premise that a single wireless communication device uses a single link. Therefore, a wireless LAN operation method for using multiple links is required. A wireless communication method for a wireless communication device using multiple links is described through Figures 9 to 26. First, a specific form of a wireless communication device using multiple links is described through Figure 9.

[0097] FIG. 9 shows a multi-link device according to an embodiment of the present invention.

[0098] A multi-link device (MLD) may be defined for the wireless communication method using multiple links described above. A multi-link device may represent a device having one or more affiliated stations. According to specific embodiments, a multi-link device may represent a device having two or more affiliated stations. Additionally, a multi-link device may exchange multi-link elements. A multi-link element contains information about one or more stations or one or more links. A multi-link element may include a multi-link setup element, which will be described later. In this case, the multi-link device may be a logical entity. Specifically, the multi-link device may have multiple affiliated stations. The multi-link device may be referred to as a multi-link logical entity (MLLE) or a multi-link entity (MLE). The multi-link device may have one medium access control service access point (SAP) up to a logical link control (LLC). Additionally, the MLD may have one MAC data service.

[0099] Multiple stations included in a multi-link device may operate on multiple links. Additionally, multiple stations included in a multi-link device may operate on multiple channels. Specifically, multiple stations included in a multi-link device may operate on multiple different links or multiple different channels. For example, multiple stations included in a multi-link device may operate on multiple different channels of 2.4 GHz, 5 GHz, and 6 GHz.

[0100] The operation of a multi-link device may be referred to as multi-link operation, MLD operation, or multi-band operation. Additionally, if a station affiliated with the multi-link device is an AP, the multi-link device may be referred to as AP MLD. Furthermore, if a station affiliated with the multi-link device is a non-AP station, the multi-link device may be referred to as non-AP MLD.

[0101] FIG. 9 illustrates the operation of communication between a non-AP MLD and an AP-MLD. Specifically, the non-AP MLD and the AP-MLD each communicate using three links. The AP MLD includes a first AP (AP1), a second AP (AP2), and a third AP (AP3). The non-AP MLD includes a first non-AP STA (non-AP STA1), a second non-AP STA (non-AP STA2), and a third non-AP STA (non-AP STA3). The first AP (AP1) and the first non-AP STA (non-AP STA1) communicate through a first link (Link1). Additionally, the second AP (AP2) and the second non-AP STA (non-AP STA2) communicate through a second link (Link2). Additionally, the third AP (AP3) and the third non-AP STA (non-AP STA3) communicate through a third link (Link3).

[0102] Multi-link operations may include multi-link setup operations. Multi-link setup corresponds to the association operation of the single-link operation described earlier and may need to be performed first for frame exchange in multi-link. A multi-link device may obtain information necessary for multi-link setup from a multi-link setup element. Specifically, the multi-link setup element may include capability information related to multi-link. In this case, the capability information may include information indicating whether any one of the multiple devices included in the multi-link device can perform transmission while another device can perform reception simultaneously. Additionally, the capability information may include information regarding the links available to each station included in the MLD. Furthermore, the capability information may include information regarding the channels available to each station included in the MLD.

[0103] Multi-link configuration can be established through negotiation between peer stations. Specifically, multi-link configuration can be performed through communication between stations without communication with an AP. Additionally, multi-link configuration can be established through any single link. For example, even if the first to third links are established through multi-link, multi-link configuration can be performed through the first link.

[0104] Additionally, a mapping between a TID (traffic identifier) ​​and a link can be established. Specifically, frames corresponding to a TID of a specific value may be exchanged only through a pre-designated link. The mapping between the TID and the link may be established on a direction-based basis. For example, if multiple links are established between a first multi-link device and a second multi-link device, the first multi-link device may be configured to transmit frames with a first TID to the first link, and the second multi-link device may be configured to transmit frames with a second TID to the first link. Furthermore, a default setting may exist for the mapping between the TID and the link. Specifically, if there are no additional settings in the multi-link configuration, the multi-link device may exchange frames corresponding to the TID on each link according to the default setting. In this case, the default setting may be such that all TIDs are exchanged on a single link.

[0105] TID is explained in detail. TID is an ID used to classify traffic and data to support Quality of Service (QoS). Additionally, TID can be used or assigned at layers higher than the MAC layer. Furthermore, TID can represent a traffic category (TC) or a traffic stream (TS). Additionally, TID can be distinguished by 16 values. For example, a TID can be assigned as any one of 0 to 15. The TID value used may vary depending on the access policy, channel access, or medium access method. For instance, when EDCA (enhanced distributed channel access) or HCAF (hybrid coordination function contention based channel access) is used, the TID value can be assigned from 0 to 7. When EDCA is used, the TID can represent the user priority (UP). In this case, the UP can be assigned based on the TC or TS. The UP can be assigned at a layer higher than the MAC. Additionally, if HCCA (HCF controlled channel access) or SPCA is used, the TID value can be assigned from 8 to 15. If HCCA or SPCA is used, the TID can represent the TSID. Additionally, if HEMM or SEMM is used, the TID value can be assigned from 8 to 15. If HEMM or SEMM is used, the TID can represent the TSID.

[0106] UP and AC can be mapped. AC can be a label for providing QoS in EDCA. AC can be a label for indicating a set of EDCA parameters. EDCA parameters or sets of EDCA parameters are parameters used in channel contention in EDCA. QoS stations can use AC to guarantee QoS. Additionally, AC can include AC_BK, AC_BE, AC_VI, and AC_VO. AC_BK, AC_BE, AC_VI, and AC_VO can represent background, best effort, video, and voice, respectively. Furthermore, AC_BK, AC_BE, AC_VI, and AC_VO can be classified into sub-ACs. For example, AC_VI can be subdivided into AC_VI primary and AC_VI alternate. Also, AC_VO can be subdivided into AC_VO primary and AC_VO alternate. Additionally, UP or TID can be mapped to AC. For example, 1, 2, 0, 3, 4, 5, 6, and 7 of UP or TID can each be mapped to AC_BK, AC_BK, AC_BE, AC_BE, AC_VI, AC_VI, AC_VO, and AC_VO, respectively. Additionally, 1, 2, 0, 3, 4, 5, 6, and 7 of UP or TID can each be mapped to AC_BK, AC_BK, AC_BE, AC_BE, AC_VI alternate, AC_VI primary, AC_VO primary, and AC_VO alternate, respectively. Furthermore, 1, 2, 0, 3, 4, 5, 6, and 7 of UP or TID may have higher priorities in that order. That is, 1 may have a lower priority and 7 may have a higher priority. Therefore, the priorities may increase in the order of AC_BK, AC_BE, AC_VI, and AC_VO.Additionally, AC_BK, AC_BE, AC_VI, and AC_VO can each correspond to ACI (AC index) 0, 1, 2, and 3, respectively. Due to these characteristics of TID, the mapping between TID and a link can represent the mapping between AC and a link. Also, the mapping between a link and an AC can represent the mapping between TID and a link.

[0107] As previously explained, a TID can be mapped to each of multiple links. The mapping may designate the links on which traffic corresponding to a specific TID or AC can be exchanged. Additionally, TIDs or ACs that can be transmitted within a link may be designated for each transmission direction. As previously explained, there may be default settings for the mapping between TIDs and links. Specifically, in a multi-link configuration where no additional settings are present, the multi-link device may exchange frames corresponding to TIDs on each link according to the default settings. In this case, the default setting may be that all TIDs are exchanged on a single link. At any given time, any TID or AC can always be mapped to at least one link. Management frames and control frames can be transmitted on all links.

[0108] If a link is mapped to a TID or AC, only data frames corresponding to the TID or AC mapped to that link can be transmitted on that link. Therefore, if a link is mapped to a TID or AC, frames that do not correspond to the TID or AC not mapped to that link cannot be transmitted on that link. If a link is mapped to a TID or AC, ACKs can also be transmitted based on the link to which the TID or AC is mapped. For example, a block ACK agreement can be determined based on the mapping between the TID and the link. In another specific embodiment, the mapping between the TID and the link can be determined based on the block ACK agreement. Specifically, a block ACK agreement can be established for a TID mapped to a specific link.

[0109] QoS can be guaranteed through the mapping between TIDs and links described earlier. Specifically, high-priority ACs or TIDs can be mapped to links with a relatively small number of operating stations or good channel conditions. Additionally, through the aforementioned mapping between TIDs and links, stations can be allowed to remain in a power-saving state for a longer period of time.

[0110] FIG. 10 shows that transmission of different links is performed simultaneously in a multi-link operation according to an embodiment of the present invention.

[0111] Depending on the implementation of a multi-link device, simultaneous operation on multiple links may not be supported. For example, a multi-link device may not support simultaneous transmission on multiple links, simultaneous reception on multiple links, or transmission on one link while reception on another link simultaneously. This is because reception or transmission performed on one link may affect reception or transmission performed on another link. Specifically, transmission on one link may act as interference on another link. Interference acting from one link of a multi-link device on another link can be referred to as internal leakage. Internal leakage can increase as the frequency spacing between links decreases. If internal leakage is not too large, transmission on another link may occur while transmission is being performed on one link. If internal leakage is large, transmission on another link cannot occur while transmission is being performed on one link. Such simultaneous operation by a multi-link device on multiple links can be referred to as STR (simultaneous transmit and receive, simultaneous transmission and reception). For example, a multi-link device transmitting simultaneously on multiple links, transmitting on one link and receiving on another link simultaneously, or receiving simultaneously on multiple links can be called STR.

[0112] As previously mentioned, a multi-link device may support STR, or it may support it only to a limited extent. Specifically, a multi-link device may support STR only under specific conditions. For example, if the multi-link device operates as a single radio, the multi-link device may not be able to perform STR. Also, if the multi-link device operates as a single antenna, the multi-link device may not be able to perform STR. Additionally, if an internal leak is detected to be greater than a predetermined size, the multi-link device may not be able to perform STR.

[0113] A station may exchange information regarding the station's STR capabilities with other stations. Specifically, a station may exchange information with other stations regarding whether there are limitations on the station's ability to perform simultaneous transmission or simultaneous reception on multiple links. Specifically, information regarding limitations on the ability to perform transmission or reception on multiple links may indicate whether simultaneous transmission, simultaneous reception, or simultaneous transmission and reception can be performed on multiple links. Additionally, information regarding limitations on the ability to perform transmission or reception on multiple links may be information indicated step by step. Specifically, information regarding limitations on the ability to perform transmission or reception on multiple links may be information indicating a step indicating the magnitude of internal leakage. In a specific embodiment, information indicating a step indicating the magnitude of internal leakage may be information indicating a step indicating the magnitude of interference caused by internal leakage. In another specific embodiment, information indicating a step indicating the frequency spacing between links that may affect internal leakage may be information indicating a step indicating the relationship between the frequency spacing between links and the magnitude of internal leakage. Additionally, information indicating a step indicating the magnitude of internal leakage may be information indicating the relationship between the frequency spacing between links and the magnitude of internal leakage in step by step.

[0114] In FIG. 10, the first station (STA1) and the second station (STA2) are affiliated with a single non-AP multi-link device. Additionally, the first AP (AP1) and the second AP (AP2) may be affiliated with a single non-AP multi-link device. A first link (link 1) is established between the first AP (AP1) and the first station (STA1), and a second link (link 2) is established between the second AP (AP2) and the second station (STA2). In FIG. 10, the non-AP multi-link device may perform STR in a limited manner. When the second station (STA2) performs transmission on the second link (Link 2), reception by the first station (STA1) on the first link (Link 1) may be interfered with by the transmission performed on the second link (Link 2). For example, in the following case, reception by the first station (STA1) on the first link (Link 1) may be interfered with by transmission performed on the second link (Link 2). On the second link (Link 2), the second station (STA2) transmits the first data (Data1), and the first AP (AP1) transmits an acknowledgment (Ack for Data1) for the first data (Data1) to the first station (STA1). On the second link (Link 2), the second station (STA2) transmits the second data (Data2). At this time, the transmission time of the second data (Data2) and the transmission time of the acknowledgment (Ack for Data1) for the first data (Data1) may overlap. At this time, interference may occur on the first link (Link 1) due to transmission from the second link (Link 2) to the second station (STA2). Consequently, the first station (STA1) may not be able to receive the acknowledgment (Ack for Data1) for the first data (Data1).

[0115] The operation of a multi-link device performing channel access is described. The operation of a multi-link without specific description may follow the channel access procedure described through FIG. 6.

[0116] A multi-link device can perform channel access independently on multiple links. In this case, the channel access may be backoff-based channel access. When the multi-link device performs channel access independently on multiple links and the backoff counter on multiple links reaches zero, the multi-link device can start transmission simultaneously on multiple links. In a specific embodiment, if any one of the backoff counters of the links of the multi-link reaches zero and satisfies a predetermined condition, the multi-link device can perform channel access not only on the link where the backoff counter reached zero but also on other links where the backoff counter has not reached zero. Specifically, when any one of the backoff counters of the links of the multi-link reaches zero, the multi-link device can perform energy sensing on other links where the backoff counter has not reached zero. In this case, if energy exceeding a predetermined size is not detected, the multi-link device can perform channel access not only on the link where the backoff counter reached zero but also on the link where energy sensing was performed. Through this, the multi-link device can start transmission simultaneously on multiple links. The magnitude of the threshold value used for energy detection may be smaller than the magnitude of the threshold value used to determine whether to reduce the backoff counter. Additionally, when determining whether to reduce the backoff counter, the multi-link device can detect any type of signal, not just wireless LAN signals. Furthermore, in the energy detection described earlier, the multi-link device can detect any type of signal, not just wireless LAN signals. Internal leakage may not be detected as a wireless LAN signal. In such cases, the multi-link device can sense the signal detected due to internal leakage through energy detection. Also, as previously explained, the magnitude of the threshold value used for energy detection may be smaller than the magnitude of the threshold value used to determine whether to reduce the backoff counter.Therefore, even if transmission is being performed on one link, a multi-link device can reduce the backoff counter on another link.

[0117] Depending on the degree of interference between the links used by the multi-link device, it may be determined whether the stations operating on each link can operate independently. In this case, the degree of interference between the links may be the magnitude of interference detected by another station of the multi-link device when one station of the multi-link device performs transmission on one link. If the transmission of the first station of the multi-link device on the first link causes interference exceeding a predetermined magnitude to the second station of the multi-link device operating on the second link, the operation of the second station may be restricted. Specifically, reception or channel access by the second station may be restricted. This is because, if interference occurs, the second station may fail to decode the received signal due to the interference. Additionally, if interference occurs, the second station may determine that the channel is in use when accessing the channel using backoff.

[0118] Additionally, if the transmission of the first station of the multi-link device on the first link causes interference of less than a predetermined size to the second station of the multi-link device operating on the second link, the first station and the second station may operate independently. Specifically, if the transmission of the first station of the multi-link device on the first link causes interference of less than a predetermined size to the second station of the multi-link device operating on the second link, the first station and the second station may perform channel access independently. Furthermore, if the transmission of the first station of the multi-link device on the first link causes interference of less than a predetermined size to the second station of the multi-link device operating on the second link, the first station and the second station may perform transmission or reception independently. This is because, when interference of less than a predetermined size occurs, the second station can succeed in decoding the received signal even if interference is present. Additionally, when interference of less than a predetermined size occurs, the second station may determine that the channel is idle when performing channel access using backoff.

[0119] The degree of interference occurring between stations of a multi-link device can vary depending not only on the spacing between the frequency bands of the links in which the stations operate but also on the hardware characteristics of the multi-link device. For example, internal interference occurring in a multi-link device containing high-cost RF (radio frequency) devices may be smaller than internal interference occurring in a multi-link device containing low-cost RF devices. Therefore, the degree of interference occurring between stations of a multi-link device can be determined based on the characteristics of the multi-link device.

[0120] FIG. 10 shows that the magnitude of interference generated varies depending on the spacing between the frequency bands of the links and the characteristics of the multi-link device. In the embodiment of FIG. 10, the first multi-link device (MLD#1) includes a first station (STA1-1) operating on the first link (Link1) and a second station (STA1-2) operating on the second link (Link2). The second multi-link device (MLD#2) includes a first station (STA2-1) operating on the first link (Link1) and a second station (STA2-2) operating on the second link (Link2). The frequency spacing between the first link (Link1) and the second link (Link2) where the first multi-link device (MLD#1) operates is the same as the frequency spacing between the first link (Link1) and the second link (Link2) where the second multi-link device (MLD#2) operates. However, the magnitude of interference caused by the difference in characteristics between the first multi-link device (MLD#1) and the second multi-link device (MLD#2) is different. Specifically, the magnitude of interference caused by the second multi-link device (MLD#2) may be greater than the magnitude of interference caused by the first multi-link device (MLD#1). Considering that the magnitude of interference caused by the characteristics of the multi-link devices may vary and that STR support may vary by multi-link device, it is necessary to exchange information regarding STR support.

[0121] A multi-link device can signal whether a station included in the multi-link device supports STR. Specifically, an AP multi-link device and a non-AP multi-link device can exchange whether the AP included in the AP multi-link device supports STR and whether the STA included in the non-AP multi-link device supports STR. In these embodiments, an element indicating whether STR is supported may be used. The element indicating whether STR is supported may be referred to as the STR support element. The STR support element may indicate whether the station of the multi-link device that transmitted the STR support element supports STR through 1 bit. Specifically, the STR support element may indicate whether each station included in the multi-link device that transmitted the STR support element supports STR on a 1-bit basis. In this case, if the station supports STR, the value of the bit may be 1, and if the station does not support STR, the value of the bit may be 0. If a multi-link device that transmitted an STR support element includes a first station (STA1), a second station (STA2), and a third station (STA3), and the first station (STA1) and the third station (STA3) support STR while the second station (STA2) does not support STR, then the STR support element is 101 1bIt may include a field having. Stations operating in different frequency bands are assumed to support STR, and the STR support element may omit signaling regarding whether STR is supported between stations operating in different frequency bands. For example, a first station (STA1) operates on a first link of 2.4 GHz, and a second station (STA2) and a third station (STA3) each operate on a second link and a third link of 5 GHz, respectively. In this case, the STR support element may use 1 bit to indicate that STR is supported between the second station (STA2) and the third station (STA3). Additionally, the STR support element may include only 1 bit when there are two stations signaled by the STR support element.

[0122] In a specific embodiment, the relationship between a link located at 2.4 GHz and a link located at 5 GHz or 6 GHz among the links of a multi-link device can always be determined to be STR. Therefore, signaling regarding whether the link located at 2.4 GHz and the link located at 5 GHz or 6 GHz is STR may be omitted.

[0123] In the embodiments described above, the operation of a station of a multi-link device can be substituted with the operation of a multi-link device. Additionally, in the embodiments described above, the operation of an AP can be substituted with the operation of a non-AP station, and the operation of a non-AP station can be substituted with the operation of an AP. Accordingly, the operation of an AP of a non-STR multi-link device can be substituted with the operation of a non-AP station of a non-STR multi-link device, and the operation of a non-AP station of an STR multi-link device can be substituted with the operation of an AP of an STR multi-link device. Furthermore, the operation of a non-AP station of a non-STR multi-link device can be substituted with the operation of an AP of a non-STR multi-link device, and the operation of an AP of an STR multi-link device can be substituted with the operation of a non-AP station of an STR multi-link device.

[0124] Scheduling for low-latency traffic transmission is explained through FIGS. 11 to 15. In conventional wireless LAN communication, channel access parameters are set for each AC via EDCA (enhanced distributed channel access), and traffic is processed according to the priority of each AC using the set channel access parameters. However, since existing EDCA provides channel access with a probabilistically higher priority, it was insufficient to support the transmission of low-latency traffic. To compensate for this, a time interval during which low-latency traffic can be transmitted preferentially can be established. For the sake of convenience of explanation, the time interval during which low-latency traffic is transmitted preferentially is referred to as the "limited service period." Since most services requiring low-latency traffic transmission, such as VR / AR, require periodic traffic transmission, the effect of reducing transmission delay of low-latency traffic due to the limited service period is significant.

[0125] A restricted service period may be a time interval in which the transmission of low-latency traffic and the transmission of responses to low-latency traffic are preferentially permitted. Specifically, within the restricted service period, only the transmission of low-latency traffic and the transmission of responses to low-latency traffic are permitted. In another specific embodiment, within the restricted service period, the transmission of low-latency traffic and the transmission of responses to low-latency traffic are performed, and after the transmission of low-latency traffic and the transmission of responses to low-latency traffic are completed, the transmission of traffic other than low-latency traffic is permitted.

[0126] First, the method for setting a limited service period will be explained. A limited service period can be set through the existing WLAN's TWT. The TWT sets the service period through agreement between the AP and the station, enables the AP and the station to perform transmission and reception during the service period, and supports entering a low-power mode during periods outside the service period. This will be explained in detail through Fig. 11. For convenience of explanation, the setting of a limited service period through the TWT and the operation of the AP and the station based on the limited service period will be referred to as a limited TWT.

[0127] FIG. 11 shows a method for establishing a broadcast TWT between an AP and a station according to an embodiment of the present invention.

[0128] In TWT, the service period can be configured as follows. The AP requests stations associated with the AP to participate in the TWT. Stations may participate in the broadcast TWT or negotiate with the AP regarding an individual TWT. In this case, the AP can request the station to participate in the TWT by setting the value of the TWT Required subfield of the HE Operation element to 1. Additionally, the AP can transmit the Broadcast TWT element via a management frame, such as a beacon frame, to convey the information necessary for participating in the broadcast TWT to the station. In this case, the AP can signal support for the broadcast TWT by setting dot11TWTOptionActivated to true and the Broadcast TWT Support field of the HE Capabilities element to 1. The AP can configure a restricted service period similar to the TWT service period.

[0129] In the embodiment of FIG. 11, the first station (STA1) requests the AP to set up a TWT. The AP and the first station (STA1) set TWT parameters, such as the initial TBTT and the listen interval. Accordingly, the AP, the first station (STA1), and the second station (STA2) set up a broadcast TWT. The AP uses a beacon frame to indicate the broadcast TWT service period. During the broadcast TWT service period, the AP may send a DL (downlink) PPDU (physical layer protocol data unit) to the first station (STA1) and the second station (STA2), or send a trigger frame to the first station (STA1) and the second station (STA2) to trigger an UL (uplink) transmission. During the broadcast TWT service period, the first station (STA1) and the second station (STA2) wake up to receive the beacon frame. The first station (STA1) and the second station (STA2) obtain information regarding the TWT from the received beacon frame. The AP transmits a trigger frame to the first station (STA1) and the second station (STA2), the first station (STA1) transmits a PS-Poll frame to the AP, and the second station (STA2) transmits a QoS Null frame to the AP. The AP receives the PS-Poll frame and QoS Null frame transmitted by the first station (STA1) and the second station (STA2), and determines that the first station (STA1) and the second station (STA2) are in an awake state. The AP transmits a multi-STA Block ACK frame to the first station (STA1) and the second station (STA2). The AP transmits a DL PPDU to the first station (STA1) and the second station (STA2).

[0130] The existing TWT service period does not restrict stations not participating in the TWT from performing channel access or transmission. This is because the TWT is intended to help stations participating in the TWT enter a doze state. However, since the restricted service period intended to prevent transmission delays of low-latency traffic must guarantee the priority transmission of low-latency traffic, a method is required to protect the restricted service period.

[0131] During a restricted service period, channel access by stations not participating in the restricted TWT may be restricted. Specifically, during a restricted service period, stations not participating in the restricted TWT may be unable to perform channel access. If a station not participating in the restricted TWT completes channel access during a restricted service period, that station may restart the channel access procedure without performing a transmission. In this case, the station may restart the channel access procedure when the restricted service period ends. Additionally, the station's channel access may represent the EDCA backoff procedure. Completion of channel access may indicate that the backoff counter of the EDCA backoff procedure has reached zero. Furthermore, when the station restarts the channel access procedure, the station may obtain a random integer from the CW used for the previous channel access and use the obtained integer as the backoff counter. That is, the station may not double the size of the CW used for the previous channel access. In this case, the CW may be maintained per AC. These channel access restrictions may apply only to stations that support restricted TWT. Specifically, these channel access restrictions may apply only to non-legacy (EHT) stations where dot11RestrictedTWTOptionImplemented in the EHT Capabilities element is set to true, and may not apply to non-legacy (EHT) stations where dot11RestrictedTWTOptionImplemented in the EHT Capabilities element is set to false. In this specification, non-legacy stations may refer to EHT stations and stations after EHT stations. Additionally, legacy stations may refer to stations prior to EHT stations, such as non-HT stations, HT stations, VHT stations, and HE stations.

[0132] Additionally, during a limited service period, a NAV may be set for traffic other than low-latency traffic for non-legacy stations. Specifically, when a NAV is set for traffic other than low-latency traffic, the station may stop the channel access procedure for the transmission of traffic other than low-latency traffic. In this embodiment, the NAV may be a NAV independent of the conventional NAV (Basic NAV, Intra-BSS NAV). In this case, the non-legacy station may be limited to a station that supports a limited TWT. In another specific embodiment, the non-legacy station may be limited to a station that participates in a limited TWT.

[0133] A limited service period may be included within a broadcast TWT service period. In another specific embodiment, a limited service period may not be included within a broadcast TWT service period.

[0134] Additionally, the restricted service period can be repeated at a period specified by the AP. That is, the AP can specify the repetition period of the restricted service period. Through this, the AP can avoid sending the TWT element of the beacon frame every time to establish the restricted service period. In this case, the period of the service period can be set according to the characteristics of the low-latency service where low-latency traffic is used. For example, the period of a low-latency service period where low-latency traffic is generated every 50ms can be 50ms.

[0135] In addition, a Quiet Interval may be set for stations that do not support limited TWT. In conventional wireless LANs, a Quiet Interval is a period for supporting channel sensing. When a Quiet Interval is set, all stations stop transmission. By utilizing the characteristics of this Quiet Interval, a limited service period can be protected. This is explained through Fig. 12. In this case, stations that do not support limited TWT may be limited to legacy stations.

[0136] FIG. 12 shows that AP sets a quiet interval according to an embodiment of the present invention.

[0137] An AP operating a restricted TWT can set a quiet period by transmitting a Quiet element. During the quiet period, stations suspend channel access. However, if channel access is restricted for stations participating in the restricted TWT, the transmission of low-latency traffic cannot be performed. Therefore, stations participating in the restricted TWT may ignore the quiet period corresponding to the restricted service period. In this case, the quiet period corresponding to the restricted service period refers to the quiet period set to protect the restricted service period of the restricted TWT. Specifically, stations participating in the restricted TWT may regard the quiet period corresponding to the restricted service period as the restricted service period. An AP operating a restricted TWT may not set the quiet period to match the restricted service period. This is because the quiet period in the Quiet element is set in TU (time unit, 1024us) units, while the TWT is set in 256us units.

[0138] However, if channel access is performed in a quiet period other than a quiet period that is not configured for a restricted service period, it may interfere with the quiet period that is not configured for a restricted service period. Therefore, it is necessary to distinguish the quiet period configured for a restricted service period, that is, the quiet period corresponding to the restricted service period. Accordingly, a station participating in a restricted TWT may not be able to ignore a quiet period that does not correspond to a restricted service period. In a quiet period that does not correspond to a restricted service period, the station cannot perform any transmissions. Specifically, a station participating in a restricted TWT may not be able to ignore a quiet period that does not overlap with the restricted service period. In a specific embodiment, a station participating in a restricted TWT cannot perform any transmissions in a quiet period that does not overlap with the restricted service period.

[0139] In addition, in the preceding embodiments, a station participating in the restricted TWT may be considered as a quiet period corresponding to the restricted service period if the start time of the restricted service period and the start time of the quiet period are within a predetermined time, and the start time of the service period and the start time of the quiet period are within a predetermined time. This is because, as previously explained, an AP operating the restricted TWT may not set the quiet period to coincide with the restricted service period.

[0140] In the embodiment of FIG. 12, the AP transmits a beacon frame to establish a quiet period and a restricted service period. In FIG. 12(a), the quiet period is set to the same time interval as the restricted service period. Therefore, during the quiet period, stations participating in the restricted TWT perform channel access. In FIG. 12(b), the quiet period is set from a time earlier than the start time of the restricted service period to a time later than the end time of the restricted service period. In FIG. 12(b), channel access by stations participating in the restricted TWT is restricted during the quiet period that does not overlap with the restricted service period. Stations participating in the restricted TWT perform channel access during the quiet period that overlaps with the restricted service period.

[0141] As previously explained, channel access may be restricted during a limited service period. Accordingly, such restrictions may also apply to TXOP settings. This is explained through Fig. 13.

[0142] FIG. 13 illustrates a method for setting a TXOP in consideration of a limited service period for a station according to an embodiment of the present invention.

[0143] A station that acquired a TXOP before the restricted service period began, i.e., a station that is the TXOP holder, may need to terminate the TXOP before the restricted service period began. This is because if the TXOP holder's frame exchange continues even after the restricted service period has started, it may interfere with the transmission of low-latency traffic. In this case, the station may be a non-legacy station. In another specific embodiment, the station may be limited to a station that supports restricted TWT. That is, a station that sets the value of the dot11RestrictedTWTOptionImplemented field to false may not be subject to this restriction.

[0144] In a specific embodiment, when a station that is a TXOP holder transmits low-latency traffic, frame exchange can continue even after a limited service period has started.

[0145] Explain the specific method for a station to terminate a TXOP before the limited service period.

[0146] A station can set a TXOP based on a limited service period. Specifically, the station can set the end time of the TXOP to before the start of the limited service period. In this case, the station can set the duration of the initiation frame that initiates the frame switching sequence to before the start of the limited service period. For example, if the time when the station successfully accesses the channel is 3 ms before the start of the limited service period, the station can set the TXOP to 3 ms before. Additionally, the station can terminate the TXO by transmitting a CTS-to-Self frame. In this case, the station can transmit the CTS-to-Self frame at the default transmission rate, 6 Mbps. This is because when the station transmits the frame at the default transmission rate, many legacy stations can receive the frame.

[0147] In another specific embodiment, the station can transmit a CF-End frame before the start of a limited service period. This allows the station to terminate the TXOP before the start of the limited service period. In this case, the station can transmit the CF-End frame at a base transmission rate of 6 Mbps. This is because when the station transmits the frame at the base transmission rate, many legacy stations can receive the frame.

[0148] Additionally, a station that is not a TXOP holder may release the NAV set prior to the start of the restricted service period at the start of the restricted service period. In this case, the station may be a station that supports restricted TWT. That is, the station may be a station that has set the value of the dot11RestrictedTWTOptionImplemented field to True. A station that is not a TXOP holder but does not support restricted TWT cannot release the NAV set prior to the start of the restricted service period at the start of the restricted service period. However, if the station completes frame exchange and the remaining duration of the TXOP is less than twice the sum of the time required to transmit the CF-End frame and the SIFS, the station may not transmit the CF-End frame. In this case, the station may be deemed to have released the TXOP at the start of the restricted service period. Specifically, the station may be deemed to have released the basic NAV at the start of the restricted service period.

[0149] In another specific embodiment, the station may be limited to a station participating in a limited TWT.

[0150] In the embodiment of FIG. 13, the AP transmits a beacon frame containing a TWT element to signal that a limited service period has been established. In the embodiment of FIG. 13(a), the station transmits an RTS frame to establish a TXOP. At this time, the station sets the value of the duration field of the RTS frame to before the limited service period. The station performs frame exchange with the AP and completes the frame exchange before the start of the limited service period. At this time, the station finally transmits a CTS-to-Self frame. In the embodiment of FIG. 13(b), the station transmits an RTS frame to establish a TXOP. At this time, the station sets the value of the duration field of the RTS frame without considering the limited service period. The station performs frame exchange with the AP and completes the frame exchange before the start of the limited service period. At this time, the station finally transmits a CF-end frame to release the TXOP.

[0151] In conventional wireless LAN operations, exceptions to TXOP rules define operations that may be transmitted beyond the TXOP limit. For example, the retransmission of a single MPDU, the transmission of a single MSDU under Block ACK agreement (not included in an A-MSDU or an A-MPDU composed of two or more MPDUs), and the transmission of control frames and QoS Null frames (not included in an A-MPDU composed of two or more MPDUs) may be transmitted beyond the TXOP limit. If such exceptions are allowed even for a limited service period, the transmission of low-latency traffic may be delayed. Such exceptions to the TXOP limit cannot be applied in violation of the limited service period.

[0152] If the end time of a TXOP and the start time of a limited service period are within a predetermined time difference, the station may determine that the TXOP was acquired before the start of the limited service period. The predetermined time may be 100 µs. In another specific embodiment, if the end time of a TXOP is within the limited service period, the station may determine that the TXOP was acquired before the start of the limited service period.

[0153] As previously explained, a station may need to complete frame exchange before the restricted service period. Accordingly, a station may not be permitted to initiate frame exchange if the completion time of the frame exchange falls within the restricted service period. In this case, the station may perform fragmentation to complete the frame exchange before the start of the restricted service period.

[0154] In addition, if low-latency traffic is transmitted during frame exchange performed by a station that is a TXOP holder, the station can continue frame exchange even after the start of the low-latency service period.

[0155] A channel access procedure considering a limited service period is explained through Fig. 14.

[0156] FIG. 14 shows that a station according to an embodiment of the present invention performs the channel access procedure again considering the limited service period.

[0157] As previously explained, even if a station completes channel access before the restricted service period, if the frame exchange completion time is after the start of the restricted service period, the station may restart the channel access procedure without performing a transmission. In this case, the station may reacquire the value of the backoff counter. At this time, the station may use the same size of the CW used in the previous channel access procedure. That is, the station may not double the size of the CW used in the previous channel access procedure, nor may it initialize the CW to the minimum value it can have. Additionally, the station may not increase the number of retries, such as the QSRC (QoS STA Retry Counter).

[0158] Additionally, if the time at which the station completes channel access is within a preset time from the start of the limited service period, the station may restart the channel access procedure without performing transmission.

[0159] In the preceding embodiments, a station intending to transmit low-latency traffic may initiate frame exchange after channel access is completed, even if the frame exchange completion time is after the start of a restricted service period. This exception may be permitted only if the station intending to transmit low-latency traffic is a station participating in a restricted TWT.

[0160] In addition, as explained earlier, the station can operate as if NAV were set on the AC for traffic other than low-latency traffic. Therefore, the station can determine that the CCA result for the transmission of the AC for traffic other than low-latency traffic is not idle (BUSY).

[0161] In the embodiment of FIG. 14, the AP transmits a beacon frame containing a TWT element to signal that a restricted service period has been established. Before the restricted service period begins, the backoff counter value of the station's channel access reaches 0. The station determines that the time when the frame exchange containing the traffic to be transmitted is completed is after the start time of the service period. Accordingly, the station obtains a backoff counter within the CW value used in the previous channel access procedure. The station performs the channel access procedure again using the obtained backoff counter. At this time, the station does not increment the retransmission counter.

[0162] All low-latency traffic transmissions may be completed before the limited service period is finished. In such cases, it may be inefficient to restrict the transmission of traffic other than low-latency traffic due to the low-latency service period. Therefore, a method to terminate the limited service period early may be required. This will be explained through the embodiment of FIG. 15.

[0163] FIG. 15 shows an operation in which an AP terminates a limited service period early according to an embodiment of the present invention.

[0164] In order for the AP to terminate the restricted service period early, it must be able to determine that all low-latency traffic transmissions by the station participating in the restricted TWT have been completed. To this end, the station participating in the restricted TWT may signal whether to transmit additional low-latency traffic in the frame being transmitted. Specifically, the station may signal to transmit additional low-latency traffic by setting the value of the More data subfield of the Frame Control field of the frame. In this case, if the value of the More data subfield of the Frame Control field of the frame transmitted during the restricted service period is 1, the More data subfield indicates that additional low-latency traffic needs to be transmitted and may not indicate whether additional transmission of traffic other than low-latency traffic is needed. For example, if a station participating in the restricted TWT does not store low-latency traffic in the transmission buffer and stores only traffic other than low-latency traffic, the station may set the value of the More data subfield of the Frame Control field of the frame transmitted by the station during the restricted service period to 0. AP may terminate the restricted service period early based on whether the value of the More data subfield of the Frame Control field of a frame is not zero for a station participating in the restricted TWT during the restricted service period. Specifically, if there is no low-latency traffic to transmit in the AP’s transmission buffer and the value of the More data subfield of the Frame Control field of a frame is not zero for a station participating in the restricted TWT during the restricted service period, AP may terminate the restricted service early.

[0165] The AP may terminate the limited service period early by transmitting a pre-designated control frame. In this case, the control frame may be a CF-End frame. In this case, the AP may set the BSSID (TA) field of the CF-End frame to the AP's MAC address or BSSID. Additionally, the AP may set the Individual / Group bit of the BSSID (TA) field of the CF-End frame to 1. In another specific embodiment, the AP may terminate the limited service period early by transmitting a pre-designated management frame.

[0166] A station that receives a frame pre-designated to terminate the restricted service period within the restricted service period may determine that the restricted service period has ended. At this time, the station that receives the pre-designated frame may resume channel access without the restrictions applied to the restricted service period. As previously explained, the pre-designated frame may be a CF-End frame. At this time, if the value of the TA (BSSID) field of the CF-End frame received by the station within the restricted service period is the MAC address of the AP to which the station is associated, the station may determine that it is a CF-End frame terminating the restricted service period.

[0167] As previously explained, a quiet period for a restricted service period may be established to protect the restricted service period from legacy wireless communication terminals. In this case, the AP may transmit a CF-End frame to terminate the restricted service period. This is because if the AP transmits a CF-End frame, the quiet period established for the legacy station can also be released.

[0168] In the embodiments described above, the CF-End frame may be a frame where the Type of the Frame Control field is a control frame (Type value B3 B2 == 01) and the Subtype is a CF-End frame (Subtype value B7 B6 B4 B4 == 1110).

[0169] When a quiet period is established for a restricted service period, stations participating in the restricted TWT may not be allowed to transmit CF-End frames within the restricted service period. In a specific embodiment, stations participating in the restricted TWT may not be allowed to transmit CF-End frames during the quiet period corresponding to the restricted service period. This is because if a station participating in the restricted TWT transmits a CF-End frame, the NAV set on the legacy station is released. However, as previously described, if a CF-End frame is used to terminate the restricted service period early, the AP may transmit a CF-End frame within the restricted service period.

[0170] In the embodiment of FIG. 15, the AP transmits a beacon frame containing a TWT element and a Quiet element. A station supporting restricted TWT determines that a restricted service period has been set, while a station not supporting restricted TWT determines that a quiet period has been set. When the AP determines that the transmission of all low-latency traffic has been completed within the restricted service period, the AP transmits a CF-End frame to terminate the restricted service period early and release the quiet period set for the legacy station. At this time, the station supporting restricted TWT determines that the channel access restriction applied during the restricted service period has been lifted. Specifically, if an embodiment in which NAV is set during the restricted service period is applied as described above, the station supporting restricted TWT may determine that the NAV for the restricted service period has been released. Additionally, a station not supporting restricted TWT that receives the CF-End frame releases the NAV.

[0171] As previously explained, each station included in a multi-link device can perform association with other stations. Therefore, each station included in a multi-link device can operate an individual TWT service period. In other words, an individual TWT service period can be operated on each of the multiple links where the multi-link device operates. To operate individual TWT service periods in this manner, individual TWT agreements may be required. To this end, a station in the multi-link device transmits a TWT request frame, and a station receiving the TWT request frame transmits a TWT response frame. The TWT request frame may be a frame in which the value of the Command field of the TWT setup frame is 0 to 2. Additionally, the TWT response frame may be a frame in which the value of the Command field of the TWT setup frame is 3 to 7. The specific TWT agreement method may be the same as that defined in IEEE 802.11ax.

[0172] Through TWT operation, a station can perform power saving. Therefore, to increase power saving efficiency, a multi-link device can set TWT service periods on multiple links where the multi-link device operates. For example, a multi-link device including a first station and a second station can set TWT service periods on a first link where the first station operates and a second link where the second station operates, and synchronize the operating states (awake state, doze state) of the first station and the second station. In this case, the first station can transmit a TWT request frame to the first AP to which the first station is connected, and the second station can transmit a TWT request frame to the second AP to which the second station is connected. In this case, the TWT parameter values ​​indicated by the TWT request frame transmitted by the first station and the TWT request frame transmitted by the second station may be identical. Therefore, transmitting TWT request frames individually on multiple links may reduce transmission efficiency. In a specific embodiment of the present invention, a TWT request frame transmitted over a single link can perform TWT consensus over multiple links. This is explained through FIG. 16.

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

[0174] A TWT request frame for TWT consensus performed on multiple links may be transmitted from the first link. In this case, the TWT request frame may include TWT parameters for TWT operations performed on multiple links. Additionally, a TWT request frame for TWT consensus performed on the second link may be transmitted from the first link. In this case, the TWT request frame may include TWT parameters for TWT operations performed on the second link. For example, when a multi-link device includes a first station operating on the first link and a second station operating on the second link, the first station may establish a TWT consensus for the second station. In this case, if the first station is coupled with the first AP and the second station is coupled with the second AP, and the first AP and the second AP are included in a single multi-link device, the first station may establish a TWT consensus with the first AP. This is because the stations included in the multi-link device may share some functions of the MAC layer or share some information. A TWT element of a new format may be required for the TWT consensus operation described above.

[0175] Specifically, the TWT element may include information about the link where TWT consensus is performed. In this case, the information about the link may be information regarding the ID of the link operated by the AP. In a specific embodiment, the TWT element may indicate multiple links where TWT consensus is performed. For example, the information about the link may be a bitmap. In this case, each bit of the bitmap may indicate whether the TWT element is performed on each of the multiple links. A station can perform TWT consensus on multiple links by transmitting such TWT elements.

[0176] The bitmap described earlier can be referred to as the Link ID (identifier) ​​bitmap. The size of the Link ID bitmap can be 2 octets. For example, the value of the Link ID bitmap is 1110 0000 0000 0000 2b In this case, the Link ID bitmap may indicate that the TWT negotiation is for a first link corresponding to the first bit, a second link corresponding to the second bit, and a third link corresponding to the third bit. In these embodiments, a link element containing information regarding TWT parameters for links other than the link to which the link element is transmitted may be transmitted. Additionally, in these embodiments, a single link element may be transmitted for TWT consensus performed on multiple links.

[0177] Additionally, the TWT element may include a TWT flow ID representing an identifier applied to the TWT consensus. If the TWT element is intended to perform a TWT consensus across multiple links, the TWT flow ID included in the TWT element may be a value not used in the TWT consensus of all links where the TWT element can perform the TWT consensus. In another specific embodiment, if the TWT element is intended to perform a TWT consensus across multiple links, the TWT element may include a field for indicating multiple TWT flow IDs. For example, if the TWT element is intended to perform a TWT consensus across multiple links, the TWT element may include multiple sub-fields indicating each of the multiple TWT flow IDs. In this case, the multiple sub-fields may correspond to each of the multiple links where the TWT element can perform the TWT consensus. In these embodiments, a TWT flow ID not used by the link corresponding to each sub-field may be used. Additionally, if a TWT element intends to modify the TWT consensus of a link corresponding to a subfield, the TWT flow ID previously used by the link corresponding to the subfield may be used in the subfield. This is because there exists a TWT consensus in which the TWT flow ID was previously used. Therefore, when a station intends to perform a new TWT consensus, the station may be restricted to using a TWT flow ID that does not correspond to the TWT flow ID of the existing TWT consensus. In this case, if the station intends to modify the existing TWT consensus, the station may use the TWT flow ID corresponding to the TWT consensus to be modified in the TWT consensus.

[0178] FIG. 16(a) shows the format of a TWT element according to an embodiment of the present invention. A TWT element may include an Element ID field, a Length field, a Control field, and a TWT Parameter Information field. In this case, the Element ID field indicates that the element containing the Element ID field is a TWT element. The value of the Element ID field may be 216.

[0179] FIG. 16(b) shows the specific format of the control field of a TWT element. The control field includes the NDP Paging Indicator field, Responder PM Mode field, Negotiation Type field, TWT Information Frame Disabled field, Wake Duration Unit field, Link ID Bitmap Present field, and Reserved field. FIG. 16(b) includes the Link ID Bitmap Present field in addition to the TWT element defined in IEEE 802.11ax. In this case, the Link ID Bitmap Present field indicates whether the TWT element contains the Link ID bitmap described earlier. Specifically, if the value of the Link ID Bitmap Present field is 1, the TWT element contains the Link ID bitmap, and if the value of the Link ID Bitmap Present field is 0, the TWT element may not contain the Link ID bitmap. A station receiving the TWT element can determine whether the TWT element contains the Link ID bitmap based on the value of the Link ID Bitmap Present field.

[0180] FIG. 16(c) shows the format of the Individual TWT Parameter Set field included in the TWT element. The Individual TWT Parameter Set field included in the TWT element may include a Request Type field, a Target Wake Time field, a TWT Group Assignment field, a Nominal Minimum TWT wake Duration field, a TWT Wake Interval Mantissa field, a TWT Channel field, an NDP Paging field, and a Link ID Bitmap field. FIG. 16(b) includes the Link ID Bitmap field in addition to the Individual TWT Parameter Set field defined in IEEE 802.11ax. If the TWT element includes the Link ID Bitmap field, the TWT element may indicate a request for a TWT Request for the link indicated by the Link ID Bitmap field. If the TWT request frame includes the TWT element and the TWT element includes the Link ID Bitmap field, the station receiving the TWT request frame may determine that the TWT request frame requests TWT consensus for the link indicated by the Link ID Bitmap field.

[0181] FIG. 16(d) shows the Request Type field of a TWT element according to an embodiment of the present invention. The Request Type field of the TWT element may include a TWT Request field, a TWT Setup Command field, a Trigger field, an Implicit field, a Flow Type field, a TWT Flow Identifier field, a TWT Wake Interval Expnent field, and a TWT Protection field. The TWT Flow Identifier field indicates a TWT Flow ID that identifies the TWT consensus performed by a TWT request frame containing the TWT element. At this time, the TWT Flow ID may be set according to the embodiments described above.

[0182] FIG. 17 shows a multi-link device according to an embodiment of the present invention performing TWT consensus.

[0183] An AP multi-link device includes a first AP (AP1), a second AP (AP2), and a third AP (AP3). A non-AP multi-link device includes a first station (STA1), a second station (STA2), and a third station (STA3). Each of the first AP (AP1), the second AP (AP2), and the third AP (AP3) operates on a first link (Link1), a second link (Link2), and a third link (Link3). Each of the first station (STA1), the second station (STA2), and the third station (STA3) operates on a first link (Link1), a second link (Link2), and a third link (Link3). A non-AP multi-link device may transmit a TWT request frame to perform TWT consensus on the first link (Link1) through the third link (Link3). In this case, the TWT request frame may include a single TWT element. Specifically, if a non-AP multi-link device intends to operate a TWT service period in which the same TWT parameters are used, the TWT request frame may include a single TWT element.

[0184] Specifically, the TWT element can indicate the start and end times of the TWT service period. Additionally, the TWT element may include the Link ID bitmap described through FIG. 16. Specifically, the TWT element can indicate the first link (Link1), the second link (Link2), and the third link (Link3) in the Link ID Bitmap subfield.

[0185] Since the Link ID Bitmap subfield of the TWT element of the received TWT request frame indicates the first link (Link1), the second link (Link2), and the third link (Link3), the AP multi-link device can determine that the TWT parameter signaling the TWT request frame corresponds to the TWT service period of the first link (Link1), the second link (Link2), and the third link (Link3).

[0186] The AP multi-link device may accept the TWT setup by transmitting a TWT response frame to the non-AP multi-link device. At this time, a TWT agreement is established at each of the first link (Link1) to the third link (Link3). At this time, the TWT agreement at each link may represent the TWT agreement between the first station (STA1) and the first AP (AP1), the TWT agreement between the second station (STA2) and the second AP (AP2), and the TWT agreement between the third station (STA3) and the third AP (AP3).

[0187] FIG. 18 shows that, according to an embodiment of the present invention, a station included in a multi-link device performs TWT consensus for another station included in the multi-link device that includes the station.

[0188] As previously explained, a TWT request frame for TWT consensus performed on the second link may be transmitted from the first link. To this end, a first station operating on the first link may transmit a TWT request frame from the first link. At this time, the TWT element of the TWT request frame includes a TWT Link ID bitmap, and the TWT Link ID bitmap may indicate the second link. A first AP operating on the first link may determine, based on the TWT Link ID bitmap, that the TWT request frame was transmitted for TWT consensus on the second link.

[0189] In the embodiment of FIG. 18, the AP multi-link device includes a first AP (AP1) and a second AP (AP2). The non-AP multi-link device includes a first station (STA1) and a second station (STA2). Each of the first AP (AP1) and the second AP (AP2) operates on a first link (Link1) and a second link (Link2). Each of the first station (STA1) and the second station (STA2) operates on a first link (Link1) and a second link (Link2). The first station (STA1) transmits a TWT request frame on the first link (Link1) for TWT consensus on the second link (Link2). The first AP (AP1) transmits a TWT response frame to the first station (STA1) to accept the TWT consensus on the second link (Link2). Accordingly, a TWT consensus is established between the second station (STA2) and the second AP (AP2).

[0190] In such cases, the station that sent the TWT request frame and the station to which the TWT consensus applies are different. Furthermore, as previously explained, while the station that sent the TWT request frame is a single station, the TWT consensus can apply to multiple stations. Therefore, the station capable of releasing the TWT consensus may become an issue.

[0191] In existing TWT operations, a 3-bit TWT Flow ID and the MAC addresses of the two stations that established the TWT consensus can be used to identify the TWT consensus. Specifically, the TWT consensus could be identified through the MAC address of the TWT requesting station, the MAC address of the TWT responding station, and the TWT Flow ID. As previously explained, it may be difficult to identify the TWT consensus established by a multi-link device because the station performing the TWT consensus and the station to which the TWT consensus applies may be different. For example, in the embodiments of FIG. 17 and FIG. 18, the TWT requesting station is the first station and the TWT responding station is the first AP. However, in the embodiment of FIG. 17, the TWT consensus applies to the first station and the first AP, the second station and the second AP, and the third station and the third AP. In the embodiment of FIG. 18, the TWT consensus applies to the second station and the second AP. In addition, in the embodiment of FIG. 17, a single TWT Flow ID may be applied identically to the first station and the first AP, the second station and the second AP, and the third station and the third AP. Therefore, TWT consensus cannot be identified. To solve this problem, the following embodiments may be applied.

[0192] A station capable of releasing TWT consensus may be a station to which TWT consensus applies. To this end, the TWT requesting station may not be the station that transmitted the TWT request frame, but rather a station operating on a link to which TWT consensus applies. Specifically, the TWT requesting station may be a station among the multi-link devices that transmitted the TWT request frame that operates on a link to which TWT consensus applies. Additionally, the TWT response station may not be the station that transmitted the TWT response frame, but rather a station operating on a link to which TWT consensus applies. Specifically, the TWT response station may be a station among the multi-link devices that transmitted the TWT response frame that operates on a link to which TWT consensus applies.

[0193] In addition, the following embodiments may be applied as a method for identifying TWT consensus.

[0194] In a specific embodiment, the TWT consensus can be identified based on the ID of the link. Specifically, the TWT consensus can be identified based on the TWT Flow ID, the MAC address of the TWT requesting station, the MAC address of the TWT responding station, and the ID of the link to which the TWT consensus applies. In the embodiment of FIG. 17, the first TWT consensus, which is the TWT consensus established between the first station and the first AP, can be identified by the TWT Flow ID, the MAC address of the first station, the MAC address of the first AP, and the ID of the first link. The second TWT consensus, which is the TWT consensus established between the second station and the second AP, can be identified by the TWT Flow ID, the MAC address of the first station, the MAC address of the first AP, and the ID of the second link. The third TWT consensus, which is the TWT consensus established between the third station and the third AP, can be identified by the TWT Flow ID, the MAC address of the first station, the MAC address of the first AP, and the ID of the third link. According to a specific embodiment, the TWT Flow ID can be set for each link.

[0195] Additionally, TWT consensus can be considered to be performed per multi-link device. Therefore, to identify TWT consensus, the MAC address of the TWT requesting multi-link device may be used instead of the MAC address of the TWT requesting station, and the MAC address of the TWT response multi-link device may be used instead of the MAC address of the TWT response station. In the embodiment of FIG. 17, the first TWT consensus, which is a TWT consensus established between the first station and the first AP, can be identified by the TWT Flow ID, the MAC address of the non-AP multi-link device, the MAC address of the AP multi-link device, and the ID of the first link. The second TWT consensus, which is a TWT consensus established between the second station and the second AP, can be identified by the TWT Flow ID, the MAC address of the non-AP multi-link device, the MAC address of the AP multi-link device, and the ID of the second link. The third TWT consensus, which is a TWT consensus established between the third station and the third AP, can be identified by the TWT Flow ID, the MAC address of the non-AP multi-link device, the MAC address of the AP multi-link device, and the ID of the third link. Depending on the specific embodiment, the TWT Flow ID may be set per link. According to specific embodiments, the TWT Flow ID can be set for each link.

[0196] Additionally, the TWT request station may be a station operating on a link where the TWT consensus applies, rather than the station that transmitted the TWT request frame. Specifically, the TWT request station may be a station among the multi-link devices that transmitted the TWT request frame that operates on a link where the TWT consensus applies. Additionally, the TWT response station may be a station among the multi-link devices that transmitted the TWT response frame that operates on a link where the TWT consensus applies, rather than the station that transmitted the TWT response frame. Specifically, the TWT response station may be a station among the multi-link devices that transmitted the TWT response frame that operates on a link where the TWT consensus applies. In the embodiment of FIG. 17, the first TWT consensus, which is a TWT consensus established between the first station and the first AP, can be identified by the TWT Flow ID, the MAC address of the first station, and the MAC address of the first AP. The second TWT consensus, which is a TWT consensus established between the second station and the second AP, can be identified by the TWT Flow ID, the MAC address of the second station, and the MAC address of the second AP. The third TWT agreement, which is a TWT agreement established between the third station and the third AP, can be identified by the TWT Flow ID, the MAC address of the third station, and the MAC address of the third AP. Depending on a specific embodiment, the TWT Flow ID may be set for each link.

[0197] Additionally, TWT consensus can be identified based on the link through which the TWT request frame is transmitted. Specifically, TWT consensus can be identified based on the TWT Flow ID, the MAC address of the TWT requesting station, the MAC address of the TWT responding station, and the ID of the link through which the TWT request frame is transmitted. In the embodiment of FIG. 17, the first TWT consensus, which is the TWT consensus established between the first station and the first AP, can be identified by the TWT Flow ID, the MAC address of the first station, the MAC address of the first AP, and the ID of the first link. The second TWT consensus, which is the TWT consensus established between the second station and the second AP, can be identified by the TWT Flow ID, the MAC address of the first station, the MAC address of the first AP, and the ID of the first link. The third TWT consensus, which is the TWT consensus established between the third station and the third AP, can be identified by the TWT Flow ID, the MAC address of the first station, the MAC address of the first AP, and the ID of the first link. Depending on the specific embodiment, the TWT Flow ID can be set for each link.

[0198] Previously, the method by which a multi-link device establishes TWT consensus was explained. The method by which a multi-link device tears down TWT consensus is explained through Fig. 19.

[0199] FIG. 19 shows the operation of a multi-link device according to an embodiment of the present invention releasing a TWT agreement.

[0200] In an embodiment of the present invention, a multi-link device can release TWT consensus applied to multiple links from a single link. In a conventional wireless LAN, a station transmits a TWT release frame to release TWT consensus. At this time, the TWT release frame may be transmitted by a TWT requesting station or a TWT responding station. The TWT release frame includes a TWT Flow Identifier field indicating a TWT Flow ID. At this time, the TWT Flow Identifier field may be a 3-bit field. When a station to which TWT consensus applies receives a TWT release frame, the station may release the TWT consensus corresponding to the TWT Flow ID indicated by the TWT release frame. If the TWT release frame is successfully transmitted, the station that transmitted the TWT release frame may release the TWT consensus corresponding to the TWT Flow ID indicated by the TWT release frame. Accordingly, the station to release the TWT consensus and the TWT consensus to be released can be identified based on the MAC address of the sender of the TWT release frame, the MAC address of the receiver of the TWT release frame, and the TWT Flow ID.

[0201] However, as previously explained, when TWT consensus is established among stations of a multi-link device, the station that transmitted the TWT request frame and the station to which the TWT consensus applies may be different. Furthermore, as previously explained, the station that transmitted the TWT request frame may be a single station, while the TWT consensus may apply to multiple stations. Therefore, a method for releasing TWT consensus that can be applied even in such cases is required.

[0202] A TWT release frame may include information regarding a link identifier. In this case, a station of a multi-link device may release at least one of a plurality of TWT agreements based on the link identifier indicated by the TWT release frame, such as a link ID. Specifically, when a station of a multi-link device operates on a first link and the station releases a TWT agreement performed on a second link, the station may transmit a TWT release frame containing information regarding a link identifier on the first link. In these embodiments, the link identifier may be the identifier of the link to which the TWT agreement to be released applies. For example, a TWT release frame may include a TWT Flow Identifier field indicating a TWT Flow ID and a Link ID field indicating the identifier of the link to which the TWT agreement to be released applies. Additionally, a TWT release frame may include a single Link ID field. Additionally, a TWT release frame may include multiple Link ID fields. To this end, the format of a TWT release frame transmitted by a station included in the multi-link device may differ from the format of a TWT release frame transmitted by a station not included in the multi-link device. In another specific embodiment, the format of the TWT release frame transmitted by a station included in the multi-link device may be the same as the format of the TWT release frame transmitted by a station not included in the multi-link device.

[0203] When the first multi-link device transmits a TWT release frame on the first link to the second multi-link device, and the second multi-link device successfully receives the TWT release frame, the TWT agreement corresponding to the TWT Flow ID indicated by the TWT release frame among the TWT agreements established between the first multi-link device and the second multi-link device may be released. At this time, the first multi-link device and the second multi-link device may release the TWT agreement corresponding to the link-related information indicated by the TWT release frame among the TWT agreements established between the first multi-link device and the second multi-link device. Specifically, the first multi-link device and the second multi-link device may release the TWT agreement corresponding to the TWT Flow ID indicated by the TWT release frame and the link-related information indicated by the TWT release frame among the TWT agreements established between the first multi-link device and the second multi-link device.

[0204] In another specific embodiment, if the first multi-link device transmits a TWT release frame on the first link to the second multi-link device and the second multi-link device successfully receives the TWT release frame, the first multi-link device and the second multi-link device may release the TWT agreement corresponding to the MAC address of the station that transmitted the TWT release frame and the MAC address of the station that received the TWT release frame among the TWT agreements established between the first multi-link device and the second multi-link device. In another specific embodiment, if the first multi-link device transmits a TWT release frame on the first link to the second multi-link device and the second multi-link device successfully receives the TWT release frame, the first multi-link device and the second multi-link device may release the TWT agreement corresponding to the MAC address of the station that performed the TWT agreement and the MAC address of the station that performed the TWT agreement among the TWT agreements established between the first multi-link device and the second multi-link device. In another specific embodiment, the station that received the TWT release frame and the station that transmitted the TWT release frame can release the TWT consensus corresponding to the TWT Flow ID indicated by the TWT release frame within the link where the station operates.

[0205] Additionally, when a TWT consensus is established on multiple links by a single TWT element, the TWT consensus established on multiple links can be released by a single TWT release frame. In this case, the TWT parameters of the TWT consensus established on multiple links may be the same. Additionally, the TWT Flow IDs of the TWT consensus established on multiple links may be the same. For example, if a TWT consensus is established on the first to third links simultaneously between the first multi-link device and the second multi-link device, for instance, by a single TWT element, the first multi-link device or the second multi-link device may release the TWT consensus established on the first to third links by transmitting a TWT release frame on any one of the first to third links.

[0206] An AP multi-link device includes a first AP (AP1), a second AP (AP2), and a third AP (AP3). A non-AP multi-link device includes a first station (non-AP STA1), a second station (non-AP STA2), and a third station (non-AP STA3). Each of the first AP (AP1), the second AP (AP2), and the third AP (AP3) operates on a first link (Link1), a second link (Link2), and a third link (Link3). Each of the first station (non-AP STA1), the second station (non-AP STA2), and the third station (non-AP STA3) operates on a first link (Link1), a second link (Link2), and a third link (Link3). The first station (non-AP STA1) is combined with the first AP (AP1), the second station (non-AP STA2) is combined with the second AP (AP2), and the third station (non-AP STA3) is combined with the third AP (AP3). A TWT consensus is established between the first station (non-AP STA1) and the first AP (AP1), and the TWT Flow ID of the corresponding TWT consensus is x. A TWT consensus is established between the second station (non-AP STA2) and the second AP (AP2), and the TWT Flow ID of the corresponding TWT consensus is y. A TWT consensus is established between the third station (non-AP STA3) and the third AP (AP3), and the TWT Flow ID of the corresponding TWT consensus is z.

[0207] At this time, the non-AP multi-link device transmits a TWT release frame to release the TWT agreement between the first station (non-AP STA1) and the first AP (AP1) and the TWT agreement between the third station (non-AP STA3) and the third AP (AP3). At this time, the device indicates x, which corresponds to the TWT Flow ID of the TWT agreement between the first station (non-AP STA1) and the first AP (AP1), and z, which corresponds to the TWT Flow ID of the TWT agreement between the third station (non-AP STA3) and the third AP (AP3).

[0208] The AP multi-link device transmits an ACK for the TWT release frame to the non-AP multi-link device. Subsequently, the AP multi-link device releases the TWT agreement between the first station (non-AP STA1) and the first AP (AP1), and the TWT agreement between the third station (non-AP STA3) and the third AP (AP3). The non-AP multi-link device receives the ACK for the TWT release frame. Subsequently, the non-AP multi-link device releases the TWT agreement between the first station (non-AP STA1) and the first AP (AP1), and the TWT agreement between the third station (non-AP STA3) and the third AP (AP3).

[0209] A TWT element for establishing and releasing a TWT consensus according to the embodiments described above is explained through FIG. 20.

[0210] FIG. 20 shows the format of the Individual TWT parameter set field of a TWT element according to an embodiment of the present invention.

[0211] The Request Type field of the Individual TWT parameter set field of the TWT element includes 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.

[0212] If the value of the TWT Request subfield is 1, the station transmitting the TWT element may be a TWT requesting station or a TWT scheduled station. Additionally, if the value of the TWT Request subfield is 0, the station transmitting the TWT element may be a TWT responding station or a TWT scheduling AP.

[0213] The TWT Setup Command subfield can indicate the type of TWT command. The value of the TWT Setup Command subfield can be set from 0 to 7. When the value of the TWT Setup Command subfield is from 0 to 7, the TWT Setup Command subfield may indicate that the TWT element containing the TWT Setup Command subfield is a Request TWT, Suggest TWT, Demand TWT, TWT Grouping, Accept TWT, Alternate TWT, Dictate TWT, and Reject TWT. This may be the same as the setting of the TWT Setup Command subfield used in the past.

[0214] When the value of the Trigger subfield is 1, the Trigger subfield may indicate that one or more trigger frames are transmitted during the TWT service period when TWT consensus is established by the TWT element.

[0215] The Implicit subfield indicates whether the TWT element requests an implicit TWT. If the value of the Implicit subfield is 1, the Implicit subfield may indicate that the TWT element requests an implicit TWT. If the value of the Implicit subfield is 0, the Implicit subfield may indicate that the TWT element requests an explicit TWT.

[0216] The Flow Type subfield indicates the interaction method between the TWT requesting station and the TWT responding station within the TWT service period. The value of the Flow Type subfield can be set to the same value as the Flow Type subfield defined in conventional wireless LAN standards.

[0217] The TWT Flow Identifier subfield indicates an ID value for distinguishing TWT consensus. In conventional wireless LAN standards, a TWT element includes only a single TWT Flow Identifier subfield. However, as previously explained, when TWT consensus is established across multiple links through a single TWT element, the TWT element may include multiple TWT Flow Identifier subfields. In this case, each of the multiple TWT Flow Identifier subfields may indicate the TWT Flow ID of the TWT consensus established on each of the multiple links.

[0218] The TWT wake interval subfield indicates the average interval between TWT service periods set by the TWT element. In this case, the average interval is an estimated value. The value of the TWT wake interval subfield can be set as a value defined in conventional wireless LAN standards.

[0219] When the value of the TWT protection subfield is 1, the TWT protection subfield indicates that the TWT requesting station is requesting the TWT responding station to support protection for the TWT service period. In this case, the protection method for the TWT service period may be the same as that defined in conventional wireless LAN standards.

[0220] The Target Wake Time field, TWT Group Assignment field, Nominal Minimum TWT Wake Duration field, TWT Wake Interval Mantissa field, TWT Channel field, and NDP Paging field of the Individual TWT Parameter Set field can be configured as defined in conventional wireless LAN standards.

[0221] The Individual TWT Parameter Set field may include a Link ID Bitmap subfield as described in the embodiment illustrated in FIG. 16. When the Link ID Bitmap subfield indicates multiple links, the TWT element may request TWT consensus from multiple links. In this case, when TWT consensus is established from multiple links, a TWT service period having the same TWT parameters may be applied to multiple links.

[0222] In addition, even if TWT consensus is established on multiple links through a single TWT element, the multiple TWT consensuses established on multiple links may have different TWT Flow IDs. This is because even if TWT consensus is established at once, it is applied to different links and to different stations and APs. A TWT element may include multiple TWT Flow Identifier fields. Specifically, a TWT element may include multiple TWT Flow Identifier fields corresponding to each of the multiple links to which the TWT consensus is applied. In this case, the number of TWT Flow Identifier fields included in the TWT element may be equal to the number of links indicated by the Link ID Bitmap subfield. For example, if the Link ID Bitmap subfield indicates two links, the TWT element containing the Link ID Bitmap subfield may include two TWT Flow Identifier fields. Among the multiple TWT Flow Identifier fields included in the TWT element, the first TWT Flow Identifier subfield may be the TWT Flow ID included in the Request Type field. The remaining subfields, excluding the first TWT Flow Identifier subfield, may be included in separate fields of the TWT element, such as the Additional TWT Flow ID field in FIG. 20. Additionally, the first TWT Flow Identifier subfield may indicate the TWT Flow ID of the TWT consensus established on the link through which the TWT request frame is transmitted. The remaining TWT Flow Identifier subfields, excluding the first TWT Flow Identifier subfield, may indicate the TWT Flow ID of the TWT consensus established on the links through which the TWT consensus is established, excluding the link through which the TWT request frame is transmitted.As previously explained, among the links where TWT consensus is established, the remaining links, excluding the link through which the TWT request frame is transmitted, can be indicated by the Link ID Bitmap subfield. Additionally, the remaining TWT Flow Identifier subfields, excluding the first TWT Flow Identifier subfield, can be mapped to links according to the order of the Link ID values. Among the remaining TWT Flow Identifier subfields, excluding the first one, the first subfield can be mapped to the link with the smallest Link ID value among the remaining links excluding the link through which the TWT request frame is transmitted, the second subfield can be mapped to the link with the second smallest Link ID value among the remaining links excluding the link through which the TWT request frame is transmitted, and the third subfield can be mapped to the link with the third smallest Link ID value among the remaining links excluding the link through which the TWT request frame is transmitted.

[0223] If a TWT element requests only one TWT consensus, the TWT element may not include the remaining TWT Flow Identifier subfields, except for the first TWT Flow Identifier subfield. If a TWT element requests only one TWT consensus on a link other than the link where the TWT request frame is transmitted, the TWT element may not include the remaining TWT Flow Identifier subfields, except for the first TWT Flow Identifier subfield. In this case, the first TWT Flow Identifier subfield may indicate the TWT Flow ID corresponding to the TWT consensus requested by the TWT request frame.

[0224] FIG. 21 shows the format of the remaining TWT Flow Identifier subfields, excluding the first TWT Flow Identifier subfield, according to an embodiment of the present invention.

[0225] As previously explained, the size of the Additional TWT Flow ID field can be determined according to the number of links indicated by the Link ID bitmap of the TWT element. In conventional wireless LANs, the maximum number of TWT consensuses that a station can establish is 8. Therefore, in conventional wireless LANs, the TWT Flow Identifier subfield is a 3-bit field. When the maximum number of TWT consensuses that a multi-link device can establish is 8, the TWT Flow Identifier subfield may be a 3-bit field. Additionally, the Additional TWT Flow ID field may include one or more subfields having a size of 3 bits. When a TWT element requests n TWT consensuses, the Additional TWT Flow ID field may include n-1 3-bit subfields. In this case, as previously explained, the first TWT Flow Identifier subfield may be the TWT Flow ID included in the Request Type field. In another specific embodiment, when a TWT element requests n TWT consensuses, the Additional TWT Flow ID field may include n 3-bit subfields. Additionally, a reserved field may be included in the Additional TWT Flow ID field to ensure that the TWT Parameter Set field has a length in octets. FIG. 21(a) illustrates such an embodiment.

[0226] In the Per-octet format of FIG. 21(a), the Additional TWT Flow ID field contains two TWT Flow ID subfields in one octet. Specifically, when a TWT element requests three TWT agreements, the Additional TWT Flow ID field may contain two TWT Flow ID subfields in one octet.

[0227] Additionally, if the Additional TWT Flow ID field indicates an odd number of TWT Flow IDs, the last octet contained in the Additional TWT Flow ID field may indicate one TWT Flow ID, and the remaining 5 bits may be set as a reserved field. FIG. 22(b) illustrates such an embodiment.

[0228] In the embodiments described above, the size of the TWT Flow ID subfield was described as being 3 bits, but the embodiments described above can also be applied even when the size of the TWT Flow ID subfield is 4 bits.

[0229] As explained earlier, a single TWT element can request TWT consensus on multiple links. Therefore, it is necessary to transmit additional information required for this. This is explained through Fig. 22.

[0230] FIG. 22 shows the format of a Control field included in a TWT element transmitted by a multi-link device according to an embodiment of the present invention.

[0231] When a single TWT element requests TWT consensus across multiple links, the additional information required may include a Link ID bitmap, which is information indicating the link where the TWT consensus is performed, and an Additional TWT Flow Identifier field, which is a TWT Flow ID corresponding to the TWT consensus. However, when a station of a multi-link device transmits a TWT request frame to a station to which it is connected, the TWT element included in the TWT request frame may not include this additional information. The TWT element may include a field indicating whether it contains the Link ID Bitmap field and the Additional TWT Flow Identifier field. A station receiving the TWT element may determine the format of the TWT element based on the field indicating whether it contains the Link ID Bitmap field and the Additional TWT Flow Identifier field.

[0232] If the TWT element transmitted by the TWT request station includes a Link ID Bitmap subfield, the TWT request station may set the value of the Link ID Bitmap Present subfield of the Control field of the TWT element to 1. If the value of the Link ID Bitmap Present subfield of the Control field of the TWT element is 1, the TWT response station that receives the TWT element may determine that the TWT element includes a Link ID Bitmap subfield and is intended to establish TWT consensus on multiple links or on a link different from the link to which the TWT request frame containing the TWT element was transmitted.

[0233] If the TWT element transmitted by the TWT requesting station includes an Additional TWT Flow ID subfield, the TWT requesting station may set the value of the Additional TWT Flow ID Present subfield in the Control field of the TWT element to 1. If the value of the Additional TWT Flow ID Present subfield in the Control field of the TWT element is 1, the TWT responding station that receives the TWT element may determine that the TWT element includes an Additional TWT Flow ID subfield and is intended to establish TWT consensus across multiple links.

[0234] In another specific embodiment, the Additional TWT Flow ID Present subfield may be omitted. In this case, the TWT response station that receives the TWT element can determine whether the TWT element includes the Additional TWT Flow ID subfield based on the Link ID Bitmap subfield. Additionally, the TWT response station that receives the TWT element can determine the size of the Additional TWT Flow ID subfield included in the TWT element based on the Link ID Bitmap subfield.

[0235] As previously explained, the multi-link device can transmit a TWT release frame to release the TWT consensus applied to the second link from the first link. Additionally, the multi-link device can release the TWT consensus applied to multiple links by transmitting a TWT release frame to a single link.

[0236] The TWT release frame can also include additional information compared to the TWT release frame of a conventional wireless LAN. This is explained through FIG. 23.

[0237] FIG. 23 shows the format of the Action field of a TWT release frame transmitted by a multi-link device according to an embodiment of the present invention.

[0238] A TWT release frame transmitted by a multi-link device can be defined as a new action frame. For convenience of explanation, the TWT release frame transmitted by a multi-link device is referred to as an MLD TWT release frame. An MLD TWT release frame can be designated as Unprotected S1G among the categories of the Action field. Among the values ​​of the Action field of Unprotected S1G, a value not used in conventional wireless LANs can be assigned to the MLD TWT release frame. For example, as in the embodiment of FIG. 23(a), 12 can be assigned to the MLD TWT release frame. At this time, when a station intends to transmit an MLD TWT release frame, the station can set the value of the category in the action frame to 22 and the value of the Unprotected S1G Action field to 12.

[0239] Additionally, the Action field of the MLD TWT release frame may include a field indicating the TWT consensus that the TWT release frame intends to release. This field may be referred to as the MLD TWT Flow field. The MLD TWT Flow field may indicate the Link ID of the link corresponding to the TWT consensus that the TWT release frame intends to release, and the TWT Flow ID corresponding to the TWT consensus that the TWT release frame intends to release. FIG. 23(b) shows an example of the Action field included in the TWT release frame.

[0240] The MLD TWT Flow field can be indicated not only by the Unprotected S1G category but also by the Action field of other categories. For example, an MLD TWT release frame can be transmitted in the format of a Protected Action frame of the S1G category. In this case, the Action field of the action frame of the S1G category may include the MLD TWT Flow field.

[0241] The TWT release frame may be used in a format different from the action frame described in this embodiment, and a frame other than the action frame may be used as the TWT release frame. The specific format of the MLD TWT Flow field will be explained through FIG. 24.

[0242] FIG. 24 shows an MLD TWT Flow field according to an embodiment of the present invention.

[0243] The MLD TWT Flow field may include a field having a variable length. Specifically, the MLD TWT Flow field may include a variable-length field indicating a TWT Flow ID corresponding to the TWT consensus to be released by the MLD TWT release frame. In a specific embodiment, the MLD TWT Flow field may include an MLD TWT Flow Control field having a fixed length and an MLD TWT Flow IDs field having a variable length. The MLD TWT Flow Control field may be a one-octet field. Additionally, the MLD TWT Flow Control field may indicate information for parsing the MLD TWT Flow IDs field. Specifically, the MLD TWT Control field may indicate information regarding the size of the MLD TWT Flow IDs field. The MLD TWT Flow IDs field may indicate a TWT Flow ID corresponding to the TWT consensus to be released. Additionally, the MLD TWT Flow IDs field may be omitted depending on the setting of the MLD TWT Flow Control field. FIG. 24(a) shows an MLD TWT Flow field according to such an embodiment.

[0244] The MLD TWT Flow Control field may include a field indicating the length of the MLD TWT Flow IDs field. In this case, this field may be referred to as the Length of MLD Flow IDs field. The Length of MLD Flow IDs field may indicate the length of the MLD TWT Flow IDs field in units of one octet. In this case, if the length of the MLD TWT Flow IDs field is five octets, the value of the Length of MLD Flow IDs field may be set to 5 or 4. FIG. 24(b) shows an MLD TWT Flow field according to this embodiment.

[0245] Additionally, the TWT Flow Control field may include a subfield indicating that all TWT consensus established between the multi-link device transmitting the MLD TWT release frame and the multi-link device receiving the MLD TWT release frame is to be released. This subfield is referred to as the Teardown All TWT of All Link field. If the multi-link device intends to release all TWT consensus established between itself and the receiver of the MLD TWT release frame, the multi-link device may set the value of the Teardown All TWT of All Link subfield of the MLD TWT release frame to 1. If an MLD TWT release frame with the Teardown All TWT of All Link subfield set to 1 is successfully received, all TWT consensus established between the multi-link device transmitting the MLD TWT release frame and the multi-link device receiving the MLD TWT release frame is released. When the Teardown All TWT of All Link subfield is 1, the Length of MLD Flow IDs field may be set as a reserved field. Therefore, when the Teardown All TWT of All Link subfield is 1, the MLD TWT Flow field may not include MLD TWT Flow IDs. FIG. 24(b) shows the TWT Flow Control field according to this embodiment.

[0246] The MLD TWT Flow IDs field may repeatedly include a 3-bit TWT Identifier subfield, a 4-bit Link ID field, and a 1-bit Teardown All TWT subfield for every octet. In this case, consecutive TWT Identifier subfields and Link ID fields can identify the TWT consensus that the MLD TWT release frame releases. FIG. 24(c) shows the MLD TWT Flow IDs field according to this embodiment.

[0247] Additionally, the Teardown All TWT subfield may indicate that all TWT consensus associated with the link corresponding to the Teardown All TWT subfield is released. In this case, the link corresponding to the Teardown All TWT subfield is the link corresponding to the Link Id field contained in the same octet as the Teardown All TWT subfield. Furthermore, if the value of the Teardown All TWT subfield is 1, the TWT Identifier subfield may be set as a reserved field. FIG. 24(e) shows the MLD TWT Flow IDs field according to this embodiment.

[0248] In another specific embodiment, the Teardown All TWT subfield may indicate that all TWT consensus corresponding to the TWT Flow ID corresponding to the Teardown All TWT subfield is released. In this case, the link corresponding to the Teardown All TWT subfield is the TWT Flow ID corresponding to the TWT Flow Identifier subfield included in the same octet as the Teardown All TWT subfield. Additionally, if the value of the Teardown All TWT subfield is 1, the Link ID subfield may be set as a reserved field. FIG. 24(f) shows the MLD TWT Flow IDs field according to this embodiment.

[0249] In another specific embodiment, the MLD TWT Flow IDs field may include a plurality of TWT Identifier subfields consecutively, a plurality of Link ID fields consecutively, and a Teardown All TWT subfield consecutively. In this embodiment, TWT Identifier subfields and Link ID fields in the same order can identify the TWT consensus released by the MLD TWT release frame. For example, a combination of the first TWT Identifier subfield and the first Link ID field can identify the TWT consensus released by the MLD TWT release frame, and a combination of the second TWT Identifier subfield and the second Link ID field can identify the TWT consensus released by the MLD TWT release frame. At least one of the number of TWT Flow Identifier subfields, the number of Link ID subfields, and the number of Teardown All TWT subfields included in the MLD TWT Flow IDs field may be proportional to the size of the MLD TWT Flow IDs field. Additionally, the Teardown All TWT subfields and Link ID fields may correspond sequentially. For example, the first Teardown All TWT subfield may correspond to the first Link ID field, and the second Teardown All TWT subfield may correspond to the second Link ID field. Additionally, the Teardown All TWT subfield and the TWT Flow Identifier subfield may correspond sequentially. For example, the first Teardown All TWT subfield may correspond to the first TWT Flow Identifier subfield, and the second Teardown All TWT subfield may correspond to the second TWT Flow Identifier subfield.

[0250] In another specific embodiment, the MLD TWT release frame may include a Link ID bitmap for indicating multiple links. This may be the same as the format of the Link ID Bitmap field included in the TWT element described above. Additionally, the MLD TWT release frame may include a bitmap to signal information for releasing multiple TWT consensus. This is explained through FIG. 25.

[0251] FIG. 25 shows the format of an MLD TWT Flow field according to another embodiment of the present invention.

[0252] As previously explained, the MLD TWT release frame may have a variable length. In this case, the MLD TWT release frame may include a fixed-length MLD TWT Flow Control field and an MLD TWT Bitmap field. That is, the MLD TWT release frame may include an MLD TWT Bitmap field instead of the MLD TWT Flow IDs field mentioned in the embodiments described through FIG. 24. In this case, the length of the MLD TWT Flow Control field may be one octet. Additionally, in the MLD TWT release frame, the MLD TWT Bitmap field may be omitted depending on the value of the MLD TWT Flow Control field. FIG. 25(a) shows the format of the MLD TWT Flow field according to this embodiment.

[0253] The MLD TWT Control field may include a subfield indicating information related to the size of the MLD TWT Bitmap field. This subfield is referred to as the Length of Bitmap subfield. The Length of Bitmap field may indicate the size of the MLD TWT Bitmap field in units of 3 octets. For example, if the size of the MLD TWT Bitmap field is 9 octets, the value of the Length of Bitmap field may be set to 3 or 2. The Length of Bitmap subfield may be a 3-bit field. In this case, the number of length types that the MLD TWT Bitmap field can have may be limited to 8 or fewer. This is because the number of TWT Flow IDs is 8 or fewer. FIG. 25(b) shows the format of the MLD TWT Control field according to this embodiment.

[0254] The MLD TWT Flow Control field may include a subfield indicating that all TWT consensus established between the multi-link device transmitting the MLD TWT release frame and the multi-link device receiving the MLD TWT release frame is to be released, as described in FIG. 24. This subfield is referred to as the Teardown All TWT of All Link field. If the multi-link device intends to release all TWT consensus established between itself and the receiver of the MLD TWT release frame, the multi-link device may set the value of the Teardown All TWT of All Link subfield of the MLD TWT release frame to 1. If an MLD TWT release frame with the Teardown All TWT of All Link subfield set to 1 is successfully received, all TWT consensus established between the multi-link device transmitting the MLD TWT release frame and the multi-link device receiving the MLD TWT release frame is released. When the Teardown All TWT of All Link subfield is 1, the Length of TWT Bitmap field may be set as a reserved field. Therefore, when the Teardown All TWT of All Link subfield is 1, the MLD TWT Flow field may not include the TWT Bitmap field. FIG. 25(c) shows the TWT Flow Control field according to this embodiment.

[0255] The TWT Bitmap field may repeatedly include a TWT Flow ID Bitmap subfield of one octet in length and a Link ID Bitmap subfield of two octets in length every three octets. FIG. 25(d) shows a TWT Bitmap field according to this embodiment. The TWT Flow ID Bitmap subfield may indicate a TWT Flow ID corresponding to the TWT consensus that the TWT release frame intends to release. When the MLD TWT release frame releases a TWT consensus with a TWT Flow ID of 1 to 3, the TWT Flow ID Bitmap subfield is 1110 0000 2b It can be set to. In this case, each of the TWT Flow ID values ​​1 through 8 is mapped to the first through eighth bits of the TWT Flow ID Bitmap subfield. Additionally, the Link ID Bitmap subfield may indicate the Link ID of the link corresponding to the TWT consensus that the TWT release frame intends to release. If the MLD TWT release frame releases a TWT consensus set on a link corresponding to Link IDs 1 through 3, the Link ID Bitmap subfield is 1110 0000 2b It can be set as such. In this case, each of the Link ID values ​​1 through 8 is mapped to the first through eighth bits of the Link ID Bitmap subfield. Additionally, as previously described, the TWT Flow ID can be indicated by 3 bits. Therefore, the TWT Flow ID bitmap can indicate the value of a single TWT Flow ID as a 3-bit field. In this case, 5 bits of the TWT Flow ID bitmap subfield may be a reserved field. FIG. 25(e) shows a TWT Bitmap field according to this embodiment.

[0256] In another specific embodiment, the TWT Bitmap field may consecutively include a TWT Flow ID Bitmap subfield and a Link ID Bitmap subfield. At least one of the lengths of the TWT Flow ID Bitmap subfield and the Link ID Bitmap subfield included in the TWT Bitmap field may be proportional to the size of the TWT Bitmap field.

[0257] The TWT consensus that the TWT release frame intends to release is the TWT consensus corresponding to the TWT Flow ID indicated by the TWT Flow ID Bitmap subfield and the Link ID indicated by the Link ID Bitmap subfield.

[0258] The MLD TWT release frame described above is newly defined as a frame for releasing TWT consensus established between multi-link devices, unlike the TWT release frames used in conventional wireless LANs. This section explains the method for releasing TWT consensus established between multi-link devices using conventional TWT release frames. Specifically, it describes 1) a method for releasing all TWT consensus established on the link where the TWT release frame is transmitted, 2) a method for releasing all TWT consensus established on a specific link, 3) a method for releasing TWT consensus corresponding to a specific TWT Flow ID on all links, and 4) a method for releasing all TWT consensus set on all links.

[0259] FIG. 26 shows a TWT release frame that releases a TWT consensus established in a multi-link device according to an embodiment of the present invention.

[0260] A conventional TWT release frame includes a TWT Flow field of one octet length. In this case, the first three bits (B0-B2) of the TWT Flow field are a TWT Flow Identifier subfield indicating the TWT Flow ID. The fourth and fifth bits (B3-B4) of the TWT Flow field are a Reserved subfield. The sixth and seventh bits (B5-B6) of the TWT Flow field are a Negotiation Type subfield indicating the negotiation type. In this case, the sixth and eighth bits (B7) of the TWT Flow field can be set as a Teardown All TWT subfield. The Teardown All TWT subfield may indicate that all TWT agreements established between the station transmitting the TWT release frame and the station receiving the TWT release frame are to be released. The format of the TWT Flow field described above may be when the value of the Negotiation Type subfield is 0 or 1. If the value of the Teardown All TWT subfield is 1, the TWT Flow Identifier subfield is set as a reserved field, and the value of the TWT Flow Identifier subfield can be set to 0.

[0261] First, a method for releasing all TWT consensus established on the link where the TWT release frame is transmitted is described. To signal that all TWT consensus established on the link where the TWT release frame is transmitted is released, the value of the Teardown all TWT subfield (B7) of the TWT release frame may be set to 1, and the value of the Teardown Type subfield (B4) may be set to 0. At this time, the first to fourth bits (B0-B3) of the TWT Flow field may be set as a reserved field. FIG. 26(a) shows the format of the TWT Flow field according to this embodiment. When the value of the Teardown all TWT subfield of the TWT Flow field is 1 and the value of the Teardown Type subfield is 0, the multi-link device that transmitted the TWT release frame containing the TWT Flow field and the multi-link device that received it can release all TWT consensus established on the link where the TWT release frame is transmitted among all TWTs established between the two multi-link devices.

[0262] A method for releasing all TWT consensus established on a specific link is described. To signal that all TWT consensus established on a specific link is released, the value of the Teardown all TWT subfield (B7) of the TWT release frame may be set to 0, and the value of the Teardown Type subfield (B4) may be set to 1. At this time, the first to fourth bits (B0-B3) of the TWT Flow field may be set as a Link ID field indicating the link corresponding to the TWT consensus being released by the TWT release frame. FIG. 26(b) shows the format of the TWT Flow field according to this embodiment. When the value of the Teardown all TWT subfield of the TWT Flow field is 0 and the value of the Teardown Type subfield is 1, the multi-link device that transmitted the TWT release frame containing the TWT Flow field and the multi-link device that received it can release all TWT consensus established on the link indicated by the Link ID field.

[0263] A method for releasing a TWT consensus corresponding to a specific TWT Flow ID across all links is described. To signal that a TWT consensus corresponding to a specific TWT Flow ID across all links is released, the value of the Teardown all TWT subfield (B7) of the TWT release frame may be set to 0, the value of the Teardown Type subfield (B4) may be set to 0, and the value of the All Link subfield (B3) may be set to 1. FIG. 26(c) shows the format of the TWT Flow field according to this embodiment. When the value of the Teardown all TWT subfield of the TWT release frame is 0, the value of the Teardown Type subfield is 0, and the value of the All Link subfield is 1, the multi-link device that transmitted the TWT release frame containing the TWT Flow field and the multi-link device that received it may release all TWT consensus corresponding to the TWT Flow ID indicated by the TWT Flow Identifier field among the TWT consensus established with the two multi-link devices.

[0264] A method for releasing all TWT consensus established on all links is described. To signal that all TWT consensus established on all links is released, the value of the Teardown all TWT subfield (B7) of the TWT release frame may be set to 1, and the value of the Teardown Type subfield (B4) may be set to 1. At this time, the TWT Flow field (B0-B3) may be set as a reserved field. FIG. 26(d) shows the format of the TWT Flow field according to this embodiment. When the value of the Teardown all TWT subfield of the TWT release frame is 1 and the value of the Teardown Type subfield is 1, the multi-link device that transmitted the TWT release frame containing the TWT Flow field and the multi-link device that received it may release the TWT consensus established with the two multi-link devices.

[0265] In the embodiments described above, the TWT consensus was released by the TWT release frame. However, the TWT consensus may be released even if the TWT release frame is not transmitted or received. This is referred to as implicit release. This is explained through FIG. 27.

[0266] FIG. 27 shows that a TWT agreement established between multi-link devices according to an embodiment of the present invention is implicitly released.

[0267] If the association between an AP and a non-AP station is disassociated, the TWT consensus established between the AP and the non-AP station may be implicitly dissolved. Additionally, if the link on which the AP and the non-AP station were associated is disabled, the TWT consensus established between the AP and the non-AP station may be implicitly dissolved. In this case, the disabling of the link may include the removal of the TID mapped to the link. For the sake of convenience, the following explanation uses the case where the association between the AP and the non-AP station is disassociated as an example; however, this also applies when the link on which the AP and the non-AP station were associated is disabled.

[0268] As previously explained, TWT consensus can be established across multiple links through a single TWT element. In this case, the TWT Flow IDs of the TWT consensuses established across multiple links may be identical. Furthermore, the requesting stations and responding stations for the TWT consensus established across multiple links may be the same. Consequently, it is difficult to distinguish between TWT consensuses established across multiple links, and they may need to be released simultaneously when releasing the consensus. Additionally, in conventional wireless LAN standards, when an AP and a non-AP station are uncoupled, the AP and the non-AP station implicitly release the TWT consensus established between them. At this time, the AP and the non-AP station delete the information regarding the TWT consensus established between them.

[0269] When TWT consensus is established on multiple links through a single TWT element, and the TWT Flow IDs of the TWT consensuses established on multiple links are identical, and the TWT request station and TWT response station are uncoupled, all multiple TWT consensuses can be implicitly released.

[0270] In another specific embodiment, when a first station included in a multi-link device is uncoupled from a second station coupled to the first station, a TWT consensus in which the first station is a TWT response station or the first station is a TWT request station may be implicitly released. At this time, the first station operates on the first link. The released TWT consensus may be inherited by a station operating on a link other than the first link among the links in which the multi-link device including the first station operates. At this time, signaling including a Link ID may be performed for the inheritance of the TWT consensus. Additionally, signaling for the inheritance of the TWT consensus may be transmitted via a management frame. Furthermore, such inheritance of the TWT consensus may be applied even if one of the stations is not coupled to the station coupled to the station. When the inheritance of the TWT consensus is performed, the TWT consensus established prior to the inheritance may be released. In the embodiments described above, the inheritance of the TWT consensus may indicate that the TWT parameters applied to the previously established TWT consensus are applied to the new TWT consensus.

[0271] In the embodiment of FIG. 27, the non-AP multi-link device (non-AP MLD) includes a first station (STA1), a second station (STA2), and a third station (STA3). Each of the first station (STA1), the second station (STA2), and the third station (STA3) operates on a first link (Link 1), a second link (Link 2), and a third link (Link 3). The AP multi-link device (AP MLD) includes a first AP (AP1), a second AP (AP2), and a third AP (AP3). Each of the first AP (AP1), the second AP (AP2), and the third AP (AP3) operates on a first link (Link 1), a second link (Link 2), and a third link (Link 3). The first station (STA1) and the first AP (AP1) combine and establish a TWT consensus (TWT 1, TWT 2, TWT 3) on the first link (Link1), the second link (Link 2), and the third link (Link3). The requesting station and the responding station of the TWT consensus (TWT 1, TWT 2, TWT 3) on the first link (Link1), the second link (Link 2), and the third link (Link3) are the first station (STA1) and the first AP (AP1). The first station (STA1) and the first AP (AP1) may be uncombined by the non-AP multi-link device (non-AP MLD) and the AP multi-link device (AP MLD) performing a reassociation procedure. The TWT consensus in which the first station (STA1) and the first AP (AP1) are the TWT responding station or the TWT requesting station may all be implicitly uncombined. Therefore, the TWT consensus (TWT 1, TWT 2, TWT 3) is released in the first link (Link 1), the second link (Link 2), and the third link (Link 3).

[0272] By recombination, the first station (STA1) can be combined with the fourth AP (AP4), which is a different AP from the first AP (AP1) of the AP Multi-Link Device (AP MLD), and operate on a different link. At this time, the TWT consensus between the first station (STA1) and the first AP (AP1) can be inherited by the first station (STA1) and the fourth AP (AP4). In this way, regardless of the link where the initial TWT setup was performed, a TWT consensus can be established on a new link through the inheritance of the TWT consensus.

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

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

[0275] 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

Claim 1 A multi-link device comprising a first station and a second station operating on a first link and a second link, respectively, wherein the first station is coupled to a first AP on the first link and the second station is coupled to a second AP on the second link, the multi-link device comprising: a transceiver; and a processor, wherein the processor transmits a TWT (target wake time) element through the first station on the first link to request a TWT agreement for the second station and the second AP, and, when the second link is deactivated, releases the TWT agreement for the second station and the second AP without receiving or transmitting a TWT release frame that releases the TWT agreement for the second station and the second AP. Claim 2 In claim 1, the TWT element is a multi-link device comprising a bitmap that indicates information indicating a link to which the TWT consensus to be established by the TWT element will be applied. Claim 3 In paragraph 1, the TWT request station of the TWT agreement for the second station and the second AP is the second station, and the TWT response station of the TWT agreement for the second station and the second AP is the second AP, a multi-link device. Claim 4 In paragraph 3, the multi-link device releases the TWT agreement for the second station and the second AP when the processor receives a TWT release frame from the second AP or successfully transmits the TWT release frame to the second AP. Claim 5 delete Claim 6 delete Claim 7 delete Claim 8 In claim 1, when the multi-link device successfully receives the TWT release frame from the first AP or successfully transmits the TWT release frame to the first AP, the TWT agreement between the second station and the second AP is released, and the TWT agreement between the second station and the second AP is identified in the TWT release frame based on the ID of the second link, the MAC (medium access control) address of the TWT requesting station, the MAC address of the TWT response station, and the Flow ID of the TWT agreement between the second station and the second AP, and the TWT requesting station of the TWT agreement for the second station and the second AP is the second station, and the TWT response station of the TWT agreement for the second station and the second AP is the second AP, a multi-link device. Claim 9 delete Claim 10 A multi-link device according to claim 1, wherein the processor releases the TWT agreement for the second station and the second AP, and succeeds the TWT agreement for the second station and the second AP to the first station and the first AP. Claim 11 A multi-link device according to claim 10, wherein when the processor inherits the TWT consensus for the second station and the second AP to the first station and the first AP, the processor applies the TWT parameters of the TWT consensus for the second station and the second AP to the TWT consensus for the first station and the first AP. Claim 12 A method of operation of a multi-link device comprising a first station and a second station operating on a first link and a second link, respectively, wherein the first station is coupled to a first AP on the first link and the second station is coupled to a second AP on the second link, the method comprising: a step of requesting a TWT (target wake time) element through the first station on the first link to request a TWT consensus for the second station and the second AP; and a step of releasing the TWT consensus for the second station and the second AP without receiving or transmitting a TWT release frame to release the TWT consensus for the second station and the second AP when the second link is deactivated. Claim 13 In paragraph 12, the above TWT element is a method of operation comprising a bitmap that indicates information indicating a link to which the TWT consensus to be established by the above TWT element will be applied. Claim 14 In paragraph 12, the TWT request station for the TWT agreement for the second station and the second AP is the second station, and the TWT response station for the TWT agreement for the second station and the second AP is the second AP. Claim 15 In paragraph 14, the above method of operation further comprises the step of releasing the TWT agreement for the second station and the second AP when the TWT release frame is received from the second AP or when the TWT release frame is successfully transmitted to the second AP. Claim 16 delete Claim 17 delete Claim 18 delete Claim 19 In claim 12, the method of operation further comprises the step of releasing the TWT agreement between the second station and the second AP when the multi-link device successfully receives the TWT release frame from the first AP or successfully transmits the TWT release frame to the first AP, wherein the TWT agreement between the second station and the second AP is identified in the TWT release frame based on the ID of the second link, the MAC (medium access control) address of the TWT requesting station, the MAC address of the TWT response station, and the Flow ID of the TWT agreement between the second station and the second AP, wherein the TWT requesting station of the TWT agreement for the second station and the second AP is the second station, and the TWT response station of the TWT agreement for the second station and the second AP is the second AP. Claim 20 delete

Images