A multilink device that operates using multiple links and a method for operating a multilink device.

Abstract

This invention provides a wireless communication method using multilink and a wireless communication terminal that uses the same. [Solution] In a wireless communication system, a multilink device including multiple stations 100 each operating on multiple links includes a transceiver and a processor, the processor being one of the multiple stations, transmitting a TWT (target wake time) element from the first station coupled with the first AP on the first link, and requesting a TWT agreement for the second station operating on the second link and the second AP coupled with the second station.

Description

Technical Field

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

Background Art

[0002] Recently, as the spread of mobile devices has expanded, wireless LAN (Local Area Network) technology that can provide fast wireless Internet services to them has been in the spotlight. Wireless LAN technology is a technology that enables mobile devices such as smartphones, smart pads, laptop PCs, portable multimedia players, and embedded devices to be wirelessly connected to the Internet in homes, companies, or specific service-providing areas based on wireless communication technology at short distances.

[0003] Since IEEE (Institute of Electrical and Electronics Engineers) 802.11 supported the initial wireless LAN technology using a 2.4 GHz frequency, various technology standards have been put into practical use or are under development. First, IEEE 802.11b uses a frequency in the 2.4 GHz band and supports a communication speed of up to 11 Mbps. IEEE 802.11a, which was commercialized after IEEE 802.11b, uses a frequency in the 5 GHz band instead of the 2.4 GHz band, reducing the impact on interference compared to the rather congested 2.4 GHz band frequency, and uses OFDM (Orthogonal Frequency Division Multiplexing) technology to improve the communication speed up to 54 Mbps. However, IEEE 802.11a has the disadvantage of a shorter communication distance compared to IEEE 802.11b. And IEEE 802.11g uses the same 2.4 GHz band frequency as IEEE 802.11b to implement a maximum communication speed of 54 Mbps and satisfies backward compatibility, attracting considerable attention, but it is also superior to IEEE 802.11a in terms of communication distance.

[0004] Furthermore, IEEE 802.11n is a technical standard established to overcome the limitations in communication speed that had been pointed out as a vulnerability in wireless LANs. The purpose of IEEE 802.11n is to increase network speed and reliability and extend the operating range of wireless networks. Specifically, IEEE 802.11n supports high throughput (HT) with a data processing speed of up to 540 Mbps or more, 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 speed. In addition, this standard uses a coding method that transmits multiple duplicate copies to improve data reliability.

[0005] As the proliferation of wireless LANs accelerates and the applications using them diversify, there is a growing need for new wireless LAN systems that can support very high throughput (VHT) higher than the data processing speed supported by IEEE 802.11n. Among these, IEEE 802.11ac supports a wide bandwidth (80MHz to 160MHz) at the 5GHz frequency. Although the IEEE 802.11ac standard is defined only in the 5GHz band, early 11ac chipsets are expected to support operation in the 2.4GHz band for backward compatibility with older 2.4GHz band products. Theoretically, this standard allows for a minimum wireless LAN speed of 1Gbps and a maximum single-link speed of 500Mbps. This is achieved by extending the wireless interface concepts accepted in 802.11n, including wider radio frequency bandwidth (up to 160MHz), more MIMO spatial streams (up to 8), multi-user MIMO, and high-density modulation (up to 256QAM). Another method for transmitting data using the 60GHz band instead of the conventional 24GHz / 5GHz band is IEEE 802.11ad. IEEE 802.11ad is a transmission standard that uses beamforming technology to provide speeds of up to 7Gbps, making it suitable for streaming large amounts of data and high-bitrate video such as uncompressed HD video. However, the 60GHz frequency band has the disadvantage of being difficult to pass through obstacles, limiting its use to devices in short-range spaces.

[0006] Meanwhile, the IEEE 802.11ax (High Efficiency WLAN, HEW) standard has been developed and is nearing completion as a wireless LAN standard for 802.11ac and 802.11ad and beyond, to provide highly efficient and high-performance wireless LAN communication technology in high-density environments where access points (APs) and terminals are densely packed. In an 802.11ax-based wireless LAN environment, it is necessary to provide highly frequency-efficient communication indoors and outdoors in the presence of high-density stations and APs (Access Points), and various technologies have been developed to realize this.

[0007] Furthermore, in order to support new multimedia applications such as high-definition video and real-time games, development has begun on a new wireless LAN standard to increase the maximum transmission speed. The 7th generation wireless LAN standard, IEEE 802.11be (Extremely High Throughput, EHT), is being developed with the goal of supporting a maximum transmission rate of 30 Gbps in the 2.4 / 5 / 6 GHz band through wider bandwidth, increased spatial streams, and multiple AP coordination. [Overview of the project] [Problems that the invention aims to solve]

[0008] One embodiment of the present invention aims to provide a wireless communication method using multilink and a wireless communication terminal using the same. [Means for solving the problem]

[0009] An embodiment of the present invention, a multilink device including a plurality of stations each operating on a plurality of links, includes a transceiver unit; 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 and requests a TWT agreement for a second station operating on a second link and a second AP coupled to the second station.

[0010] The TWT element may include a bitmap that indicates information indicating the link to which the TWT agreement that the TWT element intends to establish applies.

[0011] The TWT request station for the TWT agreement between the second station and the second AP may be the second station, and the TWT response station for the TWT agreement between the second station and the second AP may be the second AP.

[0012] The processor may terminate the TWT agreement between the second station and the second AP if it receives a TWT termination frame from the second AP or successfully transmits the TWT termination frame to the second AP.

[0013] The processor may terminate the TWT agreement for the second station and the second AP without receiving or transmitting a TWT termination frame that terminates the TWT agreement for the second station and the second AP when the second link is deactivated.

[0014] The TWT element can request multiple TWT agreements established on multiple links, including the second link.

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

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

[0017] When the processor successfully transmits or receives a TWT deactivation frame, it can deactivate at least one of the multiple TWT agreements established on multiple links based on the link ID indicated by the TWT deactivation frame.

[0018] The processor can terminate the TWT agreement between the second station and the second AP, and transfer the TWT agreement between the second station and the second AP to the first station and the first AP.

[0019] When the processor transfers the TWT agreement for the second station and the second AP to the first station and the first AP, it can apply the TWT parameters of the TWT agreement for the second station and the second AP to the TWT agreement for the first station and the first AP.

[0020] An embodiment of the present invention describes a method for operating a multilink device including a plurality of stations each operating on a plurality of links, which includes the step of transmitting a TWT (target wake time) element from one of the plurality of stations, which is coupled to a first AP on a first link, and requesting a TWT agreement for a second station operating on a second link and a second AP coupled to the second station.

[0021] The TWT element may include a bitmap that indicates information indicating the link to which the TWT agreement that the TWT element intends to establish applies.

[0022] The TWT request station for the TWT agreement between the second station and the second AP may be the second station, and the TWT response station for the TWT agreement between the second station and the second AP may be the second AP.

[0023] The above operating method may further include a step of canceling the TWT agreement for the second station and the second AP when a TWT cancellation frame is received from the second AP or when the TWT cancellation frame is successfully transmitted to the second AP.

[0024] The operation method may further include a step of canceling the TWT agreement for the second station and the second AP without receiving or transmitting a TWT cancellation frame that cancels the TWT agreement for the second station and the second AP when the second link is deactivated.

[0025] The TWT element can request a plurality of TWT agreements established for a plurality of links including a second link.

[0026] Each of the plurality of TWT agreements established for the plurality of links may be identified based on the link ID of each of the plurality of links.

[0027] Each of the plurality of TWT agreements established for the plurality of links may 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 for the plurality of links.

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

Advantages 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 a multi-link device to perform TWT operation efficiently.

Brief Description of the Drawings

[0030] [Figure 1] It is a diagram showing a wireless LAN system according to an embodiment of the present invention. [Figure 2] It is a diagram showing a wireless LAN system according to another embodiment of the present invention. [Figure 3] It is a diagram showing the configuration of a station according to an embodiment of the present invention. [Figure 4] It is a diagram showing the configuration of an access point according to an embodiment of the present invention. [Figure 5] It is a diagram schematically showing a process in which a STA sets a link with an AP. [Figure 6] This diagram illustrates the CSMA (Carrier Sense Multiple Access) / CA (Collision Avoidance) method used in wireless LAN communication. [Figure 7] Examples of various standard generational PPDU (PLCP Protocol Data Unit) formats are shown. [Figure 8] Examples of various EHT (Extremely High Throughput) PPDU (Physical Protocol Data Unit) formats and methods for specifying them according to embodiments of the present invention are shown. [Figure 9] This shows a multi-link device according to an embodiment of the present invention. [Figure 10] The embodiments of the present invention demonstrate that transmissions on different links occur simultaneously in multilink operation. [Figure 11] An embodiment of the present invention demonstrates a method for setting up a broadcast TWT between an AP and a station. [Figure 12] This embodiment of the present invention demonstrates that AP sets a quiet interval. [Figure 13] An embodiment of the present invention describes a method for setting a TXOP (Time-Controlled Operation) that takes into account a limited service period for a station. [Figure 14] An embodiment of the present invention demonstrates that a station repeats the channel access procedure, taking into account a limited service period. [Figure 15] An embodiment of the present invention demonstrates an operation in which an AP terminates a limited service period early. [Figure 16] The format of a TWT element according to an embodiment of the present invention is shown. [Figure 17] This embodiment of the present invention demonstrates that a multilink device performs TWT agreement. [Figure 18]Embodiments of the present invention demonstrate that a station included in a multilink device performs TWT agreement for other stations included in the multilink device that includes the station. [Figure 19] This demonstrates the operation of a multilink device according to an embodiment of the present invention to release a TWT agreement. [Figure 20] The format of the Individual TWT parameter set field of a TWT element according to an embodiment of the present invention is shown. [Figure 21] The format of the remaining TWT Flow Identifier subfields, excluding the first TWT Flow Identifier subfield, according to an embodiment of the present invention is shown. [Figure 22] This shows the format of the Control field included in a TWT element transmitted by a multilink device according to an embodiment of the present invention. [Figure 23] This shows the format of the Action field of a TWT release frame transmitted by a multilink device according to an embodiment of the present invention. [Figure 24] This shows an MLD TWT Flow field according to an embodiment of the present invention. [Figure 25] The format of the MLD TWT Flow field according to yet another embodiment of the present invention is shown. [Figure 26] This invention illustrates a TWT release frame for releasing a TWT agreement established in a multilink device, according to an embodiment of the present invention. [Figure 27] This embodiment of the present invention demonstrates that a TWT agreement established between multilink devices is implicitly terminated. [Modes for carrying out the invention]

[0031] The terminology used herein has been selected to the greatest extent possible from currently widely used general terms, taking into account the function of the present invention; however, this may differ depending on the intent, conventions, or emergence of new technologies of the articulate persons in the relevant field. In addition, in certain cases, the applicant has arbitrarily selected some terms, and in such cases, the meaning of these terms will be described in the relevant section of the invention description. Therefore, it should be made clear that the terms used herein are not merely names of terms, but should be interpreted based on the substantive meaning of the terms and the content of this specification as a whole.

[0032] Throughout the specification, when one component is described as being "connected" to another, this includes not only cases where they are "directly connected," but also cases where they are "electrically connected" with other components in between. Furthermore, when a component is described as "containing" a particular component, this means, unless otherwise stated, that it may contain other components rather than excluding them. In addition, limitations such as "greater than or equal to" or "less than or equal to" a specific critical value may be appropriately replaced by "greater than" or "less than" depending on the embodiment.

[0033] In the present invention, the terms "field" and "subfield" may be used interchangeably.

[0034] Figure 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 have successfully synchronized and can communicate with each other. Generally, BSSs are classified into infrastructure BSSs and independent BSSs (IBSSs), and Figure 1 shows an infrastructure BSS.

[0036] As shown in Figure 1, the infrastructure BSS BSS1, BSS2 includes one or more stations STA1, STA2, STA3, STA4, STA5, access points AP-1, AP-2 which are stations that provide distribution services, and a distribution system DS that connects multiple access points AP-1, AP-2.

[0037] A Station (STA) is any device that includes Medium Access Control (MAC) and a Physical Layer interface to a wireless medium in accordance with the IEEE 802.11 standard, and in a broad sense includes not only non-AP stations but also all access points (APs). In this specification, "terminal" is used to refer to non-APs, APs, or both. A station for wireless communication includes a processor and a communication unit, and depending on the embodiment, further includes a user interface unit and a display unit, etc. The processor generates frames to be transmitted over the wireless network or processes frames received over the wireless network, and performs various other processing for controlling the station. The communication unit is functionally connected to the processor and sends and receives frames over the wireless network for the station. In this invention, "terminal" is used as a term that includes user equipment (UE).

[0038] An Access Point (AP) is an individual device that provides connectivity to a distribution system (DS) via a wireless medium for stations associated with it. In infrastructure BSS, communication between non-AP stations is generally conducted via APs, however, direct communication is possible between non-AP stations if a direct link is configured. In this invention, AP is used as a concept that includes PCP (Personal BSS Coordination Point), but in a broader sense, it includes all concepts such as central controllers, base stations (BS), node B, BTS (Base Transceiver System), or site controllers. In this invention, AP is also referred to as a base wireless communication terminal, but in a broader sense, base wireless communication terminal is used as a term that includes APs, base stations, eNBs (eNodeBs), and transmission points (TPs). Furthermore, base wireless communication terminals include various forms of wireless communication terminals that allocate and schedule communication medium resources in communication with multiple wireless communication terminals.

[0039] Multiple infrastructure BSSs are connected to each other via a distribution system DS. In this case, multiple BSSs connected via the distribution system are called an Extended Service Set (ESS).

[0040] Figure 2 shows an independent BSS, which is a wireless LAN system according to another embodiment of the present invention. In the embodiment of Figure 2, redundant explanations are omitted for parts that are the same as or corresponding to the embodiment of Figure 1.

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

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

[0043] First, the communication unit 120 transmits and receives wireless signals such as wireless LAN packets and may be incorporated into the station 100 or provided externally. According to one 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.4GHz, 5GHz, 6GHz, and 60GHz. According to one embodiment, the station 100 may include a communication module using a frequency band of 7.125GHz or higher and a communication module using a frequency band of 7.125GHz or lower. Each communication module can perform wireless communication with an AP or external station based on 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 multiple communication modules, each communication module may be provided in an independent form, or the multiple modules may be integrated as a single chip. In embodiments of the present invention, the communication unit 120 can represent an RF (Radio Frequency) communication module that processes RF signals.

[0044] Next, the user interface 140 includes various forms of input / output means provided in the station 100. In other words, the user interface unit 140 receives user input using various input means, and the processor 110 controls the station 100 based on the received user input. The user interface unit 140 also outputs based on instructions from the processor 110 using various output means.

[0045] Next, the display unit 150 outputs an image to the display screen. The display unit 150 outputs various display objects, such as content generated by the processor 110 or user interfaces based on control instructions from the processor 110. The memory 160 stores control programs used by the station 100 and various data associated with them. Such control programs include connection programs necessary for the station 100 to connect with APs or external stations.

[0046] The processor 110 of the present invention executes various instructions or programs and processes data within the station 100. The processor 110 also controls each unit of the station 100 and controls the transmission and reception of data between units. According to an embodiment of the present invention, the processor 110 executes a program for connection with the AP stored in the memory 160 and receives a communication setup message transmitted by the AP. The processor 110 also reads information regarding the priority conditions of the station 100 contained in the communication setup message and requests a connection to the AP based on 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, or, depending on the embodiment, may refer to a control unit for individually controlling a part of the station 100's configuration, such as the communication unit 120. In other words, the processor 110 may be a modem or a modulator and / or demodulator that modulates and demodulates the 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. A detailed embodiment relating to this will be described later.

[0047] The station 100 shown in Figure 3 is a block diagram according to one embodiment of the present invention, and the separately shown blocks represent logically distinguished elements of the device. Therefore, the above-mentioned elements of the device are mounted on one chip or multiple chips depending on the device design. For example, the processor 110 and the communication unit 120 may be integrated and implemented on a single chip, or they may be implemented on separate chips. Furthermore, in the 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 selectively provided in the station 100.

[0048] Figure 4 is a block diagram showing the configuration of AP200 according to one embodiment of the present invention. As shown, AP200 according to an embodiment of the present invention includes a processor 210, a communication unit 220, and a memory 260. In Figure 4, redundant explanations are omitted for parts of the AP200 configuration that are the same as or correspond to the configuration of station 100 in Figure 3.

[0049] Referring to Figure 4, the AP 200 according to the present invention includes a communication unit 220 for operating a BSS in at least one frequency band. As described above in the embodiment of Figure 3, the communication unit 220 of the AP 200 can also include a plurality of communication modules using different frequency bands. That is, the AP 200 according to an embodiment of the present invention can include two or more communication modules using different frequency bands, for example, 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz. Preferably, the AP 200 can include 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 can communicate wirelessly with the station based on 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 can 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 can represent an RF (Radio Frequency) communication module that processes RF signals.

[0050] Next, the memory 260 stores the control program used by the AP200 and various data associated with it. Such a control program includes a connection program that manages the connection of stations. The processor 210 controls each unit of the AP200 and controls the transmission and reception of data between units. According to an embodiment of the present invention, the processor 210 executes the program for connecting with stations stored in the memory 260 and transmits a communication setting message to one or more stations. In this case, the communication setting message includes information regarding the connection priority conditions of each station. The processor 210 also performs connection settings in response to connection requests from stations. According to one embodiment, the processor 210 is a modem or modulation / demodulation unit that modulates and demodulates the wireless signals transmitted and received from the communication unit 220. The processor 210 controls various operations of wireless signal transmission and reception of the AP200 according to an embodiment of the present invention. A detailed embodiment relating thereto will be described later.

[0051] Figure 5 is a schematic diagram illustrating the process by which STA establishes a link with AP.

[0052] Referring to Figure 5, the link between STA100 and AP200 is established through three main steps: scanning, authentication, and association. First, the scanning step is the step in which STA100 obtains connection information for the BSS operated by AP200. There are two methods for performing scanning: passive scanning, which obtains information using only the beacon message S101 that AP200 periodically transmits, and active scanning, in which STA100 transmits a probe request S103 to the AP, receives a probe response S105 from the AP, and obtains connection information.

[0053] In the scanning step, STA100, having successfully received wireless connection information, transmits an authentication request (S107a), receives an authentication response from AP200 (S107b), and performs the authentication step. After the authentication step is performed, STA100 transmits an association request (S109a), receives an association response from AP200 (S109b), and performs the association step. In this specification, "association" basically means wireless coupling, but the present invention is not limited to this, and in a broad sense, coupling includes both wireless and wired coupling.

[0054] On the other hand, an additional 802.1X-based authentication step S111 and an IP address acquisition step S113 via DHCP are performed. In Figure 5, Server 300 is a server that processes authentication between STA100 and the 802.1X-based system, and may be physically connected to AP200 or exist as a separate server.

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

[0056] A terminal performing wireless LAN communication checks whether a channel is busy or not by performing carrier sensing before transmitting data. If a wireless signal above a certain strength 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 at which the detection of the signal is determined is called the CCA threshold. If a wireless signal above the CCA threshold is received by the terminal and the terminal is the recipient, the terminal processes the received wireless signal. On the other hand, if no wireless signal is detected from the channel, or if a wireless signal below the CCA threshold is detected, the channel is determined to be idle.

[0057] If a channel is determined to be idle, each terminal with data to transmit performs a backoff procedure after a time period determined by the status of each terminal, such as an IFS (Inter Frame Space), AIFS (Arbitration IFS), PIFS (PCF IFS), etc. In this embodiment, the AIFS is used as a replacement for the conventional DIFS (DCF IFS). Each terminal waits, decreasing a slot time equal to a random number determined for that terminal during the interval of idle state of the channel, and the terminal that has exhausted all of its slot time attempts to access the channel. The period in which each terminal performs this backoff procedure is called the competition window period. At this time, the random number can be called the backoff counter. That is, the initial value of the backoff counter is set by an integer, which is a random number acquired by the terminal. If a terminal senses that a channel is idle during the slot time, the terminal can decrease the backoff counter by 1. Also, when the backoff counter reaches 0, the terminal may be allowed to access the channel. Therefore, terminal transmission may be permitted when the channel is idle during the AIFS time and the backoff counter slot time.

[0058] If a specific terminal successfully accesses the channel, it transmits data through the channel. However, if a terminal attempting access collides with another terminal, the colliding terminals are each assigned a new random number and perform a further backoff procedure. In one embodiment, the random number newly assigned to each terminal is determined within a range twice the range (competition window, CW) of the random number previously assigned to that terminal (2*CW). Meanwhile, each terminal attempts access again in the next competition window interval by performing a further backoff procedure, but this time, each terminal performs the backoff procedure from the slot time remaining in the previous competition window interval. In this way, each terminal performing wireless LAN communication can avoid collisions with each other for a specific channel.

[0059] <Examples of various PPDU formats>

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

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

[0062] Referring to Figure 7(b), the HE PPDU preamble further 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 embodiments of the present invention, RL-SIG, HE-SIG-A, HE-SIG-B, HE-STF, and HE-LTF can 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 Figure 7(c), the EHT PPDU preamble further 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 embodiments of the present invention, RL-SIG, EHT-SIG-A, EHT-SIG-B, EHT-STF, and EHT-LTF can 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 PPDU preamble is configured with 64 FFT 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 BPSK and a Rate=1 / 2 MCS (Modulation and Coding Scheme) are applied to the L-SIG, 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 Figure 7(d), 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 indicates one of the transmission speeds of 6 / 9 / 12 / 18 / 24 / 36 / 48 / 54 Mbps, which is a combination of a modulation scheme such as BPSK / QPSK / 16-QAM / 64-QAM and a code rate such as 1 / 2, 2 / 3, or 3 / 4. Combining the information from the L_RATE and L_LENGTH fields allows us to determine the total length of the PPDU. In non-legacy PPDU formats, the L_RATE field is set to the minimum speed of 6 Mbps.

[0066] The L_LENGTH field is measured in bytes, with a total of 12 bits allocated, allowing for signaling up to 4095. In combination with the L_RATE field, it can indicate the length of the PPDU. In this case, legacy and non-legacy terminals can parse the L_LENGTH field in different ways.

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

[0068]

number

[0069] At this time,

[0070]

number

[0071] x 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 may be set to a maximum of 5.484 ms. Non-legacy terminals sending the PPDU must set the L_LENGTH field as shown in Equation 3 below.

[0072]

number

[0073] Here, TXTIME is the total transmission time that constitutes the PPDU, as shown in Equation 4 below. In this case, TX represents the transmission time of X.

[0074]

number

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

[0076] Referring to Figure 7(e), the U-SIG (Universal SIG) field persists in EHT PPDUs and subsequent generations of wireless LAN PPDUs, playing a role in distinguishing which generation of PPDU it is, including 11be. The U-SIG is a 64FFT-based OFDM with two symbols, capable of transmitting a total of 52 bits of information. Of these, 43 bits, excluding the 9 bits of CRC / tail, are broadly divided into the VI (Version Independent) field and the VD (Version Dependent) field.

[0077] The VI bit maintains its current bit configuration, allowing current 11be terminals to obtain information about a PPDU from its VI field even when subsequent generations of PPDUs are defined. To this end, the VI field consists of the PHY version, UL / DL, BSS color, TXOP, and Reserved fields. The PHY version field is 3 bits and is responsible for sequentially distinguishing 11be and subsequent generations of wireless LAN standards by version. 11be has a value of 000b. The UL / DL field distinguishes whether the PPDU is an uplink or downlink PPDU. The BSS color represents the BSS identifier defined in 11ax and has a value of 6 bits or more. The TXOP represents the Transmit Opportunity Duration, which was transmitted in the MAC header, but by adding it to the PHY header, the length of the TXOP containing the PPDU can be inferred without decoding the PPDU, and it has a value of 7 bits or more.

[0078] The VD field may consist of the PPDU format as signaling information useful only for the 11be version of PPDU, fields that are common to any PPDU format such as BW, and fields that are defined differently depending on the PPDU format. The PPDU format is a divisor that distinguishes between EHT SU (Single User), EHT MU (Multiple User), EHT TB (Trigger-based), EHT ER (Extended Range) PPDU, etc. The BW field broadly signals five basic PPDU BW options of 20, 40, 80, 160 (80+80), and 320 (160+160) MHz (BW that can be expressed in the form of a power of 20*2 can be called a basic BW), and various remaining PPDU BWs composed of preamble puncturing. In addition, after being signaled at 320 MHz, some 80 MHz may be punctured and then signaled. Furthermore, the punctured and deformed channel shape may be signaled directly in the BW field, or it may be signaled using both the BW field and fields appearing after the BW field (for example, fields within the EHT-SIG field). If the BW field is 3 bits, a total of 8 BW signalings are possible, so a maximum of 3 puncturing modes can be signaled. If the BW field is 4 bits, a total of 16 BW signalings are possible, so a maximum of 11 puncturing modes can be signaled.

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

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

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

[0082] In the case of an SU PPDU, multiple RUs may be assigned to the STA, and these RUs may be consecutive or discontinuous. If the RUs assigned to the STA are not consecutive, the STA can efficiently receive the SU PPDU only if it recognizes the punctured RU in the middle. Therefore, the AP can transmit the SU PPDU including information about the punctured RUs among the RUs assigned to the STA (e.g., the puncturing pattern of the RUs). That is, in the case of an SU PPDU, the EHT-SIG field may contain a puncturing mode field that includes information on whether a puncturing mode was applied and the puncturing pattern shown in bitmap format or similar, and the puncturing mode field can signal the form of discontinuous channels appearing within the bandwidth.

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

[0084] The reason only restricted forms of discontinuous channel configurations are signaled is to reduce the signaling overhead of the SU PPDU. Since puncturing can be performed on each 20MHz subchannel, when puncturing is performed on a bandwidth with multiple 20MHz subchannels, such as 80, 160, and 320MHz, in the case of 320MHz, the usage status of the remaining 15 20MHz subchannels other than the primary channel must be represented, and the discontinuous channel configuration (if a configuration where only the end 20MHz is punctured is also considered discontinuous) must be signaled. Using 15 bits to signal discontinuous channel configurations for single-user transmissions in this way can result in excessive signaling overhead when considering the low transmission speed of the signaling portion.

[0085] This invention proposes a method for signaling the discontinuous channel configuration of an SU PPDU and illustrates the discontinuous channel configuration determined by the proposed method. Furthermore, it proposes a method for signaling the primary 160MHz and secondary 160MHz puncturing configurations of an SU PPDU in a 320MHz BW configuration.

[0086] Furthermore, in one embodiment of the present invention, a method is proposed in which the configuration of the PPDU indicated by the preamble puncturing BW value differs depending on the signaled PPDU format in the PPDU format field. Assuming that the BW field is 4 bits, in the case of an EHT SU PPDU or TB PPDU, one symbol of EHT-SIG-A is further signaled after U-SIG, or it is not necessary to signal EHT-SIG-A from the beginning. Taking this into consideration, it is necessary to fully signal up to 11 puncturing modes using only the BW field of U-SIG. However, in the case of an EHT MU PPDU, EHT-SIG-B is further signaled after U-SIG, so up to 11 puncturing modes can be signaled in a different way than in an SU PPDU. In the case of an EHT ER PPDU, the BW field can be set to 1 bit to signal whether the PPDU uses a 20MHz or 10MHz bandwidth. Detailed puncturing patterns for each PPDU type will be described in detail in Figures 11 and 12.

[0087] Figure 7(f) shows the format-specific fields of the VD field when EHT MU PPDU is indicated in the U-SIG PPDU format field. In the case of MU PPDU, SIG-B, which is a signaling field for simultaneous reception by multiple users, is required, and SIG-B may be transmitted after U-SIG without a separate SIG-A. For this purpose, U-SIG must signal information for decoding SIG-B. Such fields include SIG-B MCS, SIG-B DCM, Number of SIG-B Symbols, SIG-B Compression, and Number of EHT-LTF Symbols fields.

[0088] Figure 8 shows examples of various EHT (Extremely High Throughput) PPDU (Physical Protocol Data Unit) formats and methods for specifying them according to embodiments of the present invention.

[0089] Referring to Figure 8, a PPDU may consist of a preamble and a data portion, and one type of format, EHT PPDU, may be distinguished by a U-SIG field included in the preamble. Specifically, whether or not the PPDU format is an EHT PPDU may be indicated based on the PPDU format field included in the U-SIG field.

[0090] Figure 8(a) shows an example of the 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 may have an EHT-SIG-A field for additional signaling after the U-SIG field.

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

[0092] Figure 8(c) shows an example of the EHT MU PPDU format, which is an EHT PPDU for multiple users. An EHT MU PPDU is a PPDU used to send 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.

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

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

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

[0096] For example, among the multiple divided resource units, the user field corresponding to at least one resource unit used for data transmission may contain the recipient's or sender's AID, while the user fields corresponding to the remaining resource units not used for data transmission may contain a previously set Null STA ID.

[0097] For the sake of clarity, the terms frame or MAC frame may be used interchangeably with MPDU in this specification.

[0098] 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 is a physical path and may be configured as a single wireless medium that can be used to transmit an MSDU (MAC service data unit). For example, if the frequency band of one link is being used by another wireless communication device, the wireless communication device can continue to communicate using another link. In this way, the wireless communication device can make effective use of multiple channels. Furthermore, when the wireless communication device communicates simultaneously using multiple links, the overall throughput can be increased. However, existing wireless LANs are defined on the premise that one wireless communication device uses one link. Therefore, a wireless LAN operation method for using multiple links is necessary. Referring to Figures 9 to 26, the wireless communication method for a wireless communication device using multiple links will be explained. First, using Figure 9, a specific form of a wireless communication device using multiple links will be explained.

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

[0100] A multi-link device (MLD) may be defined for the wireless communication method using the multiple links described above. A multi-link device can represent a device having one or more affiliated stations. In specific embodiments, a multi-link device can represent a device having two or more affiliated stations. A multi-link device can also 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 the multi-link setup element described later. In this case, the multi-link device may be a logical entity. Specifically, a multi-link device can have multiple affiliated stations. A multi-link device can be called an MLLE (multi-link logical entity) or an MLE (multi-link entity). A multi-link device can have one medium access control service access point (SAP) up to logical link control (LLC). An MLD can also have one MAC data service.

[0101] Multiple stations included in a multilink system can operate on multiple links. Furthermore, multiple stations included in a multilink system can operate on multiple channels. Specifically, multiple stations included in a multilink system can operate on different links or different channels. For example, multiple stations included in a multilink system can operate on different channels of 2.4GHz, 5GHz, and 6GHz.

[0102] The operation of a multilink device can be called multilink operation, MLD operation, or multi-band operation. Furthermore, if the station paired with the multilink device is an AP (Application Platform), the multilink device can be called an AP MLD (Application Platform Multilink). Conversely, if the station paired with the multilink device is a non-AP station, the multilink device can be called a non-AP MLD (Application Platform Multilink).

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

[0104] Multilink operation can include a multilink setup operation. Multilink setup corresponds to the association operation of single-link operation described above and must be performed before frame exchange in multilink. A multilink device can obtain the information necessary for multilink setup from a multi-link setup element. Specifically, the multi-link setup element can include capability information related to multilink. In this case, capability information can include information indicating whether one of the multiple devices included in the multilink device can transmit and the other devices can receive simultaneously. Capability information can also include information about the links available to each station included in the MLD. Capability information can also include information about the channels available to each station included in the MLD.

[0105] Multilink configuration may be established through negotiations between peer stations. Specifically, multilink configuration may be performed through communication between stations without communication with the AP. Furthermore, multilink configuration may be established through any one of the links. For example, even if links 1 through 3 are configured via a multilink, the multilink configuration may be performed through link 1.

[0106] Furthermore, a mapping between TIDs (traffic identifiers) and links may be configured. Specifically, frames corresponding to a specific TID value may be exchanged only through pre-specified links. The mapping between TIDs and links may be configured in a directional-based manner. For example, if multiple links are configured between a first multilink device and a second multilink device, the first multilink device may be configured to send frames with a first TID to multiple first links, and the second multilink device may be configured to send frames with a second TID to the first links. Additionally, a default setting may exist for the mapping between TIDs and links. Specifically, if there are no additional settings in the multilink configuration, the multilink device can exchange frames corresponding to TIDs on each link according to the default setting. In this case, the default setting may be such that all TIDs are exchanged on any one link.

[0107] Let's explain TID in detail. TID is an ID used to classify traffic and data to support QoS (Quality of Service). TID may be used and assigned at layers higher than the MAC layer. TID can also indicate traffic category (TC) and traffic stream (TS). There may be 16 distinct TID values. For example, a TID may be specified as one of the values ​​from 0 to 15. Different TID values ​​may be specified depending on the access policy, channel access, or medium access method. For example, when EDCA (enhanced distributed channel access) or HCAF (hybrid coordination function contention based channel access) is used, the TID value may be assigned in the range of 0 to 7. When EDCA is used, TID can indicate user priority (UP). In this case, UP may be specified by TC or TS. UP may be assigned at layers higher than MAC. Furthermore, when HCCA (HCF controlled channel access) or SPCA is used, the TID value may be assigned in the range of 8 to 15. When HCCA or SPCA is used, TID can represent TSID. Furthermore, when HEMM or SEMM is used, the TID value may be assigned in the range of 8 to 15. When HEMM or SEMM is used, TID can represent TSID.

[0108] UP and AC (access category) may be mapped. AC may be a label for providing QoS in EDCA. AC may be a label for indicating an EDCA parameter set. EDCA parameters or EDCA parameter sets are parameters used in EDCA channel contention. QoS stations can guarantee QoS using AC. AC can also include AC_BK, AC_BE, AC_VI, and AC_VO. AC_BK, AC_BE, AC_VI, and AC_VO can indicate background, best effort, video, and voice, respectively. AC_BK, AC_BE, AC_VI, and AC_VO may also be classified into sub-ACs. For example, AC_VI can be subdivided into AC_VI primary and AC_VI alternate. Similarly, AC_VO can be subdivided into AC_VO primary and AC_VO alternate. UP or TID may also be mapped to AC. For example, each of 1, 2, 0, 3, 4, 5, 6, and 7 in UP or TID may be mapped to AC_BK, AC_BK, AC_BE, AC_BE, AC_VI, AC_VI, AC_VO, and AC_VO, respectively. Also, each of 1, 2, 0, 3, 4, 5, 6, and 7 in UP or TID may be mapped to AC_BK, AC_BK, AC_BE, AC_BE, AC_VI alternate, AC_VI primary, AC_VO primary, and AC_VO alternate, respectively. Furthermore, the priority of 1, 2, 0, 3, 4, 5, 6, and 7 in UP or TID may be in that order from highest to lowest. That is, 1 may have a lower priority and 7 may have a higher priority. Therefore, the priority may be in the order of AC_BK, AC_BE, AC_VI, and AC_VO, from highest to lowest. Furthermore, 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 TIDs, the mapping between TIDs and links can represent the mapping between ACs and links.Furthermore, the mapping between links and ACs can represent the mapping between TIDs and links.

[0109] As mentioned above, a TID may be mapped to each of multiple links. The mapping may specify which links can exchange traffic corresponding to a particular TID or AC. Additionally, TIDs or ACs that can be transmitted in different transmission directions within a link may be specified. As mentioned above, a default setting may exist for the mapping between TIDs and links. Specifically, in a multilink configuration where no additional settings are made, the multilink device can exchange frames corresponding to TIDs on each link according to the default setting. In this case, the default setting may be that all TIDs are exchanged on any one link. At any given time, any TID or AC may always be mapped to at least one link. Management frames and control frames may be transmitted on all links.

[0110] When a link is mapped to a TID or AC, only data frames corresponding to the TID or AC mapped to that link may be transmitted on that link. Therefore, when a link is mapped to a TID or AC, frames that do not correspond to a TID or AC not mapped to that link do not need to be transmitted on that link. When a link is mapped to a TID or AC, the ACK may also be transmitted based on the link to which the TID or AC is mapped. For example, a block ACK agreement may be determined based on the mapping between TIDs and links. Furthermore, in other specific embodiments, the mapping between TIDs and links may be determined based on a block ACK agreement. Specifically, a block ACK agreement may be set for a TID mapped to a particular link.

[0111] The aforementioned mapping of TIDs to links may ensure QoS. Specifically, a relatively small number of stations may be operational, or higher-priority ACs or TIDs may be mapped to links with good channel conditions. Furthermore, the aforementioned mapping of TIDs to links may enable stations to maintain a power-saving state for longer periods.

[0112] Figure 10 shows that, according to an embodiment of the present invention, transmissions on different links are performed simultaneously in multilink operation.

[0113] The implementation of multilink devices does not always support simultaneous operation on multiple links. For example, a multilink device may support simultaneous transmission on multiple links, simultaneous reception on multiple links, or transmission on one link while receiving on another. Reception or transmission on one link may affect reception or transmission on other links. Specifically, transmission on one link may act as interference on other links. Interference from one link of a multilink device affecting other links can be called internal leakage. Internal leakage tends to increase as the frequency spacing between links decreases. If internal leakage is not too large, transmission on one link can occur while transmission is occurring on other links. If internal leakage is large, transmission on one link cannot occur while transmission is occurring on other links. Thus, simultaneous operation of multiple links by a multilink device can be called STR (simultaneous transmit and receive, simultaneous transmission and reception). For example, when a multilink device transmits on multiple links simultaneously, transmits on one link while receiving on another, or receives on multiple links simultaneously, this can be called STR (Simultaneous Transmission / Reception).

[0114] As mentioned earlier, multilink devices can support STR (Stroke Response) both fully and with limitations. Specifically, multilink devices can only support STR under certain conditions. For example, a multilink device may not be able to perform STR when operating as a single radio. Similarly, a multilink device may not be able to perform STR when operating as a single antenna. Furthermore, a multilink device may not be able to perform STR if internal leakage is detected to be above a predetermined level.

[0115] A station can exchange information with other stations regarding its STR capability. Specifically, a station can exchange information with other stations regarding whether there are limitations on its ability to transmit or receive on multiple links simultaneously. Specifically, information regarding limitations on the ability to transmit or receive on multiple links may indicate whether transmission or reception occurs simultaneously on multiple links, or whether transmission and reception occur simultaneously. Furthermore, information regarding limitations on the ability to transmit or receive on multiple links may be indicated in stages. Specifically, information regarding limitations on the ability to transmit or receive on multiple links may be information indicating stages indicating the magnitude of internal leakage. In a specific embodiment, information indicating stages indicating the magnitude of internal leakage may be information indicating stages indicating the magnitude of interference caused by internal leakage. In yet another specific embodiment, it may be information indicating stages indicating the frequency spacing between links that may affect internal leakage. Furthermore, information indicating stages 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 stages.

[0116] In Figure 10, the first station (STA1) and the second station (STA2) are affiliated to a single non-AP multilink device. Alternatively, the first AP (AP1) and the second AP (AP2) may also be affiliated to a single non-AP multilink device. A first link (link1) is established between the first AP (AP1) and the first station (STA1), and a second link (link2) is established between the second AP (AP2) and the second station (STA2). In Figure 10, the non-AP multilink device can perform STR (Signal Transmitting) to a limited extent. When the second station (STA2) transmits on the second link (Link2), reception by the first station (STA1) on the first link (Link1) may be interfered with by transmission on the second link (Link2). For example, in the following case, reception by the first station (STA1) on the first link (Link1) may be interfered with by transmission on the second link (Link2). On the second link (Link2), the second station (STA2) transmits the first data (Data1), and the first access point (AP1) transmits an acknowledgment (Ack for Data1) to the first station (STA1). On the second link (Link2), the second station (STA2) transmits the second data (Data2). At this time, the transmission timing of the second data (Data2) and the transmission timing of the acknowledgment (Ack for Data1) may overlap. In this case, the transmission to the second station (STA2) on the second link (Link2) may cause interference on the first link (Link1). Therefore, the first station (STA1) may not receive the acknowledgment (Ack for Data1) for the first data (Data1).

[0117] This section describes how a multilink device performs channel access. For multilink operations not specifically described, the channel access procedure shown in Figure 6 can be followed.

[0118] A multilink device can perform channel access independently from multiple links. In this case, the channel access may be backoff-based channel access. When the multilink device performs channel access independently from multiple links and the backoff counters reach 0 on multiple links, the multilink device can start transmitting on multiple links simultaneously. In a specific embodiment, when the backoff counter of any one of the links in the multilink reaches 0 and a predetermined condition is met, the multilink device can perform channel access on other links where the backoff counter has not reached 0, in addition to the link where the backoff counter reached 0. Specifically, when the backoff counter of any one of the links in the multilink reaches 0, the multilink device can sense energy on other links where the backoff counter has not reached 0. In this case, if no energy greater than a predetermined amount is sensed, the multilink device can perform channel access on the link where energy sensing was performed, in addition to the link where the backoff counter reached 0. This allows the multilink device to start transmitting on multiple links simultaneously. The size of the threshold used for energy sensing may be smaller than the size of the threshold used when deciding whether to decrease the backoff counter. Furthermore, when deciding whether to reduce the backoff counter, the multilink device can sense any form of signal, not just Wi-Fi signals. Also, in the energy sensing described above, the multilink device can sense any form of signal, not just Wi-Fi signals. Internal leakage may not be detected as a Wi-Fi signal. In such cases, the multilink device can detect the signal detected by internal leakage through energy sensing. Also, as mentioned above, the size of the threshold used for energy sensing can be smaller than the size of the threshold used when deciding whether or not to reduce the backoff counter. Therefore, even when transmission is taking place on one link, the multilink device can reduce the backoff counter on other links.

[0119] The degree of interference between links used by the multilink device may determine whether the stations operating on each link can operate independently. In this case, the degree of interference between links may be the magnitude of interference perceived by other stations of the multilink device when any one station of the multilink device transmits on any one link. If the transmission of the first station of the multilink device on the first link causes interference exceeding a predetermined magnitude to the second station of the multilink device operating on the second link, the operation of the second station may be restricted. Specifically, the reception or channel access of the second station may be restricted. When interference occurs, the second station may fail to decode the received signal due to the interference. Also, when interference occurs, the second station may determine that the channel is in use when using backoff for channel access.

[0120] Furthermore, if the transmission from the first station of a multilink device on the first link causes interference below a predetermined magnitude to the second station of the multilink device operating on the second link, the first and second stations can operate independently. Specifically, if the transmission from the first station of a multilink device on the first link causes interference below a predetermined magnitude to the second station of the multilink device operating on the second link, the first and second stations can independently access the channel. Also, if the transmission from the first station of a multilink device on the first link causes interference below a predetermined magnitude to the second station of the multilink device operating on the second link, the first and second stations can independently transmit or receive. When interference below a predetermined magnitude occurs, the second station can successfully decode the received signal even in the presence of interference. Also, when interference below a predetermined magnitude occurs, the second station can determine that the channel is idle when using backoff for channel access.

[0121] The degree of interference between stations in a multilink system can vary not only depending on the interval between the frequency bands of the links on which the stations operate, but also on the hardware characteristics of the multilink system. For example, internal interference in a multilink system that includes high-RF (radio frequency) equipment may be less than internal interference in a multilink system that includes low-RF equipment. Therefore, the degree of interference between stations in a multilink system may be determined based on the characteristics of the multilink system.

[0122] Figure 10 shows that the magnitude of interference varies depending on the interval between the frequency bands of the links and the characteristics of the multilink device. In the embodiment shown in Figure 10, the first multilink 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 multilink 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 interval between the first link (Link1) and the second link (Link2) in which the first multilink device (MLD#1) operates is the same as the frequency interval between the first link (Link1) and the second link (Link2) in which the second multilink device (MLD#2) operates. However, the magnitude of interference differs due to the difference between the characteristics of the first multilink device (MLD#1) and the characteristics of the second multilink device (MLD#2). Specifically, the magnitude of interference generated by the second multilink device (MLD#2) may be greater than the magnitude of interference generated by the first multilink device (MLD#1). Considering that the magnitude of interference may differ depending on the characteristics of the multilink devices, and that the availability of STR support may vary for each multilink device, it is necessary to exchange information regarding whether or not STR support is provided.

[0123] A multilink device can signal whether or not a station it includes provides STR support. Specifically, an AP multilink device and a non-AP multilink device can exchange whether or not an AP included in the AP multilink device provides STR support and whether or not a STA included in the non-AP multilink device provides STR support. In such an embodiment, an element indicating the presence or absence of STR support may be used. This element can be called an STR support element. The STR support element can indicate, with one bit, whether or not a station in the multilink device that transmitted the STR support element provides STR support. Specifically, the STR support element can indicate, one bit at a time, whether or not each station included in the multilink device that transmitted the STR support element provides STR support. In this case, the bit value may be 1 when the station provides STR support, and 0 when the station does not provide STR support. If the multilink device that transmits the 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 the STR, but the second station (STA2) does not, then the STR support element is 101 1b The STR support element may include a field containing a bit. It is assumed that stations operating in different frequency bands support each other, and the STR support element may omit signaling for the presence or absence of STR support between stations operating in different frequency bands. For example, suppose the first station (STA1) operates on the 2.4GHz first link, and the second station (STA2) and third station (STA3) operate on the 5GHz second and third links, respectively. In this case, the STR support element can indicate with one bit that STR support is provided between the second station (STA2) and the third station (STA3). The STR support element may also contain only one bit if there are two stations to which the STR support element signals.

[0124] In a specific embodiment, the relationship between a link located at 2.4 GHz and a link located at 5 GHz or 6 GHz in a multilink device may always be considered a STR (Structured Link). Therefore, signaling for the presence or absence of a STR between the 2.4 GHz link and the 5 GHz or 6 GHz link may be omitted.

[0125] In the embodiments described above, what is described as the operation of a station in a multilink device may be replaced with the operation of the multilink device itself. Also, in the embodiments described above, the operation of the AP may be replaced with the operation of a non-AP station, and the operation of a non-AP station may be replaced with the operation of the AP. Therefore, the operation of the AP in a non-STR multilink device may be replaced with the operation of a non-AP station in a non-STR multilink device, and the operation of a non-AP station in an STR multilink device may be replaced with the operation of the AP in an STR multilink device. Furthermore, the operation of a non-AP station in a non-STR multilink device may be replaced with the operation of the AP in a non-STR multilink device, and the operation of the AP in an STR multilink device may be replaced with the operation of a non-AP station in an STR multilink device.

[0126] Scheduling for low-latency traffic transmission is explained in Figures 11 to 15. In conventional wireless LAN communication, EDCA (enhanced distributed channel access) is used to set channel access parameters for each AC, and the set channel access parameters are used to support traffic processing according to priority for each AC. However, existing EDCA provides channel access with a probabilistically high priority, and therefore has shortcomings in supporting the transmission of low-latency traffic. To compensate for this, it is possible to set a time interval in which low-latency traffic can be transmitted preferentially. For the sake of explanation, the time interval in which low-latency traffic is transmitted preferentially is called the restricted service period. Most services that require low-latency traffic transmission, such as VR / AR, require periodic traffic transmission, and therefore the effect of reducing the transmission delay of low-latency traffic by using the restricted service period is significant.

[0127] 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, a restricted service period may be a time interval in which only the transmission of low-latency traffic and the transmission of responses to low-latency traffic are permitted. In yet another specific embodiment, 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 have occurred, and the transmission of traffic other than low-latency traffic is permitted after the transmission of low-latency traffic and the transmission of responses to low-latency traffic have been completed.

[0128] First, we will explain how to set a restricted service period. The restricted service period may be set by the TWT of an existing WLAN. The TWT sets a service period through consultation between the AP and the station, and the AP and station transmit and receive data during the service period, while assisting in entering low-power mode outside of the service period. This will be explained in detail in Figure 11. For the sake of explanation, we will refer to the setting of a restricted service period by the TWT and the operation of the AP and station based on the said restricted service period as a restricted TWT.

[0129] Figure 11 shows a method for setting up a broadcast TWT between an AP and a station according to an embodiment of the present invention.

[0130] In a TWT, the service period may be set as follows: An AP requests an associated station to participate in the TWT. The station can participate in the broadcast TWT or negotiate with the AP about an individual TWT. At this time, 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. Alternatively, the AP can transmit the Broadcast TWT element in a management frame, such as a beacon frame, to convey the information necessary for the station to participate in the broadcast TWT. At this time, the AP can signal that it supports the broadcast TWT by setting dot11TWTOptionActivated to true and setting the Broadcast TWT Support field (of the HE Capabilities element) to 1. The AP can set a restricted service period similar to the TWT service period.

[0131] In the embodiment shown in Figure 11, the first station (STA1) requests the AP to configure the TWT. The AP and the first station (STA1) configure the TWT parameters, such as the initial TBTT and the listen interval. This configures the broadcast TWT for the AP, the first station (STA1), and the second station (STA2). The AP uses a beacon frame to indicate the broadcast TWT service period. During the broadcast TWT service period, the AP can either 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 about the TWT from the received beacon frame. The AP sends a trigger frame to the first station (STA1) and the second station (STA2). The first station (STA1) sends a PS-Poll frame to the AP, and the second station (STA2) sends a QoS Null frame to the AP. The AP receives the PS-Poll frame and QoS Null frame sent 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 sends a multi-STA Block ACK frame to the first station (STA1) and the second station (STA2). The AP sends a DL PPDU to the first station (STA1) and the second station (STA2).

[0132] The existing TWT service period does not restrict stations that do not participate in the TWT from accessing the channel or transmitting. This is because the TWT is intended to help stations participating in the TWT enter a doze state. However, a restricted service period designed to prevent transmission delays of low-latency traffic must guarantee preferential transmission of low-latency traffic, and therefore, a method is needed to protect the restricted service period.

[0133] During a restricted service period, stations not participating in a restricted TWT may be restricted from accessing the channel. Specifically, stations not participating in a restricted TWT may not be able to access the channel during the restricted service period. If a station not participating in a restricted TWT completes channel access during the restricted service period, the station may restart the channel access procedure without transmitting. In this case, the station can restart the channel access procedure when the restricted service period ends. Furthermore, a station's channel access can represent an EDCA backoff procedure. Completion of channel access can represent the EDCA backoff procedure's backoff counter reaching 0. Also, when a station restarts the channel access procedure, the station may randomly obtain an integer within the CW used for the previous channel access and use the obtained integer as the backoff counter. That is, the station does not need to double the size of the CW used for the previous channel access. In this case, the CW may be maintained separately for each AC. Such channel access restrictions may only be applied to stations supporting a restricted TWT. Specifically, such channel access restrictions apply only to non-legacy (EHT) stations where the EHT Capabilities element's dot11RestrictedTWTOptionImplemented is set to true, and do not apply to non-legacy (EHT) stations where the EHT Capabilities element's dot11RestrictedTWTOptionImplemented is set to false. In this specification, non-legacy stations can represent EHT stations and stations after EHT stations. Legacy stations are stations before EHT stations and can represent non-HT stations, HT stations, VHT stations, and HE stations.

[0134] Furthermore, during the restricted service period, non-legacy stations may be configured with NAVs for traffic other than low-latency traffic. Specifically, as if NAVs were configured for traffic other than low-latency traffic, stations can suspend channel access procedures for transmitting traffic other than low-latency traffic. In such embodiments, the NAV may be independent of conventional NAVs (basic NAVs, Intra-BSS NAVs). In this case, non-legacy stations may be limited to stations supporting restricted TWTs. In yet another specific embodiment, non-legacy stations may be limited to stations participating in restricted TWTs.

[0135] The restricted service period may be included within the broadcast TWT service period. Furthermore, in other specific embodiments, the restricted service period may not be included within the broadcast TWT service period.

[0136] Furthermore, the restricted service period may be repeated at a frequency specified by the AP. That is, the AP can specify the repetition frequency of the restricted service period. This eliminates the need for the AP to send a TWT element of the beacon frame every time to set the restricted service period. In this case, the service period frequency may be set according to the characteristics of the low-latency service using low-latency traffic. For example, the frequency of a low-latency service period where low-latency traffic is generated every 50ms may be 50ms.

[0137] Furthermore, a Quiet Interval may be set for stations that do not support the restricted TWT. In conventional wireless LANs, the Quiet Interval is a section that supports channel sensing. When the Quiet Interval is set, all stations suspend transmission. This characteristic of the Quiet Interval can be used to protect the restricted service period. This is explained in Figure 12. In this case, stations that do not support the restricted TWT may be limited to legacy stations.

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

[0139] APs operating a restricted TWT can send a Quiet element to set a quiet section. During the quiet section, stations suspend channel access. However, if channel access is restricted for stations participating in the restricted TWT, they will not be able to send low-latency traffic. Therefore, stations participating in a restricted TWT may ignore the quiet section corresponding to the restricted service period. In this case, the quiet section corresponding to the restricted service period represents the quiet section set to protect the restricted service period of the restricted TWT. Specifically, stations participating in a restricted TWT can consider the quiet section corresponding to the restricted service period as the restricted service period itself. APs operating a restricted TWT do not need to set the quiet section to match the restricted service period. This is because the quiet section in the Quiet element is set in TU (time unit, 1024us) units, and the TWT is set in 256us units.

[0140] However, channel access in a quiet section other than one not set for a restricted service period may interfere with quiet sections not set for a restricted service period. Therefore, it is necessary to distinguish between quiet sections set for a restricted service period, i.e., quiet sections corresponding to a restricted service period. Consequently, stations participating in a restricted TWT may not be able to ignore quiet sections that do not correspond to a restricted service period. Stations cannot transmit at all in quiet sections that do not correspond to a restricted service period. Specifically, stations participating in a restricted TWT may not be able to ignore quiet sections that do not overlap with a restricted service period. In a specific example, stations participating in a restricted TWT cannot transmit at all in quiet sections that do not overlap with a restricted service period.

[0141] Furthermore, in the above embodiment, a station participating in a restricted TWT can be considered a quiet section corresponding to a restricted service period if the start time of the restricted service period and the start time of the quiet section are within a predetermined time. As mentioned above, APs operating a restricted TWT do not need to set the quiet section to coincide with the restricted service period.

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

[0143] As mentioned earlier, channel access may be restricted during the restricted service period. This means that such restrictions may also apply to TXOP configurations. This is illustrated in Figure 13.

[0144] Figure 13 illustrates how a station configures a TXOP considering a limited service period according to an embodiment of the present invention.

[0145] A station that obtains a TXOP before the restricted service period begins, i.e., a TXOP holder, may need to terminate its TXOP before the restricted service period starts. This is because if the TXOP holder continues to exchange frames after the restricted service period has begun, it could interfere with the transmission of low-latency traffic. In this case, the station may be a non-legacy station. In yet another specific embodiment, the station may be limited to stations that support restricted TWT. That is, stations with the value of the dot11RestrictedTWTOptionImplemented field set to false are not subject to this restriction.

[0146] In a specific example, when a station that is a TXOP holder transmits low-latency traffic, frame exchange may continue even after the restricted service period has begun.

[0147] This document describes specific methods for a station to terminate a TXOP before its limited service period.

[0148] A station can configure a TXOP based on a restricted service period. Specifically, a station can set the end of the TXOP to before the start of the restricted service period. In this case, the station can set the duration of the starting frame that initiates the frame exchange sequence to before the start of the restricted service period. For example, if a station successfully accesses the channel 3m before the start of the restricted service period, the station can set the TXOP to 3ms or earlier. Alternatively, a station may terminate the TXO by sending a CTS-to-Self frame. In this case, the station can send the CTS-to-Self frame at the base transmission rate, 6Mbps, because many legacy stations can receive frames when the station sends them at the base transmission rate.

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

[0150] Furthermore, a station that is not a TXOP holder can deactivate the NAV set before the restricted service period began 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 deactivate the NAV set before the restricted service period began at the start of the restricted service period. However, if the station has completed frame exchange and the remaining duration of the TXOP is less than twice the sum of the time it takes to transmit the CF-End frame and the SIFS, the station does not need to transmit a CF-End frame. In this case, the station can be considered to have deactivated the TXOP at the start of the restricted service period. Specifically, the station can be considered to have deactivated the basic NAV at the start of the restricted service period.

[0151] In other specific embodiments, the stations may be limited to stations participating in a restricted TWT.

[0152] In the embodiment shown in Figure 13, the AP transmits a beacon frame containing a TWT element to signal that a limited service period is being set. In the embodiment shown in Figure 13(a), the station transmits an RTS frame to set the TXOP. At this time, the station sets the value of the Duration field in the RTS frame to before the limited service period begins. The station exchanges frames with the AP and completes the frame exchange before the start of the limited service period. At this time, the station transmits a CTS-to-Self frame as a final step. In the embodiment shown in Figure 13(b), the station transmits an RTS frame to set the TXOP. At this time, the station sets the value of the Duration field in the RTS frame without considering the limited service period. The station exchanges frames with the AP and completes the frame exchange before the start of the limited service period. At this time, the station transmits a CF-end frame as a final step to release the TXOP.

[0153] Conventional wireless LAN operation defines actions that may be transmitted beyond the TXOP limit as exceptions to the TXOP rule. For example, the retransmission of a single MPDU, the transmission of a single MSDU under a Block ack agreement (not included in an A-MSDU or an A-MPDU consisting of two or more MPDUs), and the transmission of control frames and QoS Null frames (not included in an A-MPDU consisting of two or more MPDUs) may be transmitted beyond the TXOP limit. If such exceptions are granted to restricted service periods, the transmission of low-latency traffic may be delayed. Such exceptions to the TXOP limit must not be applied in violation of restricted service periods.

[0154] If the end time of a TXOP and the start time of a restricted service period are within a predetermined time difference, the station can determine that the TXOP was acquired before the start of the restricted service period. The predetermined time difference may be 100us. Furthermore, in other specific embodiments, if the end time of a TXOP is within a restricted service period, the station can determine that the TXOP was acquired before the start of the restricted service period.

[0155] As mentioned above, stations may be required to complete frame replacement before the restricted service period. This means that stations are not permitted to initiate frame replacement if the completion of the frame replacement falls within the restricted service period. In this case, stations may perform fragmentation to complete the frame replacement before the start of the restricted service period.

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

[0157] Figure 14 illustrates the channel access procedure considering the limited service period.

[0158] Figure 14 shows that a station according to an embodiment of the present invention performs the channel access procedure again, taking into account a limited service period.

[0159] As mentioned above, even if a station completes channel access before the restricted service period, if the frame exchange is completed after the restricted service period has started, the station can restart the channel access procedure without transmitting. At this time, the station can obtain the backoff counter value again. At this time, the station can use the same CW size used in the previous channel access procedure. In other words, the station does not need to double the CW size used in the previous channel access procedure or initialize it to the minimum value that the CW can have. Also, the station does not need to increase the number of retries, such as the QSRC (QoS STA Retry Counter).

[0160] Furthermore, if a station completes channel access within a predetermined time frame from the start of a restricted service period, the station may restart the channel access procedure without transmitting.

[0161] In the above embodiment, a station attempting to transmit low-latency traffic may begin frame exchange after channel access is complete, even if the frame exchange completion time is after the start of the restricted service period. Such an exception may only be permitted if the station attempting to transmit low-latency traffic is a station participating in a restricted TWT.

[0162] Furthermore, as mentioned above, the station can operate in such a way that NAV is set for AC of traffic other than low-latency traffic. Therefore, the station can determine that the CCA result for transmitting AC of traffic other than low-latency traffic is not idle (busy).

[0163] In the embodiment shown in Figure 14, the AP transmits a beacon frame containing a TWT element to signal that a restricted service period is being set. The station's channel access backoff counter value reaches 0 before the restricted service period begins. The station determines that the completion of the frame exchange containing the traffic it intends to transmit occurs after the start of the service period. Therefore, the station obtains a backoff counter within the CW value used in the previous channel access procedure. The station then performs the channel access procedure again using the obtained backoff counter. At this time, the station does not increment the retransmission counter.

[0164] It is possible that all low-latency traffic transmissions are completed before the restricted service period ends. In such cases, restricting the transmission of traffic other than low-latency traffic due to the low-latency service period can be inefficient. Therefore, a method for terminating the restricted service period early may be necessary. This will be explained using the example shown in Figure 15.

[0165] Figure 15 shows the operation by which an AP terminates a limited service period early according to an embodiment of the present invention.

[0166] For an AP to terminate a restricted service period early, it must be able to determine that all low-latency traffic transmissions from stations participating in the restricted TWT have been completed. To this end, stations participating in the restricted TWT can signal whether or not to transmit additional low-latency traffic in the frames they transmit. Specifically, a station can signal to transmit additional low-latency traffic by setting the value of the More data subfield in the Frame Control field of the frame. In this case, if the value of the More data subfield in the Frame Control field of a frame transmitted during the restricted service period is 1, the More data subfield indicates that additional transmission of low-latency traffic is required, and does not need to indicate whether additional transmission of non-low-latency traffic is required. For example, if a station participating in the restricted TWT does not store low-latency traffic in the transmit buffer and only stores non-low-latency traffic, the station can set the value of the More data subfield in the Frame Control field of the frames it transmits during the restricted service period to 0. An AP may terminate a restricted service period early based on whether stations participating in a restricted TWT have a value of 0 in the More data subfield of the Frame Control field of a frame during the restricted service period. Specifically, if there is no low-latency traffic to send to the AP's transmit buffer and stations participating in a restricted TWT have a value of 0 in the More data subfield of the Frame Control field of a frame during the restricted service period, the AP may terminate the restricted service early.

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

[0168] When a station receives a pre-specified frame that signals the end of a restricted service period, the station can determine that the restricted service period has ended. At this time, the station that received the pre-specified frame can resume channel access without the restrictions that apply to the restricted service period. As mentioned above, the pre-specified frame may be a CF-End frame. In this case, the station can determine that a CF-End frame signals the end of a restricted service period if the value of the TA(BSSID) field of the CF-End frame received by the station during the restricted service period is the MAC address of the AP to which the station is associated.

[0169] As mentioned above, a quiet period may be set for the restricted service period to protect legacy wireless communication terminals from the restricted service period. In this case, the AP can send a CF-End frame to terminate the restricted service period. When the AP sends a CF-End frame, the quiet period set on the legacy station is also released.

[0170] In the embodiment 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).

[0171] When a quiet period is set for a restricted service period, stations participating in a restricted TWT are not permitted to transmit CF-End frames within the restricted service period. In a specific embodiment, stations participating in a restricted TWT are not permitted to transmit CF-End frames in the quiet period corresponding to the restricted service period. This is because if a station participating in a restricted TWT transmits a CF-End frame, the NAV set on the legacy station is deactivated. However, as mentioned above, if the 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.

[0172] In the embodiment shown in Figure 15, the AP transmits a beacon frame containing a TWT element and a Quiet element. Stations supporting the restricted TWT determine that a restricted service period has been set, while stations not supporting the restricted TWT determine that a quiet section has been set. When the AP determines that all low-latency traffic has been transmitted within the restricted service period, it transmits a CF-End frame to terminate the restricted service period early and removes the quiet section set on legacy stations. At this time, stations supporting the restricted TWT determine that the channel access restrictions applied during the restricted service period have been removed. Specifically, as described above, if the embodiment in which NAV is set during the restricted service period is applied, stations supporting the restricted TWT can determine that the NAV for the restricted service period has been removed. Also, stations not supporting the restricted TWT that receive a CF-End frame remove the NAV.

[0173] As mentioned above, each station included in a multilink device can form associations with other stations. Therefore, each station included in a multilink device can operate its own TWT service period. In other words, a separate TWT service period may be operated on each of the multiple links on which the multilink device operates. For such separate TWT service periods to be operated, a separate TWT agreement may be required. To this end, a station in the multilink device can send a TWT request frame, and a station that receives a TWT request frame can send a TWT response frame. The TWT request frame may be a frame in which the Command field of the TWT setup frame has a value between 0 and 2. The TWT response frame may be a frame in which the Command field of the TWT setup frame has a value between 3 and 7. The specific TWT agreement method may be the same as that defined in IEEE 802.11ax.

[0174] TWT operation allows stations to perform power saving. Therefore, to improve power saving efficiency, a multilink device can set TWT service periods on multiple links on which the multilink device operates. For example, a multilink device including a first station and a second station can set TWT service periods on the first link on which the first station operates and on the second link on which the second station operates, and synchronize the operating states (awake state, power saving (doze) state) of the first and second stations. In this case, the first station can send a TWT request frame to the first AP to which the first station is connected, and the second station can send a TWT request frame to the second AP to which the second station is connected. At this time, the TWT parameter values ​​indicated in the TWT request frame sent by the first station and the TWT request frame sent by the second station may be the same. Therefore, sending TWT request frames individually on multiple links may reduce transmission efficiency. In a specific embodiment of the present invention, a TWT request frame sent on one link can establish TWT agreement for multiple links. This will be explained using Figure 16.

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

[0176] A TWT request frame for TWT agreement performed on multiple links may be transmitted on the first link. In this case, the TWT request frame may include TWT parameters for TWT operations performed on multiple links. Similarly, a TWT request frame for TWT agreement performed on the second link may be transmitted on 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 multilink device includes a first station operating on the first link and a second station operating on the second link, the first station can establish a TWT agreement for the second station. In this case, the first station can establish a TWT agreement with the first AP if the first station is coupled with the first AP, the second station is coupled with the second AP, and the first AP and the second AP are included in a single multilink device. This is because stations included in a multilink device can share some functions or some information of the MAC layer. A new format of TWT elements may be required for the aforementioned TWT agreement operations.

[0177] Specifically, a TWT element may include information about the link on which the TWT agreement is to be made. In this case, the link information may be information about the ID of the link operated by the AP. In a specific embodiment, a TWT element can indicate multiple links on which the TWT agreement is to be made. For example, the link information may be a bitmap. In this case, each bit of the bitmap may indicate whether or not a TWT element is to be made on each of the multiple links. A station can transmit such a TWT element to make a TWT agreement on multiple links.

[0178] The bitmap mentioned above can be called a Link ID (identifier) ​​bitmap. The size of the Link ID bitmap may be 2 octets. For example, if the value of the Link ID bitmap is 1110 0000 0000 0000 2bIn this case, the Link ID bitmap can indicate that the TWT negotiation is for the first link corresponding to the first bit, the second link corresponding to the second bit, and the third link corresponding to the third bit. In such an embodiment, a link element containing information about TWT parameters only for links other than the link to which the link element is transmitted may be transmitted. Also in such an embodiment, an element may be transmitted for a TWT agreement to take place on multiple links in a single link.

[0179] Furthermore, a TWT element may include a TWT flow ID that indicates an identifier applicable to the TWT agreement. When a TWT element is used to perform a TWT agreement across multiple links, the TWT flow ID included in the TWT element may be a value that is not used in the TWT agreements of all links for which the TWT element can perform a TWT agreement. In other specific embodiments, when a TWT element is used to perform a TWT agreement across multiple links, the TWT element may include fields for indicating multiple TWT flow IDs. For example, when a TWT element is used to perform a TWT agreement across multiple links, the TWT element may include multiple subfields, each indicating a different TWT flow ID. In this case, the multiple subfields may correspond to each of the multiple links for which the TWT element can perform a TWT agreement. In these embodiments, each subfield may use a TWT flow ID that is not used by the corresponding link. Also, when a TWT element attempts to modify the TWT agreement of a link corresponding to a subfield, the TWT flow ID that the link corresponding to the subfield has already used may be used in the subfield. This is because there is an existing TWT agreement for which the TWT flow ID was used. Therefore, when a station attempts to enter into a new TWT agreement, it may be restricted to using a TWT flow ID that does not correspond to a TWT flow ID of an existing TWT agreement. In this case, when a station attempts to modify an existing TWT agreement, it may use a TWT flow ID that corresponds to the TWT agreement it intends to modify.

[0180] Figure 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.

[0181] Figure 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. Figure 16(b) further includes the Link ID Bitmap Present field compared to the TWT element defined in IEEE 802.11ax. In this case, the Link ID Bitmap Present field indicates whether or not the TWT element includes the aforementioned Link ID bitmap. Specifically, if the value of the Link ID Bitmap Present field is 1, the TWT element includes the Link ID bitmap, and if the value of the Link ID Bitmap Present field is 0, the TWT element does not need to include the Link ID bitmap. A station receiving a TWT element can determine whether or not the TWT element includes the Link ID bitmap based on the value of the Link ID Bitmap Present field.

[0182] Figure 16(c) shows the format of the Individual TWT Parameter Set field included in a TWT element. The Individual TWT Parameter Set field included in a TWT element may include the Request Type field, Target Wake Time field, TWT Group Assignment field, Nominal Minimum TWT wake Duration field, TWT Wake Interval Mantissa field, TWT Channel field, NDP Paging field, and Link ID Bitmap field. Figure 16(b) shows the Individual TWT Parameter Set field as defined in IEEE 802.11ax, with the addition of the Link ID Bitmap field. When a TWT element includes the Link ID Bitmap field, the TWT element can indicate that it is requesting a TWT Request for the link indicated by the Link ID Bitmap field. When a TWT request frame includes a TWT element, and the TWT element includes the Link ID Bitmap field, the station receiving the TWT request frame can determine that the TWT request frame is requesting a TWT agreement for the link indicated by the Link ID Bitmap field.

[0183] Figure 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 agreement performed by the TWT request frame containing the TWT element. In this case, the TWT Flow ID may be set according to the embodiment described above.

[0184] Figure 17 shows that a multilink device according to an embodiment of the present invention performs TWT agreement.

[0185] An AP multilink device includes a first AP (AP1), a second AP (AP2), and a third AP (AP3). A non-AP multilink device includes a first station (STA1), a second station (STA2), and a third station (STA3). Each of the first AP (AP1), second AP (AP2), and third AP (AP3) operates on the first link (Link1), second link (Link2), and third link (Link3). Each of the first station (STA1), second station (STA2), and third station (STA3) operates on the first link (Link1), second link (Link2), and third link (Link3). A non-AP multilink device can send a TWT request frame to establish a TWT agreement on the first link (Link1) through the third link (Link3). In this case, the TWT request frame may contain one TWT element. Specifically, when a non-AP multilink device intends to operate a TWT service period in which the same TWT parameters are used, the TWT request frame may contain one TWT element.

[0186] Specifically, the TWT element can indicate the start and end times of the TWT service period. The TWT element may also include a Link ID bitmap, as explained using Figure 16. Specifically, the TWT element can indicate the first link (Link1), the second link (Link2), and the third link (Link3) in its Link ID Bitmap subfield.

[0187] The AP multilink device can determine that the TWT parameters signaled by the TWT request frame relate to the TWT service periods of the first link (Link1), second link (Link2), and third link (Link3), because the Link ID Bitmap subfield of the TWT element in the received TWT request frame indicates the first link (Link1), second link (Link2), and third link (Link3).

[0188] An AP multilink device can accept a TWT setup by sending a TWT response frame to a non-AP multilink device. At this time, a TWT agreement is established for each of the first links (Link1) to the third link (Link3). In this case, the TWT agreements on 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).

[0189] Figure 18 shows an embodiment of the present invention in which a station included in a multilink device performs TWT agreement for other stations included in the multilink device that includes the station.

[0190] As mentioned above, a TWT request frame for TWT agreement to take place on the second link may be transmitted on the first link. To this end, a first station operating on the first link can transmit a TWT request frame on the first link. In this case, the TWT element of the TWT request frame includes a TWT Link ID bitmap, which can indicate the second link. A first AP operating on the first link can determine, based on the TWT Link ID bitmap, that the TWT request frame was transmitted for TWT agreement on the second link.

[0191] In the embodiment shown in Figure 18, the AP multilink device includes a first AP (AP1) and a second AP (AP2). The non-AP multilink device includes a first station (STA1) and a second station (STA2). Each of the first AP (AP1) and the second AP (AP2) operates on the first link (Link1) and the second link (Link2). Each of the first station (STA1) and the second station (STA2) operates on the first link (Link1) and the second link (Link2). The first station (STA1) transmits a TWT request frame on the first link (Link1) for TWT agreement on the second link (Link2). The first AP (AP1) accepts the TWT agreement on the second link (Link2) by transmitting a TWT response frame to the first station (STA1). This establishes a TWT agreement between the second station (STA2) and the second AP (AP2).

[0192] In this case, the station that sent the TWT request frame and the station to which the TWT agreement applies are different. Also, as mentioned above, although only one station sent the TWT request frame, the TWT agreement may apply to multiple stations. Therefore, the station that can terminate the TWT agreement may become an issue.

[0193] In existing TWT operations, a 3-bit TWT Flow ID and the MAC addresses of the two stations that entered into the TWT agreement may be used to identify a TWT agreement. Specifically, a TWT agreement could be identified by the MAC address of the TWT requesting station, the MAC address of the TWT response station, and the TWT Flow ID. However, as mentioned above, TWT agreements set up by a multilink device may be difficult to identify because the station that made the TWT agreement and the station to which the TWT agreement applies may be different. For example, in the embodiments shown in Figures 17 and 18, the TWT requesting station is Station 1, and the TWT response station is AP 1. However, in the embodiment of Figure 17, the TWT agreement applies to Station 1 and AP 1, Station 2 and AP 2, and Station 3 and AP 3. In the embodiment of Figure 18, the TWT agreement applies to Station 2 and AP 2. Furthermore, in the embodiment shown in Figure 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 agreements cannot be identified. To solve this problem, the following embodiment can be applied.

[0194] A station that can terminate a TWT agreement may be any station to which the TWT agreement applies. For this reason, a TWT requesting station may be any station operating on a link to which the TWT agreement applies, rather than the station that sent the TWT requesting frame. Specifically, a TWT requesting station may be any station in the multilink device that sent the TWT requesting frame that operates on a link to which the TWT agreement applies. Similarly, a TWT response station may be any station operating on a link to which the TWT agreement applies, rather than the station that sent the TWT response frame. Specifically, a TWT response station may be any station in the multilink device that sent the TWT response frame that operates on a link to which the TWT agreement applies.

[0195] Furthermore, the following embodiments may be applied as methods for identifying TWT agreements.

[0196] In a specific embodiment, a TWT agreement may be identified based on the link ID. Specifically, a TWT agreement may be identified based on the TWT Flow ID, the MAC address of the TWT requesting station, the MAC address of the TWT response station, and the ID of the link to which the TWT agreement applies. In the embodiment shown in Figure 17, the first TWT agreement, which is a TWT agreement established between the first station and the first AP, may 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 agreement, which is a TWT agreement established between the second station and the second AP, may 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 agreement, which is a TWT agreement established between the third station and the third AP, may 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. In a specific embodiment, the TWT Flow ID may be set separately for each link.

[0197] Furthermore, TWT agreements may be considered to have been made separately for each multilink device. Therefore, to identify a TWT agreement, the MAC address of the TWT requesting multilink device may be used instead of the MAC address of the TWT requesting station, and the MAC address of the TWT replying multilink device may be used instead of the MAC address of the TWT replying station. In the embodiment shown in Figure 17, the first TWT agreement, which is a TWT agreement set up between the first station and the first AP, may be identified by the TWT Flow ID, the MAC address of the non-AP multilink device, the MAC address of the AP multilink device, and the ID of the first link. The second TWT agreement, which is a TWT agreement set up between the second station and the second AP, may be identified by the TWT Flow ID, the MAC address of the non-AP multilink device, the MAC address of the AP multilink device, and the ID of the second link. The third TWT agreement, which is a TWT agreement set up between the third station and the third AP, may be identified by the TWT Flow ID, the MAC address of the non-AP multilink device, the MAC address of the AP multilink device, and the ID of the third link. Depending on the specific embodiment, the TWT Flow ID may be set separately for each link. Depending on the specific implementation, the TWT Flow ID may be set for each link.

[0198] Furthermore, the TWT request station may be a station operating on the link to which the TWT agreement applies, rather than the station that sent the TWT request frame. Specifically, the TWT request station may be a station among the stations of the multilink device that sent the TWT request frame, operating on the link to which the TWT agreement applies. Similarly, the TWT response station may be a station operating on the link to which the TWT agreement applies, rather than the station that sent the TWT response frame. Specifically, the TWT response station may be a station among the stations of the multilink device that sent the TWT response frame, operating on the link to which the TWT agreement applies. In the embodiment shown in Figure 17, the first TWT agreement, which is a TWT agreement established between the first station and the first AP, may 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 agreement, which is a TWT agreement established between the second station and the second AP, may 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, may be identified by the TWT Flow ID, the MAC address of the third station, and the MAC address of the third AP. In specific embodiments, the TWT Flow ID may be set for each link.

[0199] Furthermore, TWT agreements may be identified based on the link from which the TWT request frame is sent. Specifically, a TWT agreement may be identified based on the TWT Flow ID, the MAC address of the TWT requesting station, the MAC address of the TWT response station, and the ID of the link from which the TWT request frame is sent. In the embodiment shown in Figure 17, the first TWT agreement, which is a TWT agreement established between the first station and the first AP, may 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 agreement, which is a TWT agreement established between the second station and the second AP, may 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 agreement, which is a TWT agreement established between the third station and the third AP, may 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. In specific embodiments, the TWT Flow ID may be set separately for each link.

[0200] The above explains how a multilink device establishes a TWT agreement. Figure 19 illustrates how a multilink device can terminate (teardown) a TWT agreement.

[0201] Figure 19 shows the operation of a multilink device according to an embodiment of the present invention to release the TWT agreement.

[0202] In an embodiment of the present invention, a multilink device can terminate TWT agreements applied to multiple links using a single link. In a conventional wireless LAN, a station transmits a TWT termination frame to terminate a TWT agreement. The TWT termination frame can be transmitted by a TWT requesting station or a TWT response station. The TWT termination frame includes a TWT Flow Identifier field indicating the TWT Flow ID. The TWT Flow Identifier field may be a 3-bit field. When a station to which a TWT agreement applies receives a TWT termination frame, the station can terminate the TWT agreement corresponding to the TWT Flow ID indicated by the TWT termination frame. If the TWT termination frame is transmitted successfully, the station that transmitted the TWT termination frame can terminate the TWT agreement corresponding to the TWT Flow ID indicated by the TWT termination frame. Therefore, the station terminating the TWT agreement and the TWT agreement to be terminated may be identified based on the MAC address of the sender of the TWT termination frame, the MAC address of the receiver of the TWT termination frame, and the TWT Flow ID.

[0203] However, as mentioned above, when a TWT agreement is established at a station in a multilink device, the station that sent the TWT request frame and the station to which the TWT agreement applies may be different. Also, as mentioned above, although only one station sends the TWT request frame, the TWT agreement may apply to multiple stations. Therefore, a method for terminating a TWT agreement that can be applied in such cases is necessary.

[0204] A TWT release frame may include information about a link identifier. In this case, a station in a multilink device can release at least one of several TWT agreements based on the link identifier, e.g., link ID, indicated by the TWT release frame. Specifically, if a station in a multilink device is operating on a first link and the station releases a TWT agreement made on a second link, the station can send a TWT release frame containing information about the link identifier on the first link. In these embodiments, the link identifier may be the identifier of the link to which the released TWT agreement applies. For example, a TWT release frame may include a TWT Flow Identifier field indicating the TWT Flow ID and a Link ID field indicating the identifier of the link to which the released TWT agreement applies. Alternatively, a TWT release frame may include one Link ID field. Alternatively, a TWT release frame may include multiple Link ID fields. For this reason, the format of a TWT release frame sent by a station included in a multilink device may differ from the format of a TWT release frame sent by a station not included in a multilink device. In other specific embodiments, the format of the TWT deactivation frame transmitted by a station included in the multilink device may be the same as the format of the TWT deactivation frame transmitted by a station not included in the multilink device.

[0205] When the first multilink device transmits a TWT release frame to the second multilink device on the first link, and the second multilink device successfully receives the TWT release frame, the first and second multilink devices can release the TWT agreement established between them that corresponds to the TWT Flow ID indicated by the TWT release frame. At this time, the first and second multilink devices can release the TWT agreement established between them that corresponds to the link-related information indicated by the TWT release frame. Specifically, the first and second multilink devices can release the TWT agreement established between them that corresponds to the TWT Flow ID indicated by the TWT release frame and the link-related information indicated by the TWT release frame.

[0206] In yet another specific embodiment, if the first multilink device transmits a TWT deactivation frame to the second multilink device over the first link and the second multilink device successfully receives the TWT deactivation frame, the first and second multilink devices can deactivate the TWT agreement established between them that corresponds to the MAC address of the station that transmitted the TWT deactivation frame and the MAC address of the station that received the TWT deactivation frame. In yet another specific embodiment, if the first multilink device transmits a TWT deactivation frame to the second multilink device over the first link and the second multilink device successfully receives the TWT deactivation frame, the first and second multilink devices can deactivate the TWT agreement established between them that corresponds to the MAC address of the station that entered into the TWT agreement and the MAC address of the station that entered into the TWT agreement. In yet another specific embodiment, the station that received the TWT deactivation frame and the station that sent the TWT deactivation frame can deactivate the TWT agreement corresponding to the TWT Flow ID indicated by the TWT deactivation frame within the link on which the stations are operating.

[0207] Furthermore, when a TWT agreement is established on multiple links by a single TWT element, the TWT agreement established on multiple links may be canceled by a single TWT cancellation frame. In this case, the TWT parameters of the TWT agreements established on multiple links may be identical to each other. Also, the TWT Flow IDs of the TWT agreements established on multiple links may be identical to each other. For example, if a TWT agreement is established simultaneously between a first multilink device and a second multilink device, for example, by a single TWT element, the first or second multilink device can send a TWT cancellation frame on any one of the first to third links to cancel the TWT agreement established on the first to third links.

[0208] An AP multilink system includes a first AP (AP1), a second AP (AP2), and a third AP (AP3). A Non-AP multilink system 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), second AP (AP2), and third AP (AP3) operates on the first link (Link1), second link (Link2), and third link (Link3). Each of the first station (non-AP STA1), second station (non-AP STA2), and third station (non-AP STA3) operates on the first link (Link1), second link (Link2), and third link (Link3). The first station (non-AP STA1) is connected to the first AP (AP1), the second station (non-AP STA2) is connected to the second AP (AP2), and the third station (non-AP STA3) is connected to the third AP (AP3). A TWT agreement is established between the first station (non-AP STA1) and the first AP (AP1), and the TWT Flow ID of this agreement is x. A TWT agreement is established between the second station (non-AP STA2) and the second AP (AP2), and the TWT Flow ID of this agreement is y. A TWT agreement is established between the third station (non-AP STA3) and the third AP (AP3), and the TWT Flow ID of this agreement is z.

[0209] At this time, the non-AP multilink device transmits a TWT release frame to release the TWT agreement between the first station (non-AP STA1) and the first AP (AP1), and between the third station (non-AP STA3) and the third AP (AP3). At this time, the TWT release frame 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).

[0210] The AP multilink device sends an ACK to the non-AP multilink device for the TWT release frame. The AP multilink device then releases the TWT agreement between the first station (non-AP STA1) and the first AP (AP1), and between the third station (non-AP STA3) and the third AP (AP3). The non-AP multilink device receives an ACK for the TWT release frame. The non-AP multilink device then releases the TWT agreement between the first station (non-AP STA1) and the first AP (AP1), and between the third station (non-AP STA3) and the third AP (AP3).

[0211] The TWT elements for setting and releasing TWT agreements, as described in the above-mentioned examples, will be explained using Figure 20.

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

[0213] The Request Type field of the Individual TWT parameter set field of a TWT element includes the TWT Request subfield (1 bit field), the TWT Setup Command subfield (3 bit fields), the Trigger subfield (1 bit field), the Implicit subfield (1 bit field), the Flow Type subfield (1 bit field), the TWT Flow Identifier subfield (3 bit fields), the TWT Wake Interval Exponent subfield (5 bit fields), and the TWT Protection subfield (1 bit field).

[0214] When the value of the TWT Request subfield is 1, the station sending the TWT element may be a TWT request station or a TWT scheduled station. When the value of the TWT Request subfield is 0, the station sending the TWT element may be a TWT response station or a TWT scheduling AP.

[0215] The TWT Setup Command subfield can indicate the type of TWT command. The value of the TWT Setup Command subfield may be set to 0 to 7. When the value of the TWT Setup Command subfield is between 0 and 7, the TWT Setup Command subfield can 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, or Reject TWT. This may be the same as the conventional setting of the TWT Setup Command subfield.

[0216] When the value of the Trigger subfield is 1, the Trigger subfield can indicate that one or more trigger frames will be sent to the TWT service period when a TWT agreement is established by a TWT element.

[0217] The Implicit subfield indicates whether the TWT element requests an implicit TWT. A value of 1 in the Implicit subfield indicates that the TWT element requests an implicit TWT. A value of 0 in the Implicit subfield indicates that the TWT element requests an explicit TWT.

[0218] The Flow Type subfield indicates the interaction method between TWT request stations and TWT response stations within a TWT service period. The value of the Flow Type subfield may be set to be the same as the value of the Flow Type subfield defined in conventional wireless LAN standards.

[0219] The TWT Flow Identifier subfield indicates an ID value for distinguishing TWT agreements. In conventional wireless LAN standards, a TWT element contains only one TWT Flow Identifier subfield. However, as mentioned above, when a single TWT element establishes TWT agreements for multiple links, the TWT element may contain multiple TWT Flow Identifier subfields. In this case, each of the multiple TWT Flow Identifier subfields can indicate the TWT Flow ID of the TWT agreement established for each of the links.

[0220] 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 a predicted value. The value of the TWT wake interval subfield may be set to the same value as defined in conventional wireless LAN standards.

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

[0222] 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 in the Individual TWT Parameter Set field may be set to the same values ​​as defined in conventional wireless LAN standards.

[0223] The Individual TWT Parameter Set field may include a Link ID Bitmap subfield, as illustrated in the embodiment shown in Figure 16. When the Link ID Bitmap subfield indicates multiple links, the TWT element can request TWT agreement for multiple links. In this case, if TWT agreement is reached for multiple links, a TWT service period with the same TWT parameters may be applied to each of the links.

[0224] Furthermore, even if a single TWT element sets up TWT agreements for multiple links, the multiple TWT agreements set up for those links may have different TWT Flow IDs. This is because even if TWT agreements are set up at once, they apply to different links and to different stations and APs. A TWT element may contain multiple TWT Flow Identifier fields. Specifically, a TWT element may contain multiple TWT Flow Identifier fields corresponding to each of the multiple links to which the TWT agreement applies. In this case, the number of TWT Flow Identifier fields contained in the TWT element may be the same as the number of links indicated by the Link ID Bitmap subfield. For example, if the Link ID Bitmap subfield indicates two links, a TWT element containing the Link ID Bitmap subfield may contain two TWT Flow Identifier fields. Of the multiple TWT Flow Identifier fields contained in the TWT element, the first TWT Flow Identifier subfield may be the TWT Flow ID contained in the Request Type field. The remaining subfields, other than the first TWT Flow Identifier subfield, may be included in other fields of the TWT element, such as the Additional TWT Flow ID field in Figure 20. The first TWT Flow Identifier subfield can also indicate the TWT Flow ID of the TWT agreement established on the link to which the TWT request frame is sent. The remaining TWT Flow Identifier subfields, other than the first TWT Flow Identifier subfield, can also indicate the TWT Flow ID of the TWT agreement established on the remaining links to which the TWT agreement is established, other than the link to which the TWT request frame is sent. As mentioned above, the remaining links to which the TWT agreement is established, other than the link to which the TWT request frame is sent, may be indicated by the Link ID Bitmap subfield.Additionally, the remaining TWT Flow Identifier subfields, excluding the first TWT Flow Identifier subfield, may be mapped to links in order of the size of their Link ID values. Of the remaining TWT Flow Identifier subfields, the first subfield may be mapped to the link with the smallest Link ID value among the remaining links other than the link to which the TWT request frame is sent; the second subfield may be mapped to the link with the second smallest Link ID value among the remaining links other than the link to which the TWT request frame is sent; and the third subfield may be mapped to the link with the third smallest Link ID value among the remaining links other than the link to which the TWT request frame is sent.

[0225] If a TWT element requests only one TWT agreement, it does not need to include any of the remaining TWT Flow Identifier subfields except for the first TWT Flow Identifier subfield. If a TWT element requests only one TWT agreement on a link other than the link to which the TWT request frame is sent, it does not need to include any of the remaining TWT Flow Identifier subfields except for the first TWT Flow Identifier subfield. In this case, the first TWT Flow Identifier subfield can indicate the TWT Flow ID corresponding to the TWT agreement requested by the TWT request frame.

[0226] Figure 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.

[0227] As mentioned above, the size of the Additional TWT Flow ID field may be determined by the number of links indicated by the Link ID bitmap of the TWT element. In a conventional wireless LAN, the maximum number of TWT agreements that a station can establish is 8. Therefore, in a conventional wireless LAN, the TWT Flow Identifier subfield is a 3-bit field. When the maximum number of TWT agreements that a multilink device can establish is 8, the TWT Flow Identifier subfield may be a 3-bit field. Also, the Additional TWT Flow ID field may contain one or more subfields having a size of 3 bits. When a TWT element requests n TWT agreements, the Additional TWT Flow ID field may contain n-1 3-bit subfields. In this case, as mentioned above, the first TWT Flow Identifier subfield may be the TWT Flow ID included in the Request Type field. Furthermore, in other specific embodiments, when a TWT element requests n TWT agreements, the Additional TWT Flow ID field may contain n 3-bit subfields. Furthermore, the Additional TWT Flow ID field may include a reserved field so that the TWT Parameter Set field has a length in octets. An example of this is shown in Figure 21(a).

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

[0229] Furthermore, 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 to the Reserved field. An example of this is shown in Figure 22(b).

[0230] In the previously described embodiment, the size of the TWT Flow ID subfield was assumed to be 3 bits, but the above embodiment may also be applied when the size of the TWT Flow ID subfield is 4 bits.

[0231] As mentioned earlier, a single TWT element can request TWT agreement across multiple links. Therefore, additional information needs to be transmitted. This will be explained using Figure 22.

[0232] Figure 22 shows the format of the Control field included in the TWT element transmitted by the multilink device according to an embodiment of the present invention.

[0233] When a single TWT element requests TWT agreement across multiple links, the additional information required may include a Link ID bitmap, which indicates the links on which the TWT agreement is taking place, and an Additional TWT Flow Identifier field, which is the TWT Flow ID corresponding to the TWT agreement. However, when a station in a multilink device sends a TWT request frame to a station to which it is connected, the TWT element included in the TWT request frame does not need to include such additional information. The TWT element may include a field indicating whether or not it contains the Link ID Bitmap field and the Additional TWT Flow Identifier field. A station receiving the TWT element can determine the format of the TWT element based on the field indicating whether or not it contains the Link ID Bitmap field and the Additional TWT Flow Identifier field.

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

[0235] If a TWT element sent by a TWT request station includes an Additional TWT Flow ID subfield, the TWT request station can 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, a TWT response station that receives the TWT element can determine that the TWT element includes an Additional TWT Flow ID subfield and is intended to establish a TWT agreement across multiple links.

[0236] In other specific embodiments, 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 contains the Additional TWT Flow ID subfield based on the Link ID Bitmap subfield. The TWT response station that receives the TWT element can also determine the size of the Additional TWT Flow ID subfield contained in the TWT element based on the Link ID Bitmap subfield.

[0237] As mentioned above, a multilink device can send a TWT release frame on the first link to release a TWT agreement that applies to the second link. Furthermore, a multilink device can send a TWT release frame to one link to release a TWT agreement that applies to multiple links.

[0238] Similarly, TWT decryption frames may also include additional information compared to conventional wireless LAN TWT decryption frames. This will be explained using Figure 23.

[0239] Figure 23 shows the format of the Action field of a TWT release frame transmitted by a multilink device according to an embodiment of the present invention.

[0240] The TWT release frame transmitted by the multilink device may be defined as a new action frame. For convenience of explanation, the TWT release frame transmitted by the multilink device will be called an MLD TWT release frame. The MLD TWT release frame may be designated as Unprotected S1G in the Action field category. Among the values ​​of the Action field of Unprotected S1G, a value not used in conventional wireless LANs may be assigned to the MLD TWT release frame. For example, as in the embodiment shown in Figure 23(a), 12 may be assigned to the MLD TWT release frame. In this case, when a station intends to transmit an MLD TWT release frame, the station can set the category value in the action frame to 22 and the value of the Unprotected S1G Action field to 12.

[0241] Furthermore, the Action field of the MLD TWT release frame may include a field that indicates the TWT agreement that the TWT release frame intends to release. This field can be called the MLD TWT Flow field. The MLD TWT Flow field can indicate the link ID of the link corresponding to the TWT agreement that the TWT release frame intends to release, and the TWT Flow ID corresponding to the TWT agreement that the TWT release frame intends to release. Figure 23(b) shows an example of an Action field included in a TWT release frame.

[0242] The MLD TWT Flow field may 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 may be sent in the Protected Action frame format 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.

[0243] The TWT release frame may be used in a different format 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 with reference to Figure 24.

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

[0245] The MLD TWT Flow field may include a field of variable length. Specifically, the MLD TWT Flow field may include a variable-length field that indicates the TWT Flow ID corresponding to the TWT agreement that the MLD TWT release frame is trying to release. In a specific embodiment, the MLD TWT Flow field may include a fixed-length MLD TWT Flow Control field and a variable-length MLD TWT Flow IDs field. The MLD TWT Flow Control field may be a one-octet field. The MLD TWT Flow Control field can also indicate information for parsing the MLD TWT Flow IDs field. Specifically, the MLD TWT Control field can indicate information regarding the size of the MLD TWT Flow IDs field. The MLD TWT Flow IDs field can indicate the TWT Flow ID corresponding to the TWT agreement that is trying to release. The MLD TWT Flow IDs field may also be omitted depending on the setting of the MLD TWT Flow Control field. An MLD TWT Flow field according to such an embodiment is shown in Figure 24(a).

[0246] The MLD TWT Flow Control field may include a field that indicates the length of the MLD TWT Flow IDs field. In this case, this field may be called the Length of MLD Flow IDs field. The Length of MLD Flow IDs field can 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 5 octets, the value of the Length of MLD Flow IDs field may be set to 5 or 4. An MLD TWT Flow field according to such an embodiment is shown in Figure 24(b).

[0247] The TWT Flow Control field may also include a subfield indicating an attempt to terminate all TWT agreements established between the multilink device sending the MLD TWT termination frame and the multilink device receiving the MLD TWT termination frame. Such a subfield is called the Teardown All TWT of All Link field. When a multilink device attempts to terminate all TWT agreements established with the recipient of an MLD TWT termination frame, it can set the value of the Teardown All TWT of All Link subfield of the MLD TWT termination frame to 1. If an MLD TWT termination frame with the Teardown All TWT of All Link subfield set to 1 is successfully received, all TWT agreements established between the multilink device sending the MLD TWT termination frame and the multilink device receiving the MLD TWT termination frame are terminated. When the Teardown All TWT of All Link subfield is 1, the Length of MLD Flow IDs field may be set to the Reserved field. Therefore, when the Teardown All TWT of All Link subfield is 1, the MLD TWT Flow field does not need to include MLD TWT Flow IDs. A TWT Flow Control field according to such an embodiment is shown in Figure 24(b).

[0248] The MLD TWT Flow IDs field may contain, for each octet, a repeating 3-bit TWT Identifier subfield, a 4-bit Link ID field, and a 1-bit Teardown All TWT subfield. In this case, the consecutive TWT Identifier subfield and Link ID field can identify the TWT agreement released by the MLD TWT release frame. An MLD TWT Flow IDs field according to such an embodiment is shown in Figure 24(c).

[0249] Furthermore, the Teardown All TWT subfield can indicate that all TWT agreements associated with the link corresponding to the Teardown All TWT subfield will be terminated. In this case, the link corresponding to the Teardown All TWT subfield is the link corresponding to the Link Id field, which is included in the same octet as the Teardown All TWT subfield. Also, if the value of the Teardown All TWT subfield is 1, the TWT Identifier subfield may be set as a reserved field. The MLD TWT Flow IDs field relating to such an embodiment is shown in Figure 24(e).

[0250] In another specific embodiment, the Teardown All TWT subfield can indicate that all TWT agreements corresponding to the TWT Flow IDs associated with the Teardown All TWT subfield are terminated. In this case, the links associated with the Teardown All TWT subfield are the TWT Flow IDs associated with the TWT Flow Identifier subfield, which is included in the same octet as the Teardown All TWT subfield. Also, if the value of the Teardown All TWT subfield is 1, the Link ID subfield may be set as a reserved field. The MLD TWT Flow IDs field relating to such an embodiment is shown in Figure 24(f).

[0251] In further specific embodiments, the MLD TWT Flow IDs field may contain a series of TWT Identifier subfields, a series of Link ID fields, and a series of Teardown All TWT subfields. In such embodiments, TWT Identifier subfields and Link ID fields in the same order can identify the TWT agreement released by the MLD TWT release frame. For example, the combination of the first TWT Identifier subfield and the first Link ID field can identify the TWT agreement released by the MLD TWT release frame, and the combination of the second TWT Identifier subfield and the second Link ID field can identify the TWT agreement released by the MLD TWT release frame. At least one of the number of TWT Flow Identifier subfields, Link ID subfields, and Teardown All TWT subfields contained in the MLD TWT Flow IDs field may be proportional to the size of the MLD TWT Flow IDs field. Also, the Teardown All TWT subfield and Link ID field 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. Also, 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.

[0252] In further specific embodiments, the MLD TWT release frame may include a Link ID bitmap for indicating multiple links. This may be in the same format as the Link ID Bitmap field included in the TWT element described above. In addition, the MLD TWT release frame may include a bitmap to signal information for releasing multiple TWT agreements. This will be illustrated with reference to Figure 25.

[0253] Figure 25 shows the format of an MLD TWT Flow field according to yet another embodiment of the present invention.

[0254] As mentioned above, 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 embodiment described in Figure 24. In this case, the length of the MLD TWT Flow Control field may be one octet. Also, 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. The format of the MLD TWT Flow field according to such an embodiment is shown in Figure 25(a).

[0255] The MLD TWT Control field may include a subfield that indicates information related to the size of the MLD TWT Bitmap field. Such a subfield is called the Length of Bitmap subfield. The Length of Bitmap field can specify 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 possible lengths that the MLD TWT Bitmap field may be limited to 8 or less. This is because the number of TWT Flow IDs is 8 or less. The format of the MLD TWT Control field according to such an embodiment is shown in Figure 25(b).

[0256] The MLD TWT Flow Control field may include a subfield indicating an attempt to tear down all TWT agreements established between the multilink device sending the MLD TWT De-tear frame and the multilink device receiving the MLD TWT De-tear frame, as illustrated in Figure 24. Such a subfield is called the Teardown All TWT of All Link field. When a multilink device attempts to tear down all TWT agreements established between itself and the receiver of the MLD TWT De-tear frame, it can set the value of the Teardown All TWT of All Link subfield of the MLD TWT De-tear frame to 1. If an MLD TWT De-tear frame with the Teardown All TWT of All Link subfield set to 1 is successfully received, all TWT agreements established between the multilink device sending the MLD TWT De-tear frame and the multilink device receiving the MLD TWT De-tear frame are undone. 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 does not need to include the TWT Bitmap field. A TWT Flow Control field according to such an embodiment is shown in Figure 25(c).

[0257] The TWT Bitmap field may contain, repeating every three octets, a one-octet TWT Flow ID Bitmap subfield and a two-octet Link ID Bitmap subfield. A TWT Bitmap field according to such an embodiment is shown in Figure 25(d). The TWT Flow ID Bitmap subfield can indicate the TWT Flow ID corresponding to the TWT agreement that the TWT release frame is trying to release. When an MLD TWT release frame releases a TWT agreement where the TWT Flow ID is 1 to 3, the TWT Flow ID Bitmap subfield is 1110 0000 2b It may be set to this. In this case, each of the TWT Flow ID values ​​1 to 8 is mapped to the first to eighth bits of the TWT Flow ID Bitmap subfield. The Link ID Bitmap subfield can also indicate the Link ID of the link corresponding to the TWT agreement that the TWT release frame is trying to release. When the MLD TWT release frame releases a TWT agreement set to a link corresponding to Link ID 1 to 3, the Link ID Bitmap subfield is 1110 0000 2b It may be set as follows. In this case, each of the Link ID values ​​1 to 8 is mapped to the first to eighth bits of the Link ID Bitmap subfield. Also, as mentioned above, the TWT Flow ID may be indicated by 3 bits. Therefore, the TWT Flow ID bitmap can indicate the value of one TWT Flow ID with a 3-bit field. In this case, 5 bits of the TWT Flow ID bitmap subfield may be a reserved field. A TWT Bitmap field according to such an embodiment is shown in Figure 25(e).

[0258] In other specific embodiments, the TWT Bitmap field may include a series of TWT Flow ID Bitmap subfields and a series of Link ID Bitmap subfields. At least one of the lengths of the TWT Flow ID Bitmap subfields and the Link ID Bitmap subfields included in the TWT Bitmap field may be proportional to the size of the TWT Bitmap field.

[0259] The TWT agreement that the TWT release frame attempts to release is the TWT agreement that corresponds to the TWT Flow ID indicated by the TWT Flow ID Bitmap subfield and the Link ID indicated by the Link ID Bitmap subfield.

[0260] The aforementioned MLD TWT deactivation frame is a newly defined frame for deactivating TWT agreements established between multilink devices, rather than the TWT deactivation frame used in conventional wireless LANs. The following describes how to deactivate TWT agreements established between multilink devices using conventional TWT deactivation frames. Specifically, the following methods will be described: 1) how to deactivate all TWT agreements established on the link to which the TWT deactivation frame is sent, 2) how to deactivate all TWT agreements established on a specific link, 3) how to deactivate TWT agreements corresponding to a specific TWT Flow ID on all links, and 4) how to deactivate all TWT agreements set on all links.

[0261] Figure 26 shows a TWT release frame for releasing a TWT agreement established in a multilink device according to an embodiment of the present invention.

[0262] A conventional TWT deactivation frame includes a one-octet-length TWT Flow field. In this TWT Flow field, the first three bits (B0-B2) are the TWT Flow Identifier subfield, which indicates the TWT Flow ID. The fourth and fifth bits (B3-B4) are the Reserved subfield. The sixth and seventh bits (B5-B6) are the Negotiation Type subfield, which indicates the negotiation type. In this case, the sixth to eighth bits (B7) of the TWT Flow field may be set as the Teardown All TWT subfield. The Teardown All TWT subfield can indicate an attempt to deactivate all TWT agreements established between the station sending the TWT deactivation frame and the station receiving the TWT deactivation frame. The format of the TWT Flow field described above may be such that 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 may be set to 0.

[0263] First, we will explain how to cancel all TWT agreements established on the link to which the TWT cancellation frame is sent. To signal that all TWT agreements established on the link to which the TWT cancellation frame is sent should be canceled, the value of the Teardown all TWT subfield (B7) of the TWT cancellation frame may be set to 1 and the value of the Teardown Type subfield (B4) may be set to 0. In this case, the first to fourth bits (B0-B3) of the TWT Flow field may be set as a reserved field. The format of the TWT Flow field according to such an embodiment is shown in Figure 26(a). 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 multilink device that sent and received the TWT cancellation frame containing the TWT Flow field can cancel all TWT agreements established on the link to which the TWT cancellation frame is sent, out of all TWTs established between the two multilink devices.

[0264] This section describes a method for canceling all TWT agreements established on a specific link. To signal the cancellation of all TWT agreements established on a specific link, the value of the Teardown all TWT subfield (B7) of the TWT cancellation frame may be set to 0, and the value of the Teardown Type subfield (B4) may be set to 1. In this case, the first four bits (B0-B3) of the TWT Flow field may be set as a Link ID field indicating the link to which the TWT agreement to be canceled by the TWT cancellation frame corresponds. The format of the TWT Flow field according to such an embodiment is shown in Figure 26(b). 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 multilink device that sent and received the TWT cancellation frame containing the TWT Flow field can cancel all TWT agreements established on the link indicated by the Link ID field.

[0265] This section describes how to cancel TWT agreements corresponding to a specific TWT Flow ID across all links. To signal that TWT agreements corresponding to a specific TWT Flow ID should be canceled across all links, the value of the Teardown all TWT subfield (B7) in the TWT cancellation 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. The format of the TWT Flow field in such an embodiment is shown in Figure 26(c). When the value of the Teardown all TWT subfield in the TWT cancellation frame is 0, the value of the Teardown Type subfield is 0, and the value of the All Link subfield is 1, the multilink device that sent the TWT cancellation frame containing the TWT Flow field and the multilink device that received it can cancel all TWT agreements among the TWT agreements established with both multilink devices that correspond to the TWT Flow ID indicated by the TWT Flow Identifier field.

[0266] This section describes how to cancel all TWT agreements established on all links. To signal the cancellation of all TWT agreements established on all links, the value of the Teardown all TWT subfield (B7) and the Teardown Type subfield (B4) of the TWT cancellation frame may be set to 1. In this case, the TWT Flow fields (B0-B3) may be set as reserved fields. The format of the TWT Flow fields in such an embodiment is shown in Figure 26(d). When the value of the Teardown all TWT subfield and the Teardown Type subfield of the TWT cancellation frame are 1, the multilink device that sent the TWT cancellation frame containing the TWT Flow field and the multilink device that received it can cancel the TWT agreements established between both multilink devices.

[0267] In the embodiment described above, the TWT agreement was terminated by a TWT termination frame. However, the TWT agreement may also be terminated if a TWT termination frame is not sent or received. This is called implicit termination. This will be explained using Figure 27.

[0268] Figure 27 shows that the TWT agreement established between the multilink devices according to an embodiment of the present invention is implicitly terminated.

[0269] When the association between an AP and a non-AP station is released, the TWT agreement established between the AP and the non-AP station may be implicitly released. Also, when the link established between the AP and the non-AP station is deactivated, the TWT agreement established between the AP and the non-AP station may be implicitly released. At this time, the deactivation of the link may include the disappearance of the TID mapped to the link. In the following description, for the sake of convenience of explanation, the case where the association between the AP and the non-AP station is released will be taken up for explanation, but this may also be applied to the case where the link established between the AP and the non-AP station is deactivated.

[0270] As described above, a TWT agreement may be established for a plurality of links by one TWT element. At this time, the TWT Flow IDs of the TWT agreements established for the plurality of links may be the same. Also, the requesting stations of the TWT agreements established for the plurality of links may be the same, and the responding stations of the TWT agreements established for the plurality of links may be the same. For this reason, it is difficult to distinguish the TWT agreements established for the plurality of links from each other, and in some cases, they must be released simultaneously when releasing the TWT agreement. Also, in the conventional wireless LAN standard, when the association between the AP and the non-AP station is released, the AP and the non-AP station implicitly release the TWT agreement established between the AP and the non-AP station. At this time, the information regarding the TWT agreement established between the AP and the non-AP station is deleted.

[0271] When a TWT agreement is established for a plurality of links by one TWT element, the TWT Flow IDs of the TWT agreements established for the plurality of links are the same, and when the TWT requesting station and the TWT responding station are disassociated, all of the plurality of TWT agreements may be implicitly released.

[0272] In yet another specific embodiment, when the first station, which is a station included in the multi-link device, is disconnected from the second station coupled to the first station, the TWT agreement 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 agreement may be inherited by stations operating on links other than the first link among the links on which the multi-link device including the first station operates. At this time, signaling including a Link ID may be performed for inheritance of the TWT agreement. Also, the signaling for inheritance of the TWT agreement may be transmitted in a management frame. Further, such inheritance of the TWT agreement may also be applied when any one station is not coupled to the station coupled to the station. When inheritance of the TWT agreement is performed, the TWT agreement established before inheritance may be released. In the above-described embodiment, TWT agreement inheritance can indicate that the TWT parameters applied to the previously established TWT agreement are applied to the new TWT agreement.

[0273] In the embodiment shown in Figure 27, the non-AP multilink device (non-AP MLD) includes a first station (STA1), a second station (STA2), and a third station (STA3). Each of the first station (STA1), second station (STA2), and third station (STA3) operates on the first link (Link1), second link (Link2), and third link (Link3). The AP multilink device (AP MLD) includes a first AP (AP1), second AP (AP2), and third AP (AP3). Each of the first AP (AP1), second AP (AP2), and third AP (AP3) operates on the first link (Link1), second link (Link2), and third link (Link3). The first station (STA1) and the first AP (AP1) are coupled, establishing a TWT agreement (TWT1, TWT2, TWT3) on the first link (Link1), the second link (Link2), and the third link (Link3). The requesting and responding stations for the TWT agreement (TWT1, TWT2, TWT3) on the first link (Link1), the second link (Link2), and the third link (Link3) are the first station (STA1) and the first AP (AP1). A non-AP multilink device (non-AP MLD) and an AP multilink device (AP MLD) may perform a reassociation procedure, and the first station (STA1) and the first AP (AP1) may be discoupled. All TWT agreements in which the first station (STA1) and the first AP (AP1) are TWT responding stations or TWT requesting stations may be implicitly terminated. Therefore, all TWT agreements (TWT1, TWT2, TWT3) are terminated at Link 1, Link 2, and Link 3.

[0274] Through recombination, the first station (STA1) can operate on another link by being coupled to the fourth AP (AP4), which is a different AP from the first AP (AP1) of the AP multilink device (AP MLD). In this case, the TWT agreement between the first station (STA1) and the first AP (AP1) may be inherited by the first station (STA1) and the fourth AP (AP4). Thus, regardless of the link on which the TWT was initially set up, the TWT agreement may be set up on the new link through TWT agreement inheritance.

[0275] Although the present invention has been described using wireless LAN communication as an example, it is not limited to this and can be applied equally to other communication systems such as cellular communication. Furthermore, although the methods, apparatus, and systems of the present invention have been described in relation to specific embodiments, some or all of the components and operations of the present invention can be embodied by a computer system having a general-purpose hardware architecture.

[0276] The features, structures, and effects described in the examples above are included in at least one embodiment of the present invention, and are not necessarily limited to just one embodiment. Furthermore, the features, structures, and effects exemplified in each embodiment can be combined or modified and implemented in other embodiments by a person with ordinary skill in the art to which the embodiment belongs. Therefore, it should be interpreted that such combinations and modifications are included within the scope of the present invention.

[0277] While the above description has focused on embodiments, these are merely illustrative and do not limit the present invention. Those with ordinary skill in the art to which the present invention pertains will understand that various modifications and applications not exemplified above are possible, without departing from the essential characteristics of these embodiments. For example, each component specifically shown in the embodiments can be modified. Furthermore, any differences related to such modifications and applications should be interpreted as being within the scope of the present invention as defined in the attached claims. [Explanation of symbols]

[0278] 100 stations 110 processors 120 Communications Department 140 User Interface Section 150 display units 160 memory 200 AP 210 processors 220 Communications Department 260 memory 300 servers S101 Beacon Message S103 Probe request S105 Probe response S107a Authentication request S107b Authentication response S109a Association request S109b Association response S111 Authentication Step S113 Steps to acquire an IP address

Claims

1. A multilink device including multiple stations, each operating on multiple links, Transmitting and receiving unit; and Including the processor, The aforementioned processor, A multilink device that is one of several stations, transmits a TWT (target wake time) element from a first station coupled to a first AP on a first link, and requests a TWT agreement for a second station operating on a second link and a second AP coupled to the second station.

2. The multilink device according to claim 1, wherein the TWT element includes a bitmap indicating information indicating the link to which the TWT agreement that the TWT element intends to establish applies.

3. The TWT request station for the TWT agreement for the second station and the second AP is the second station, The multilink apparatus according to claim 1, wherein the TWT response station for the TWT agreement for the second station and the second AP is the second AP.

4. The aforementioned processor, The multilink device according to claim 3, which terminates the TWT agreement for the second station and the second AP when it receives a TWT termination frame from the second AP or when it successfully transmits the TWT termination frame to the second AP.

5. The aforementioned processor, The multilink device according to claim 1, wherein the TWT agreement for the second station and the second AP is terminated without receiving or transmitting a TWT termination frame that terminates the TWT agreement for the second station and the second AP when the second link is deactivated.

6. The multilink device according to claim 1, wherein the TWT element requests a plurality of TWT agreements established on a plurality of links including a second link.

7. The multilink device according to claim 6, wherein each of the multiple TWT agreements established on the multiple links is identified based on the respective link ID of the multiple links.

8. The multilink device according to claim 7, wherein each of the multiple TWT agreements established on the multiple links is identified based on the respective link ID of the multiple links, the MAC (medium access control) address of the multilink device, and the respective TWT Flow ID of the multiple TWT agreements established on the multiple links.

9. The aforementioned processor, The multilink device according to claim 7, which, upon successfully transmitting or receiving a TWT cancellation frame, cancels at least one of a plurality of TWT agreements established on a plurality of links based on the link ID indicated by the TWT cancellation frame.

10. The aforementioned processor, The TWT agreement for the second station and the second AP is terminated, The multilink device according to claim 1, wherein the TWT agreement for the second station and the second AP is transferred to the first station and the first AP.

11. The aforementioned processor, The multilink device according to claim 10, wherein when the TWT agreement for the second station and the second AP is transferred to the first station and the first AP, the TWT parameters of the TWT agreement for the second station and the second AP are applied to the TWT agreement for the first station and the first AP.

12. A method for operating a multilink device including multiple stations, each operating on multiple links, An operating method comprising the step of sending a TWT (target wake time) element from a first station, which is one of several stations and coupled to a first AP on a first link, and requesting a TWT agreement for a second station operating on a second link and a second AP coupled to the second station.

13. The operation method according to claim 12, wherein the TWT element includes a bitmap indicating information that indicates the link to which the TWT agreement that the TWT element intends to establish applies.

14. The TWT request station for the TWT agreement for the second station and the second AP is the second station, The operation method according to claim 12, wherein the TWT response station for the TWT agreement for the second station and the second AP is the second AP.

15. The aforementioned operation method is, The operation method according to claim 14, further comprising the step of canceling the TWT agreement for the second station and the second AP when a TWT cancellation frame is received from the second AP or when the TWT cancellation frame is successfully transmitted to the second AP.

16. The aforementioned operation method is, The operation method according to claim 12, further comprising the step of canceling the TWT agreement for the second station and the second AP without receiving or transmitting a TWT cancellation frame that cancels the TWT agreement for the second station and the second AP when the second link is deactivated.

17. The operation method according to claim 12, wherein the TWT element requests a plurality of TWT agreements established on a plurality of links, including a second link.

18. The operation method according to claim 17, wherein each of the multiple TWT agreements established on the multiple links is identified based on the link ID of each of the multiple links.

19. The operation method according to claim 18, wherein each of the multiple TWT agreements established on the multiple links is identified based on the link ID of each of the multiple links, the MAC (medium access control) address of the multilink device, and the TWT Flow ID of each of the multiple TWT agreements established on the multiple links.

20. The aforementioned operation method is, The operation method according to claim 18, further comprising the step of, upon successfully transmitting or receiving a TWT deactivation frame, deactivating at least one of a plurality of TWT agreements established on a plurality of links based on the link ID indicated by the TWT deactivation frame.

Images