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

Abstract

To provide a wireless communication method using a multilink and a wireless communication terminal using the same.SOLUTION: In a wireless communication system, a multi-link device including a plurality of stations 100 each operating with a plurality of links includes a transmitting / receiving unit and a processor. The processor transmits a target wake time (TWT) element from a first station, which is one of the plurality of stations and is coupled to a first AP via a first link, and requests a TWT agreement for a second station operating with a second link and a second AP coupled to the second station.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to a multi-link device that operates with multiple links and a method for operating a multi-link device. [Background technology]

[0002] Recently, as the popularity of mobile devices has increased, wireless LAN technology, which can provide them with high-speed wireless Internet services, has been gaining attention. Wireless LAN technology is a technology that uses short-range wireless communication technology to enable mobile devices such as smartphones, smart pads, laptop PCs, portable multimedia players, embedded devices, etc. to connect to the Internet wirelessly at home, in business, or in specific service areas.

[0003] Since supporting early wireless LAN technology using the 2.4 GHz frequency band, IEEE (Institute of Electronics Engineers) 802.11 has since implemented or is currently developing various other technology standards. IEEE 802.11b uses the 2.4 GHz frequency band and supports a maximum communication speed of 11 Mbps. IEEE 802.11a, which was commercialized after IEEE 802.11b, uses the 5 GHz frequency band instead of the 2.4 GHz band, reducing the impact of interference compared to the significantly more congested 2.4 GHz frequency band, and uses OFDM technology to improve communication speeds to a maximum of 54 Mbps. However, IEEE 802.11a has the disadvantage of a shorter communication distance than IEEE 802.11b. IEEE 802.11g, like IEEE 802.11b, uses the 2.4GHz band and achieves a maximum transmission speed of 54Mbps, and has attracted considerable attention for its backward compatibility, but it also has an advantage over IEEE 802.11a in terms of communication distance.

[0004] IEEE 802.11n is a technical standard established to overcome the communication speed limitations that have been identified as a weakness of wireless LANs. IEEE 802.11n aims to increase network speed and reliability and extend the operating distance of wireless networks. Specifically, IEEE 802.11n supports high throughput (HT) of up to 540 Mbps and is based on MIMO (Multiple Inputs and Multiple Outputs) technology, which uses multiple antennas on both the transmitting and receiving ends to minimize transmission errors and optimize data speed. This standard also uses a coding method that transmits multiple duplicate copies to increase data reliability.

[0005] As WLAN adoption continues to grow and applications become more diverse, the need for new WLAN systems is emerging to support data throughput rates (Very High Throughput, VHT) higher than those supported by IEEE 802.11n. Among these, IEEE 802.11ac supports wide bandwidth (80MHz-160MHz) in the 5GHz frequency band. While the IEEE 802.11ac standard is defined only in the 5GHz band, initial 802.11ac chipsets are expected to support operation in the 2.4GHz band as well for backward compatibility with existing 2.4GHz products. Theoretically, this standard enables multi-station WLAN speeds of at least 1Gbps and maximum single-link speeds of at least 500Mbps. This is achieved by expanding the air interface concepts adopted in 802.11n, including wider radio frequency bandwidth (up to 160MHz), more MIMO spatial streams (up to 8), multi-user MIMO, and denser modulation (up to 256QAM). Additionally, there is IEEE 802.11ad, a method of transmitting data using the 60GHz band instead of the conventional 24GHz / 5GHz. 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 and can only be used between devices in close proximity.

[0006] Meanwhile, the IEEE 802.11ax (High Efficiency WLAN, HEW) standard is being developed and is nearing completion as the successor to 802.11ac and 802.11ad in order to provide high-efficiency and high-performance WLAN communication technology in high-density environments where APs and terminals are densely packed. In an 802.11ax-based WLAN environment, high-frequency-efficient communication must be provided both indoors and outdoors in the presence of a high density of stations and APs (Access Points), and various technologies are being developed to achieve this.

[0007] Additionally, development of a new WLAN standard has begun to increase maximum transmission speeds to support new multimedia applications such as high-definition video and real-time gaming. IEEE 802.11be (Extremely High Throughput, EHT), the seventh generation WLAN standard, is currently being developed with the goal of supporting transmission rates of up to 30Gbps in the 2.4 / 5 / 6GHz bands through wider bandwidth, increased spatial streams, and multi-AP cooperation. Summary of the Invention [Problem to be solved by the invention]

[0008] An object of one embodiment of the present invention is to provide a wireless communication method using multilinks and a wireless communication terminal using the same. [Means for solving the problem]

[0009] According to an embodiment of the present invention, a multi-link device including a plurality of stations operating on a plurality of links includes a transceiver unit and a processor, wherein the processor transmits a target wake time (TWT) element from a first station, which is one of the plurality of stations and is coupled to a first AP via a first link, and requests a TWT agreement between 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 indicating information indicating the link to which the TWT agreement that the TWT element is attempting to establish applies.

[0011] A TWT request station in a TWT agreement between the second station and the second AP may be the second station, and a TWT responding station in a TWT agreement between the second station and the second AP may be the second AP.

[0012] The processor may release the TWT agreement for the second station and the second AP when it receives a TWT release frame from the second AP or when it successfully sends the TWT release frame to the second AP.

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

[0014] The TWT element may request multiple TWT agreements to be established for multiple links, including the second link.

[0015] Each of the plurality of TWT agreements established for the plurality of links may be identified based on a link ID of each of the plurality of 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 multi-link 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 release frame, it can release at least one of multiple TWT agreements established on multiple links based on the link ID indicated by the TWT release frame.

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

[0019] When the processor 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 operating method of a multi-link device including a plurality of stations each operating on a plurality of links according to an embodiment of the present invention includes transmitting a target wake time (TWT) element from a first station, which is one of the plurality of stations and 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 indicating information indicating the link to which the TWT agreement that the TWT element is attempting to establish applies.

[0022] A TWT request station in a TWT agreement between the second station and the second AP may be the second station, and a TWT responding station in a TWT agreement between the second station and the second AP may be the second AP.

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

[0024] The operating method may further include a step of releasing the TWT agreement for the second station and the second AP when the second link is deactivated, even without receiving or transmitting a TWT release frame releasing the TWT agreement for the second station and the second AP.

[0025] The TWT element may request multiple TWT agreements to be established for multiple links, including the second link.

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

[0027] 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 multi-link device, and the TWT Flow ID of each of the multiple TWT agreements established on the multiple links.

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

[0029] One embodiment of the present invention provides a multi-link device that operates with multiple links, and a method for the multi-link device to efficiently perform TWT operation. [Brief explanation of the drawings]

[0030] [Figure 1] 1 is a diagram showing a wireless LAN system according to an embodiment of the present invention. [Figure 2] FIG. 10 is a diagram showing a wireless LAN system according to another embodiment of the present invention. [Figure 3] FIG. 2 is a diagram showing the configuration of a station according to an embodiment of the present invention. [Figure 4] FIG. 2 is a diagram illustrating a configuration of an access point according to an embodiment of the present invention. [Figure 5] 1 is a diagram illustrating a process in which a STA establishes a link with an AP. [Figure 6] FIG. 1 is a diagram illustrating a CSMA (Carrier Sense Multiple Access) / CA (Collision Avoidance) method used in wireless LAN communication. [Figure 7] 1 shows examples of various standard generation PPDU (PLCP Protocol Data Unit) formats. [Figure 8] 1 illustrates various Extremely High Throughput (EHT) Physical Protocol Data Unit (PPDU) formats and methods for indicating the same according to an embodiment of the present invention. [Figure 9] 1 shows a multi-link device according to an embodiment of the present invention; [Figure 10] 1 illustrates simultaneous transmission of different links in a multi-link operation according to an embodiment of the present invention. [Figure 11] 1 illustrates a method for establishing a broadcast TWT between an AP and a station according to an embodiment of the present invention. [Figure 12] 10 illustrates an example of an AP setting a quiet period according to an embodiment of the present invention. [Figure 13] A method for a station to set a TXOP taking into account a limited service period according to an embodiment of the present invention will now be described. [Figure 14] 10 illustrates a station re-performing a channel access procedure in consideration of a limited service period, according to an embodiment of the present invention. [Figure 15] 10 illustrates an operation in which an AP prematurely terminates a limited service period according to an embodiment of the present invention. [Figure 16] 1 shows a format of a TWT element according to an embodiment of the present invention. [Figure 17] 10 illustrates a multi-link device performing TWT agreement according to an embodiment of the present invention. [Figure 18]10 shows that, according to an embodiment of the present invention, a station included in a multilink device performs TWT negotiation for other stations included in the multilink device in which the station is included. [Figure 19] 10 illustrates an operation of a multi-link device according to an embodiment of the present invention to cancel a TWT agreement. [Figure 20] 10 shows the format of the Individual TWT parameter set field of the TWT element according to an embodiment of the present invention. [Figure 21] 10 illustrates the format of the remaining TWT Flow Identifier subfields other than the first TWT Flow Identifier subfield according to an embodiment of the present invention. [Figure 22] 10 illustrates the format of a Control field included in a TWT element transmitted by a multilink device according to an embodiment of the present invention. [Figure 23] 10 illustrates a format of an Action field of a TWT release frame transmitted by a multi-link device according to an embodiment of the present invention. [Figure 24] 10 illustrates an MLD TWT Flow field according to an embodiment of the present invention. [Figure 25] 10 shows the format of an MLD TWT Flow field according to yet another embodiment of the present invention. [Figure 26] 10 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] 10 illustrates an example embodiment of the present invention in which a TWT agreement established between multilink devices is implicitly terminated. DETAILED DESCRIPTION OF THE INVENTION

[0031] The terms used in this specification are generally used as widely as possible, taking into consideration the functions of the present invention. However, these may vary depending on the intentions of engineers in the relevant technical field, customs, or the emergence of new technologies. In addition, in certain cases, the applicant may have arbitrarily selected terms, and in such cases, the meanings thereof will be described in the relevant description of the invention. Therefore, it is made clear that the terms used in this specification should be interpreted not simply as names of terms, but based on the substantive meanings of the terms and the overall content of this specification.

[0032] Throughout this specification, when a component is referred to as being "connected" to another component, this includes not only when the component is "directly connected" to another component, but also when the component is "electrically connected" to another component via another component in between. Furthermore, when a component is referred to as "comprising" a specific component, this does not mean that the component may exclude the other component, but may further include the other component, unless otherwise specified. In addition, limitations such as "greater than" or "less than" based on a specific critical value may be appropriately substituted with "exceeds" or "less than," respectively, depending on the embodiment.

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

[0034] FIG. 1 is a diagram showing a wireless LAN system according to an embodiment of the present invention.

[0035] A wireless LAN system includes one or more Basic Service Sets (BSSs), which are a set of devices that can synchronize and 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 FIG. 1, infrastructure BSSs BSS1 and BSS2 include one or more stations STA1, STA2, STA3, STA4, and STA5, access points AP-1 and AP-2 that are stations providing distribution services, and a distribution system DS that connects multiple access points AP-1 and AP-2.

[0037] A station (STA) is any device that includes a medium access control (MAC) and a physical layer interface for a wireless medium according to the IEEE 802.11 standard. In a broad sense, the term "station" encompasses not only non-AP stations but also APs. In this specification, the term "terminal" refers to either a non-AP or an AP, or both. A station for wireless communication includes a processor and a communication unit, and may further include a user interface and a display unit, depending on the embodiment. The processor generates frames to be transmitted over a wireless network, processes frames received over the wireless network, and performs various other processes for controlling the station. The communication unit is functionally connected to the processor and transmits and receives frames over the wireless network for the station. In this specification, the term "terminal" encompasses user equipment (UE).

[0038] An access point (AP) is an entity that provides a connection to a distribution system (DS) via a wireless medium for associated stations. In an infrastructure BSS, communication between non-AP stations is generally performed via the AP. However, if a direct link is established, direct communication is also possible between non-AP stations. Meanwhile, in the present invention, the term AP is used as a concept including a personal BSS coordination point (PCP), but in a broader sense, it also includes concepts such as a central controller, a base station (BS), a node B, a base transceiver system (BTS), or a site controller. In the present invention, an AP is also referred to as a base wireless communication terminal, but in a broader sense, the term base wireless communication terminal is used as a term including an AP, a base station, an eNodeB (eNB), and a transmission point (TP). In addition, the base wireless communication terminal includes various types of wireless communication terminals that allocate communication medium resources and perform scheduling for communication with multiple wireless communication terminals.

[0039] A plurality of infrastructure BSSs are connected to each other via a distribution system DS, and the plurality of BSSs connected via the distribution system are called an Extended Service Set (ESS).

[0040] 2 is a diagram showing an independent BSS, which is a wireless LAN system according to another embodiment of the present invention. In the embodiment of FIG. 2, the same or corresponding parts as those in the embodiment of FIG. 1 will not be described again.

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

[0042] 3 is a block diagram showing the configuration of a station 100 according to an embodiment of the present invention. As shown, the station 100 according to 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 WLAN packets and may be incorporated into or external to the station 100. According to an embodiment, the communication unit 120 may include at least one communication module using different frequency bands. For example, the communication unit 120 may include communication modules using different frequency bands such as 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz. According to an embodiment, the station 100 may include a communication module using a frequency band above 7.125 GHz and a communication module using a frequency band below 7.125 GHz. Each communication module may perform wireless communication with an AP or an external station based on the WLAN standard of the frequency band supported by the communication module. The communication unit 120 may operate only one communication module at a time or multiple communication modules simultaneously, depending on the performance and requirements of the station 100. When the station 100 includes multiple communication modules, each communication module may be provided independently, or multiple modules may be integrated into a single chip. In the embodiment of the present invention, the communication unit 120 may represent a radio frequency (RF) communication module that processes RF signals.

[0044] Next, the user interface 140 includes various types of input / output means provided in the station 100. That is, 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. Also, the user interface unit 140 performs output based on instructions from the processor 110 using various output means.

[0045] Next, the display unit 150 outputs an image on a display screen. The display unit 150 outputs various display objects, such as a user interface, based on the contents processed by the processor 110 or the control commands of the processor 110. The memory 160 also stores control programs and various data used by the station 100. The control programs include a connection program required for the station 100 to connect to an AP or an external station.

[0046] The processor 110 of the present invention executes various commands or programs to process 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 the units. According to an embodiment of the present invention, the processor 110 executes a program for connection with an AP stored in the memory 160 and receives a communication setup message transmitted by the AP. The processor 110 also reads information about the station 100's preferences contained in the communication setup message and requests connection to the AP based on the information about the station 100's preferences. The processor 110 of the present invention may refer to a main control unit of the station 100, or, depending on the embodiment, may refer to a control unit for individually controlling some components of the station 100, such as the communication unit 120. That is, the processor 110 may be a modem that modulates and demodulates wireless signals transmitted and received by the communication unit 120, or a modulator and / or demodulator. The processor 110 controls various operations for transmitting and receiving wireless signals in the station 100 according to an embodiment of the present invention. A detailed embodiment of this will be described later.

[0047] The station 100 shown in FIG. 3 is a block diagram according to an embodiment of the present invention, and the separate blocks indicate the logically separated elements of the device. Therefore, the above-described device elements may be mounted on a single chip or multiple chips depending on the device design. For example, the processor 110 and the communication unit 120 may be integrated into a single chip or may be mounted on separate chips. Furthermore, in embodiments 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] 4 is a block diagram showing the configuration of an AP 200 according to an embodiment of the present invention. As shown, the AP 200 according to the embodiment of the present invention includes a processor 210, a communication unit 220, and a memory 260. In FIG. 4, duplicated descriptions of parts of the configuration of the AP 200 that are the same as or correspond to the configuration of the station 100 in FIG. 3 will be omitted.

[0049] Referring to FIG. 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 FIG. 3, the communication unit 220 of the AP 200 may also include multiple communication modules using different frequency bands. That is, the AP 200 according to the embodiment of the present invention may 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 may include a communication module using a frequency band above 7.125 GHz and a communication module using a frequency band below 7.125 GHz. Each communication module may perform wireless communication with a station based on the WLAN standard of the frequency band supported by the communication module. The communication unit 220 may operate only one communication module at a time or multiple communication modules simultaneously, depending on the performance and requirements of the AP 200. In the embodiment of the present invention, the communication unit 220 may represent an RF (Radio Frequency) communication module that processes RF signals.

[0050] The memory 260 stores control programs used by the AP 200 and various data associated therewith. These control programs include a connection program that manages station connections. The processor 210 also controls each unit of the AP 200 and controls data transmission and reception between the units. According to an embodiment of the present invention, the processor 210 executes a program for connecting with a station stored in the memory 260 and transmits a communication setup message to one or more stations. The communication setup message includes information regarding connection preferences for each station. The processor 210 also performs connection setup in response to a station connection request. According to an embodiment, the processor 210 is a modem or a modulator / demodulator that modulates and demodulates wireless signals transmitted and received by the communication unit 220. The processor 210 controls various operations for transmitting and receiving wireless signals by the AP 200 according to an embodiment of the present invention. A detailed embodiment of this will be described later.

[0051] FIG. 5 is a diagram illustrating a process in which a STA establishes a link with an AP.

[0052] 5, a link between the STA 100 and the AP 200 is established through three steps: scanning, authentication, and association. First, the scanning step is a step in which the STA 100 acquires connection information for the BSS operated by the AP 200. There are two scanning methods: a passive scanning method in which the STA 100 acquires information using only a beacon message S101 periodically transmitted by the AP 200, and an active scanning method in which the STA 100 transmits a probe request to the AP S103, receives a probe response from the AP S105, and acquires connection information.

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

[0054] Meanwhile, an 802.1X-based authentication step S111 and an IP address acquisition step S113 via DHCP are additionally performed. In Fig. 5, server 300 is a server that processes 802.1X-based authentication with STA 100, and may be physically connected to AP 200 or may exist as a separate server.

[0055] FIG. 6 is a diagram showing a CSMA (Carrier Sense Multiple Access) / CA (Collision Avoidance) method used in wireless LAN communication.

[0056] A terminal performing WLAN communication performs carrier sensing to check whether a channel is occupied before transmitting data. If a wireless signal above a certain strength is detected, the channel is determined to be occupied, and the terminal delays access to the channel. This process is called Clear Channel Assessment (CCA), and the level that determines whether or not a signal is detected is called the CCA threshold. If a wireless signal above the CCA threshold is received by the terminal and the terminal is the receiver, the terminal processes the received wireless signal. On the other hand, if no wireless signal is detected from the channel or a wireless signal with a strength below the CCA threshold is detected, the channel is determined to be idle.

[0057] If the channel is determined to be idle, each terminal having data to transmit performs a backoff procedure after an Inter Frame Space (IFS), such as an Arbitration IFS (AIFS) or a PCF IFS (PIFS), depending on the status of each terminal. In some embodiments, the AIFS is used as a configuration replacing the conventional DCF IFS (DIFS). Each terminal waits while decrementing a slot time equal to a random number determined for the corresponding terminal during the idle interval of the channel, and a terminal that has exhausted all of its slot time attempts to access the corresponding channel. The period during which each terminal performs the backoff procedure is called a contention window period. In this case, the random number can be called a backoff counter. That is, the initial value of the backoff counter is set by an integer, which is a random number obtained by the terminal. If the terminal detects that the channel is idle during the slot time, the terminal can decrement the backoff counter by 1. If the backoff counter reaches 0, the terminal may be allowed to perform channel access on the corresponding channel. Therefore, if the channel is idle during the AIFS time and the backoff counter slot time, the terminal may be allowed to transmit.

[0058] If a specific terminal successfully accesses the channel, it transmits data over the channel. However, if the terminal attempting access collides with another terminal, the colliding terminals are assigned new random numbers and perform a backoff procedure again. According to one embodiment, the new random numbers assigned to each terminal are determined within a range (2*CW) twice the range of the random numbers previously assigned to the terminal (contention window, CW). Meanwhile, each terminal attempts access by performing a backoff procedure again in the next contention window period. At this time, each terminal performs the backoff procedure from the slot time remaining in the previous contention window period. In this way, terminals communicating over a wireless LAN can avoid collisions with each other on a specific channel.

[0059] <Examples of various PPDU formats>

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

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

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

[0063] Referring to FIG. 7(c), the preamble of the EHT PPDU further includes a Repeated Legacy Short Training field (RL-SIG), a Universal Signal field (U-SIG), an Extremely High Throughput Signal A field (EHT-SIG-A), an Extremely High Throughput Signal B field (EHT-SIG-A), an Extremely High Throughput Short Training field (EHT-STF), and an Extremely High Throughput Long Training field (EHT-LTF) in addition to the legacy preamble. In an embodiment of the present invention, the RL-SIG, EHT-SIG-A, EHT-SIG-B, EHT-STF, and EHT-LTF may be referred to as an EHT preamble. The specific configuration of the non-legacy preamble may vary depending on the EHT PPDU format. For example, EHT-SIG-A and EHT-SIG-B may be used only in some EHT PPDU formats.

[0064] The L-SIG field included in the PPDU preamble is configured with a total of 64 subcarriers using 64 FFT OFDM. Of these, 48 subcarriers, excluding guard subcarriers, DC subcarriers, and pilot subcarriers, are used for L-SIG data transmission. BPSK and Rate=1 / 2 MCS (Modulation and Coding Scheme) are applied to the L-SIG, so it can contain a total of 24 bits of information. Figure 7(d) shows the 24-bit information structure of the L-SIG.

[0065] Referring to FIG. 7(d), the L-SIG includes an L_RATE field and an L_LENGTH field. The L_RATE field is composed of 4 bits and indicates the MCS used for data transmission. Specifically, the L_RATE field indicates one of the transmission rates of 6, 9, 12, 18, 24, 36, 48, or 54 Mbps, which is a combination of a modulation scheme such as BPSK, QPSK, 16-QAM, or 64-QAM and a code rate such as 1 / 2, 2 / 3, or 3 / 4. The combined information in the L_RATE and L_LENGTH fields indicates the total length of the PPDU. In a non-legacy PPDU format, the L_RATE field is set to the minimum rate of 6 Mbps.

[0066] The unit of the L_LENGTH field is byte, and a total of 12 bits are allocated, allowing signaling up to 4095. In combination with the L_RATE field, the length of the PPDU can be indicated. In this case, legacy and non-legacy terminals can interpret the L_LENGTH field in different ways.

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

[0068]

number

[0069] At this time,

[0070]

number

[0071] 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. A non-legacy terminal transmitting the PPDU must set the L_LENGTH field as shown in Equation 3 below.

[0072]

number

[0073] Here, TXTIME is the total transmission time constituting the PPDU, and is expressed as the following equation 4. 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 ​​of 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 remains in the EHT PPDU and subsequent generation WLAN PPDUs, and serves to distinguish which generation of PPDU it is, including 11be. The U-SIG is two 64FFT-based OFDM symbols and can transmit a total of 52 bits of information. Of these, 43 bits excluding 9 bits of CRC / tail are roughly divided into a VI (Version Independent) field and a VD (Version Dependent) field.

[0077] The VI bit will maintain its current bit configuration, so even if a subsequent generation PPDU is defined, current 11be UEs can obtain information about the PPDU from the VI field of the PPDU. 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 long and serves to sequentially distinguish between 11be and subsequent generations of WLAN standards. 11be has a value of 000b. The UL / DL field identifies whether the PPDU is an uplink or downlink PPDU. The BSS color represents a BSS identifier defined in 11ax and has a value of 6 or more bits. The TXOP represents the transmit opportunity duration (Transmit Opportunity Duration) transmitted in the MAC header. By adding it to the PHY header, the length of the TXOP containing the PPDU can be inferred without decoding the MPDU, and has a value of 7 or more bits.

[0078] The VD field, which is signaling information useful only for 11be version PPDUs, may consist of fields commonly used in any PPDU format, such as the PPDU format and BW, as well as fields defined differently for each PPDU format. The PPDU format is a separator that distinguishes between EHT SU (Single User), EHT MU (Multiple User), EHT TB (Trigger-based), and EHT ER (Extended Range) PPDUs. The BW field broadly signals five basic PPDU BW options: 20, 40, 80, 160 (80 + 80), and 320 (160 + 160) MHz (BWs that can be expressed in the form of a power of 20 * 2 can be called basic BWs), as well as various remaining PPDU BWs formed by preamble puncturing. After signaling at 320 MHz, a portion of 80 MHz may be punctured. In addition, the punctured and modified channel shape may be signaled directly in the BW field, or may be signaled using both the BW field and a field that appears after the BW field (for example, a field in 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] The fields located after the BW field vary depending on the type and format of the PPDU. MU PPDUs and SU PPDUs may be signaled in the same PPDU format, and a field for distinguishing 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 not required for the SU PPDU may be compressed. In this case, the information of the compressed fields may be omitted or may have a reduced size compared to the size of the original fields included in the MU PPDU. For example, the SU PPDU may have a different configuration, such as the common fields of the EHT-SIG being omitted or replaced, or the user-specific fields being replaced or reduced to one.

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

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

[0082] In the case of an SU PPDU, a STA may be assigned multiple RUs, and the multiple RUs may be contiguous or discontinuous. If the RUs assigned to the STA are not contiguous, the STA can efficiently receive the SU PPDU only by recognizing punctured RUs in between. Therefore, the AP can transmit the SU PPDU including information on punctured RUs among the RUs assigned to the STA (e.g., puncturing pattern of the RUs). That is, in the case of an SU PPDU, a puncturing mode field including information indicating whether a puncturing mode is applied and the puncturing pattern in a bitmap format, etc., may be included in the EHT-SIG field, and the puncturing mode field can signal the type of discontinuous channels appearing within the bandwidth.

[0083] The type of signaled discontinuous channel is limited, and indicates the BW and discontinuous channel information of the SU PPDU in combination with the value of the BW field. For example, since the SU PPDU is a PPDU transmitted only to a single UE, the STA can recognize its allocated bandwidth from the BW field included in the PPDU and can recognize 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 UE can receive the PPDU in the remaining resource units other than the specific channel of the punctured resource units. In this case, multiple RUs allocated to the STA may be configured with different frequency bands or tones.

[0084] The reason why only limited discontinuous channel types are signaled is to reduce the signaling overhead of the SU PPDU. Since puncturing can be performed for each 20 MHz subchannel, if puncturing is performed on a BW having multiple 20 MHz subchannels, such as 80, 160, or 320 MHz, in the case of 320 MHz, the discontinuous channel type (when only the end 20 MHz is punctured and considered discontinuous) must be signaled by expressing whether or not the remaining 15 20 MHz subchannels other than the primary channel are in use. Using 15 bits to signal the discontinuous channel type for single-user transmission can result in excessive signaling overhead when considering the low transmission rate of the signaling part.

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

[0086] In addition, one embodiment of the present invention proposes a method of varying the PPDU configuration indicated by the preamble puncturing BW value depending on the PPDU format signaled in the PPDU format field. Assuming that the BW field is 4 bits, in the case of an EHT SU PPDU or TB PPDU, an EHT-SIG-A symbol can be further signaled after the U-SIG, or no EHT-SIG-A can be signaled at all. Taking this into consideration, up to 11 puncturing modes must be fully signaled using only the BW field of the U-SIG. However, in the case of an EHT MU PPDU, an EHT-SIG-B symbol is further signaled after the U-SIG, so up to 11 puncturing modes can be signaled in a different manner than in the case of 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 20 MHz or 10 MHz bandwidth. Detailed puncturing patterns for each PPDU type will be described in detail below with reference to FIGS. 11 and 12.

[0087] Figure 7(f) shows the format-specific field configuration of the VD field when the PPDU format field of the U-SIG indicates an EHT MU PPDU. For an MU PPDU, SIG-B, a signaling field for simultaneous reception by multiple users, is required. SIG-B may be transmitted after the U-SIG without a separate SIG-A. For this purpose, the U-SIG must signal information for decoding SIG-B. These fields include the SIG-B MCS, SIG-B DCM, number of SIG-B symbols, SIG-B compression, and number of EHT-LTF symbols.

[0088] FIG. 8 illustrates an example of various Extremely High Throughput (EHT) Physical Protocol Data Unit (PPDU) formats and methods for indicating the same according to an embodiment of the present invention.

[0089] 8, a PPDU may be configured with a preamble and a data portion, and the format of one type, EHT PPDU, may be distinguished by a U-SIG field included in the preamble. Specifically, whether the format of the PPDU is EHT PPDU may be indicated based on a PPDU format field included in the U-SIG field.

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

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

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

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

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

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

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

[0097] For ease of explanation, the term 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 improved. 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, when the frequency band of one link is being used by another wireless communication device, the wireless communication device can continue communication using another link. In this way, the wireless communication device can effectively use multiple channels. Furthermore, when a wireless communication device simultaneously communicates using multiple links, the overall throughput can be improved. However, existing wireless LANs are specified on the assumption that one wireless communication device uses one link. Therefore, a wireless LAN operation method for using multiple links is needed. A wireless communication method for a wireless communication device using multiple links will be described with reference to FIGS. 9 to 26. First, a specific embodiment of a wireless communication device using multiple links will be described with reference to FIG. 9.

[0099] FIG. 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 multiple links described above. The multi-link device may represent a device having one or more affiliated stations. Depending on a specific embodiment, the multi-link device may represent a device having two or more affiliated stations. The multi-link device may also exchange multi-link elements. The multi-link element includes information about one or more stations or one or more links. The multi-link element may include a multi-link setup element, which will be described later. In this case, the multi-link device may be a logical entity. Specifically, the multi-link device may have multiple affiliated stations. The multi-link device may be referred to as a multi-link logical entity (MLLE) or a multi-link entity (MLE). The multi-link device may have one medium access control service access point (SAP) up to a logical link control (LLC). The MLD may also have one MAC data service.

[0101] Multiple stations included in a multilink device can operate on multiple links. Also, multiple stations included in a multilink device can operate on multiple channels. Specifically, multiple stations included in a multilink device can operate on different links or different channels. For example, multiple stations included in a multilink device can operate on different channels, such as 2.4 GHz, 5 GHz, and 6 GHz.

[0102] The operation of the multilink device can be referred to as multilink operation, MLD operation, or multi-band operation. If the station associated with the multilink device is an AP, the multilink device can be referred to as AP MLD. If the station associated with the multilink device is a non-AP station, the multilink device can be referred to as non-AP MLD.

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

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

[0105] Multilink configuration may be established through negotiation between peer stations. Specifically, multilink configuration may be established through communication between stations without communication with an AP. Multilink configuration may also be established through any one of the links. For example, even if the first to third links are established through multilink, multilink configuration may be established through the first link.

[0106] In addition, a mapping between a traffic identifier (TID) and a link may be configured. Specifically, frames corresponding to a specific TID value may be exchanged only through a pre-specified link. The mapping between a TID and a link may be configured on a directional basis. For example, when multiple links are configured between a first multilink device and a second multilink device, the first multilink device may be configured to transmit frames of the first TID to the multiple first links, and the second multilink device may be configured to transmit frames of the second TID to the first link. In addition, a default setting may exist for the mapping between TIDs and links. Specifically, if no additional settings are configured in the multilink configuration, the multilink device may exchange frames corresponding to TIDs on each link according to a default setting. In this case, the default setting may be that all TIDs are exchanged on any one link.

[0107] The TID will be described in detail. The TID is an ID for classifying traffic and data to support quality of service (QoS). The TID may be used and assigned in a layer higher than the MAC layer. The TID may indicate a traffic category (TC) or a traffic stream (TS). There may be 16 distinct TIDs. For example, the TID may be designated as any one of 0 to 15. Different TID values ​​may be designated depending on an access policy, a channel access method, or a medium access method. For example, when enhanced distributed channel access (EDCA) or hybrid coordination function contention-based channel access (HCAF) is used, the TID may be assigned a value ranging from 0 to 7. When EDCA is used, the TID may indicate a user priority (UP). In this case, the UP may be designated by the TC or the TS. The UP may be assigned in a layer higher than the MAC. Furthermore, when HCCA (HCF controlled channel access) or SPCA is used, the TID may be assigned a value in the range of 8 to 15. When HCCA or SPCA is used, the TID may indicate a TSID. Furthermore, when HEMM or SEMM is used, the TID may be assigned a value in the range of 8 to 15. When HEMM or SEMM is used, the TID may indicate a 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 may include AC_BK, AC_BE, AC_VI, and AC_VO. AC_BK, AC_BE, AC_VI, and AC_VO may indicate background, best effort, video, and voice, respectively. AC_BK, AC_BE, AC_VI, and AC_VO may be classified into lower-level ACs. For example, AC_VI may be further subdivided into AC_VI primary and AC_VI alternate. AC_VO may be further subdivided into AC_VO primary and AC_VO alternate. UP or TID may be mapped to an AC. For example, 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, 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. Also, 1, 2, 0, 3, 4, 5, 6, and 7 in UP or TID may have decreasing priority in that order. That is, 1 may have a lower priority, and 7 may have a higher priority. Therefore, the order of priority may be AC_BK, AC_BE, AC_VI, and AC_VO. Also, AC_BK, AC_BE, AC_VI, and AC_VO can correspond to ACI (AC index) 0, 1, 2, and 3, respectively. Due to the characteristics of TID, the mapping between TID and link can represent the mapping between AC and link.The mapping between links and ACs can also represent the mapping between TIDs and links.

[0109] As described above, a TID may be mapped to each of multiple links. The mapping may specify the links through which traffic corresponding to a specific TID or AC can be exchanged. Furthermore, the TID or AC that can be transmitted for each transmission direction within a link may be specified. As described above, a default setting may exist for the mapping between TIDs and links. Specifically, if no additional settings are configured in the multilink configuration, the multilink device may exchange frames corresponding to the TID 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 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 the link may be transmitted on the link. Therefore, when a link is mapped to a TID or AC, frames not corresponding to a TID or AC not mapped to the link may not be transmitted on the link. When a link is mapped to a TID or AC, an 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 the TID and the link. In yet another specific embodiment, the mapping between the TID and the link may be determined based on the Block ACK agreement. Specifically, a Block ACK agreement may be set for a TID mapped to a specific link.

[0111] The above-described TID-to-link mapping may ensure QoS. Specifically, a high-priority AC or TID may be mapped to a link where a relatively small number of stations are active or where channel conditions are good. The above-described TID-to-link mapping may also allow stations to remain in a power-saving state for a longer period of time.

[0112] FIG. 10 illustrates simultaneous transmission of different links in multi-link operation according to an embodiment of the present invention.

[0113] Depending on the implementation of the multi-link device, simultaneous operation of the multi-links may not be supported. For example, a multi-link device may support simultaneous transmission on multiple links, simultaneous reception on multiple links, or transmission on one link while receiving on another link. Reception or transmission on one link may affect reception or transmission on another link. Specifically, transmission on one link may interfere with other links. Interference from one link of a multi-link device affecting other links may be called internal leakage. The smaller the frequency spacing between links, the greater the internal leakage. If the internal leakage is not too large, transmission on one link can occur when transmission on another link. If the internal leakage is large, transmission on one link cannot occur when transmission on another link. This simultaneous operation of the multi-link device on multiple links may be called STR (simultaneous transmit and receive, simultaneous transmission and reception). For example, a multilink device transmitting on multiple links simultaneously, transmitting on one link while receiving on another link, or receiving on multiple links simultaneously can be referred to as STR.

[0114] As mentioned above, a multilink device can support STR, or can support it with limitations. Specifically, a multilink device can support STR only under certain conditions. For example, if the multilink device operates with a single radio, the multilink device may not be able to perform STR. Also, if the multilink device operates with a single antenna, the multilink device may not be able to perform STR. Also, if an internal leak is detected to be greater than a predetermined magnitude, the multilink device may not be able to perform STR.

[0115] A station can exchange information about its STR capability with other stations. Specifically, a station can exchange information about whether or not the station has limitations on its ability to simultaneously transmit or receive on multiple links. Specifically, the information about whether or not the station has limitations on its ability to transmit or receive on multiple links can indicate whether or not the station will transmit or receive on multiple links simultaneously, or whether or not transmission and reception are simultaneous. Furthermore, the information about whether or not the station has limitations on its ability to transmit or receive on multiple links can be information indicated in stages. Specifically, the information about whether or not the station has limitations on its ability to transmit or receive on multiple links can be information indicating a stage indicating the magnitude of internal leakage. In a specific embodiment, the information indicating a stage indicating the magnitude of internal leakage can be information indicating a stage indicating the magnitude of interference caused by internal leakage. In yet another specific embodiment, the information indicating a stage indicating the frequency spacing between links that may affect internal leakage can be information indicating a stage indicating the relationship between the frequency spacing between links and the magnitude of internal leakage.

[0116] In FIG. 10, a first station (STA1) and a second station (STA2) are affiliated with one non-AP multilink device. A first AP (AP1) and a second AP (AP2) may also be affiliated with one 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 FIG. 10, the non-AP multilink device can perform limited STR. When the second station (STA2) transmits on the second link (Link2), the first station (STA1)'s reception on the first link (Link1) may be interrupted by the transmission on the second link (Link2). For example, in the following case, the first station (STA1)'s reception on the first link (Link1) may be interrupted by the transmission on the second link (Link2). The second station (STA2) transmits the first data (Data1) over the second link (Link2), and the first AP (AP1) transmits a response (Ack for Data1) to the first station (STA1). The second station (STA2) transmits the second data (Data2) over the second link (Link2). At this time, the transmission of the second data (Data2) and the transmission of the response (Ack for Data1) to the first data (Data1) may overlap. In this case, the transmission to the second station (STA2) over the second link (Link2) may cause interference to the first link (Link1). As a result, the first station (STA1) may not receive the response (Ack for Data1) to the first data (Data1).

[0117] The operation of the multilink device for channel access will be described below. The multilink operation without a specific description can follow the channel access procedure described in FIG.

[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 a multilink device performs channel access independently from multiple links and the backoff counters for multiple links reach zero, the multilink device can start transmission simultaneously from multiple links. In a specific embodiment, when one of the backoff counters for multiple links reaches zero and a predetermined condition is met, the multilink device can perform channel access not only for the link whose backoff counter has reached zero but also for other links whose backoff counters have not reached zero. Specifically, when one of the backoff counters for multiple links reaches zero, the multilink device can perform energy sensing on other links whose backoff counters have not reached zero. In this case, if energy greater than or equal to a predetermined value is not detected, the multilink device can perform channel access not only for the link whose backoff counter has reached zero but also for the link for which energy sensing has been performed. This allows the multilink device to start transmission simultaneously from multiple links. The threshold used for energy sensing may be smaller than the threshold used for determining whether to decrement the backoff counter. Furthermore, when determining whether to decrement the backoff counter, the multilink device can sense any type of signal, not just a WLAN signal. Furthermore, in the energy sensing described above, the multilink device can sense any type of signal, not just a WLAN signal. Internal leakage may not be detected as a WLAN signal. In such a case, the multilink device can detect signals detected due to internal leakage through energy sensing. Furthermore, as described above, the threshold used for energy sensing may be smaller than the threshold used when determining whether to decrement the backoff counter. Therefore, even while transmission is occurring on one link, the multilink device can decrement the backoff counter on another link.

[0119] Depending on the degree of interference between links used by the multilink device, the multilink device may determine whether 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 in the multilink device when one station in the multilink device transmits on one of the links. If transmission on the first link of a first station in the multilink device causes interference of a predetermined magnitude or greater to a second station in the multilink device operating on the second link, the operation of the second station may be restricted. Specifically, reception or channel access of the second station may be restricted. If interference occurs, the second station may fail to decode a received signal due to the interference. Furthermore, if interference occurs, the second station may determine that the channel is in use when accessing the channel using backoff.

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

[0121] The degree of interference occurring between stations of a multilink device may vary depending on the interval between the frequency bands of the links on which the stations operate as well as the hardware characteristics of the multilink device. For example, the internal interference occurring in a multilink device including a high RF (radio frequency) device may be smaller than the internal interference occurring in a multilink device including a low RF device. Therefore, the degree of interference occurring between stations of a multilink device may be determined based on the characteristics of the multilink device.

[0122] FIG. 10 shows how the magnitude of interference varies depending on the spacing between link frequency bands and the characteristics of the multilink devices. In the example of FIG. 10, a first multilink device (MLD#1) includes a first station (STA1)-1 operating on a first link (Link1) and a second station (STA1)-2 operating on a second link (Link2). A second multilink device (MLD#2) includes a first station (STA2)-1 operating on a first link (Link1) and a second station (STA2)-2 operating on a second link (Link2). The frequency spacing between the first link (Link1) and the second link (Link2) on which the first multilink device (MLD#1) operates is the same as the frequency spacing between the first link (Link1) and the second link (Link2) on which the second multilink device (MLD#2) operates. However, the magnitude of interference varies depending on the difference between the characteristics of the first multilink device (MLD#1) and the second multilink device (MLD#2). Specifically, the magnitude of interference generated in the second multilink device (MLD#2) may be greater than the magnitude of interference generated in the first multilink device (MLD#1). Considering that the magnitude of interference generated may differ depending on the characteristics of the multilink devices and that the presence or absence of STR support may differ depending on the multilink devices, information regarding whether STR is supported or not needs to be exchanged.

[0123] A multilink device can signal whether or not a station included in the multilink device supports STR. Specifically, an AP multilink device and a non-AP multilink device can exchange whether or not an AP included in the AP multilink device supports STR with whether or not a STA included in the non-AP multilink device supports STR. In this embodiment, an element indicating whether or not STR support is available may be used. The element indicating whether or not STR support is available may be referred to as an STR support element. The STR support element may indicate, with one bit, whether or not a station in the multilink device that transmitted the STR support element supports STR. Specifically, the STR support element may indicate, with one bit, whether or not each station included in the multilink device that transmitted the STR support element supports STR. In this case, if a station supports STR, the bit value may be 1, and if a station does not support STR, the bit value may be 0. If the multilink device that transmitted 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 STR, and the second station (STA2) does not support STR, the STR support element is 101. 1b The STR Support element may include a field having the following information: Stations operating in different frequency bands are assumed to support STR, and the STR Support element may omit signaling regarding the presence or absence of STR support between stations operating in different frequency bands. For example, a first station (STA1) operates on a first link of 2.4 GHz, and a second station (STA2) and a third station (STA3) operate on a second link of 5 GHz and a third link of 5 GHz, respectively. In this case, the STR Support element may indicate with one bit that STR is supported between the second station (STA2) and the third station (STA3). Alternatively, the STR Support element may include only one bit if the STR Support element signals two stations.

[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 among the links of a multi-link device may always be determined as STR, and therefore, signaling regarding the presence or absence of STR between a link located at 2.4 GHz and a link located at 5 GHz or 6 GHz may be omitted.

[0125] In the above-described embodiments, the operation of a station in a multilink device may be replaced by the operation of the multilink device. Also, in the above-described embodiments, the operation of an AP may be replaced by the operation of a non-AP station, and the operation of a non-AP station may be replaced by the operation of an AP. Thus, the operation of an AP in a non-STR multilink device may be replaced by 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 by the operation of an AP in the STR multilink device. Also, the operation of a non-AP station in a non-STR multilink device may be replaced by the operation of an AP in a non-STR multilink device, and the operation of an AP in an STR multilink device may be replaced by the operation of a non-AP station in the STR multilink device.

[0126] Scheduling for low-latency traffic transmission will be described with reference to FIGS. 11 to 15. In conventional WLAN communications, enhanced distributed channel access (EDCA) is used to set channel access parameters for each AC, and traffic is processed according to priority for each AC using the set channel access parameters. However, existing EDCA provides channel access with high priority stochastically, which is insufficient for supporting low-latency traffic transmission. To address this issue, a time period during which low-latency traffic can be transmitted with priority can be set. For ease of explanation, the time period during which low-latency traffic is transmitted with priority is called a restricted service period. Most services requiring low-latency traffic transmission, such as VR / AR, require periodic traffic transmission, and therefore the restricted service period significantly reduces the transmission delay of low-latency traffic.

[0127] The limited service period may be a time interval during which transmission of low-latency traffic and transmission of a response to the low-latency traffic are preferentially permitted. Specifically, the limited service period may be a time interval during which only transmission of low-latency traffic and transmission of a response to the low-latency traffic are permitted. In yet another specific embodiment, the limited service period may be a time interval during which transmission of low-latency traffic and transmission of a response to the low-latency traffic are performed, and after transmission of the low-latency traffic and transmission of the response to the low-latency traffic are completed, transmission of traffic other than the low-latency traffic is permitted.

[0128] First, a method for setting a limited service period will be described. The limited service period may be set by TWT in an existing WLAN. TWT sets a service period through negotiation between an AP and a station, and supports the AP and station to transmit and receive during the service period and enter a low power mode outside the service period. This will be described in detail with reference to FIG. 11. For convenience of explanation, the operation of the AP and station based on the limited service period set by TWT is referred to as limited TWT.

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

[0130] The service period for TWT can be set as follows: The AP requests stations associated with the AP to join TWT. Stations can join broadcast TWT or negotiate individual TWT with the AP. In this case, the AP can request stations to join TWT by setting the value of the TWT Required subfield of the HE Operation element to 1. The AP can also transmit a Broadcast TWT element in a management frame, for example, a beacon frame, to convey information necessary for stations to join broadcast TWT. In this case, the AP can signal that it supports 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 limited service period similar to the TWT service period.

[0131] In the embodiment of FIG. 11, the first station (STA1) requests TWT configuration from the AP. The AP and the first station (STA1) configure TWT parameters, such as the initial TBTT and listen interval. This configures the AP, the first station (STA1), and the second station (STA2) for broadcast TWT. The AP uses a beacon frame to indicate a broadcast TWT service period. During the broadcast TWT service period, the AP can transmit downlink (DL) physical layer protocol data units (PPDUs) to the first station (STA1) and the second station (STA2), or can transmit trigger frames to the first station (STA1) and the second station (STA2) to trigger uplink (UL) transmissions. During the broadcast TWT service period, the first station (STA1) and the second station (STA2) wake up to receive beacon frames. The first station (STA1) and the second station (STA2) acquire TWT information from the received beacon frames. 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 awake. 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] In the service period of the existing TWT, stations that do not participate in the TWT are not restricted from accessing the channel or transmitting. This is because the TWT is intended to help stations that participate in the TWT enter a doze state. However, a restricted service period to prevent transmission delays of low-latency traffic must guarantee the priority transmission of low-latency traffic, so a method for protecting the restricted service period is required.

[0133] During the restricted service period, stations that do not participate in the restricted TWT may be restricted from accessing the channel. Specifically, stations that do not participate in the restricted TWT may not be able to access the channel during the restricted service period. If a station that does not participate in the 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 may restart the channel access procedure when the restricted service period ends. In addition, the station's channel access may represent an EDCA backoff procedure. Completion of channel access may represent the backoff counter of the EDCA backoff procedure reaching 0. In addition, when a station restarts the channel access procedure, the station may randomly obtain an integer within the CW used in the previous channel access and use the obtained integer for the backoff counter. In other words, the station does not need to double the size of the CW used in the previous channel access. In this case, the CW may be maintained separately for each AC. Such channel access restriction may be applied only to stations that support restricted TWT. Specifically, such channel access restriction is applied only to non-legacy (EHT) stations for which dot11RestrictedTWTOptionImplemented in the EHT Capabilities element is set to true, and may not be applied to non-legacy (EHT) stations for which dot11RestrictedTWTOptionImplemented in the EHT Capabilities element is set to false. In this specification, non-legacy stations may refer to EHT stations and stations subsequent to EHT stations. Furthermore, legacy stations are stations prior to EHT stations, and may refer to non-HT stations, HT stations, VHT stations, and HE stations.

[0134] Furthermore, during the restricted service period, non-legacy stations may be configured with a NAV for traffic other than low-latency traffic. Specifically, as the NAV is configured for traffic other than low-latency traffic, the stations may discontinue channel access procedures for transmitting traffic other than low-latency traffic. In such an embodiment, the NAV may be a NAV independent of the conventional NAV (basic NAV, intra-BSS NAV). In this case, non-legacy stations may be limited to stations that support restricted TWT. In yet another specific embodiment, non-legacy stations may be limited to stations that participate in restricted TWT.

[0135] The limited service period may be included within the broadcast TWT service period. In yet another specific embodiment, the limited service period may not be included within the broadcast TWT service period.

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

[0137] In addition, a quiet interval may be set for stations that do not support limited TWT. In conventional WLANs, the quiet interval is a period for supporting channel sensing. When the quiet interval is set, all stations suspend transmission. Using this characteristic of the quiet interval, the limited service period can be protected. This will be explained with reference to FIG. 12. In this case, stations that do not support limited TWT may be limited to legacy stations.

[0138] FIG. 12 illustrates how an AP sets a quiet period according to an embodiment of the present invention.

[0139] An AP operating a restricted TWT can transmit a quiet element to set a quiet period. During the quiet period, stations suspend channel access. However, if channel access of stations participating in a restricted TWT is also restricted, low-latency traffic transmission is not possible. Therefore, stations participating in a restricted TWT can ignore the quiet period corresponding to the restricted service period. In this case, the quiet period corresponding to the restricted service period represents a quiet period set to protect the restricted service period of the restricted TWT. Specifically, a station participating in a restricted TWT can regard the quiet period corresponding to the restricted service period as the restricted service period. An AP operating a restricted TWT does not need to set the quiet period to coincide with the restricted service period. This is because the quiet period in the quiet element is set in TU (time unit, 1024 us) units, and the TWT is set in 256 us units.

[0140] However, when a station accesses a channel in a quiet period other than a quiet period not set for a restricted service period, the quiet period not set for the restricted service period may be disturbed. For this reason, it is necessary to distinguish between a quiet period set for a restricted service period, i.e., a quiet period corresponding to the restricted service period. Therefore, a station participating in a restricted TWT may not be able to ignore a quiet period not corresponding to a restricted service period. A station cannot transmit at all in a quiet period not corresponding to a restricted service period. Specifically, a station participating in a restricted TWT may not be able to ignore a quiet period that does not overlap with a restricted service period. In a specific embodiment, a station participating in a restricted TWT may not be able to transmit at all in a quiet period that does not overlap with a restricted service period.

[0141] In addition, in the above embodiment, a station participating in a restricted TWT may consider a quiet period corresponding to a restricted service period if the start time of the restricted service period and the start time of the quiet period are within a predetermined time, and if the start time of the service period and the start time of the quiet period are within a predetermined time, this is because, as described above, an AP operating a restricted TWT does not need to set a quiet period to coincide with the restricted service period.

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

[0143] As mentioned above, channel access may be restricted during restricted service periods, and such restrictions may also be applied in relation to TXOP settings, as illustrated in FIG.

[0144] FIG. 13 illustrates how a station sets a TXOP taking into account 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 station that is a TXOP holder, may need to terminate the TXOP before the restricted service period begins. This is because if the TXOP holder's frame exchange continues even after the restricted service period begins, it may interfere with the transmission of low-latency traffic. In this case, the station may be a non-legacy station. In yet another specific embodiment, stations may be limited to stations that support restricted TWT. That is, stations with the value of the dot11RestrictedTWTOptionImplemented field set to false may not be subject to this restriction.

[0146] In particular embodiments, if a station that is a TXOP holder is transmitting low latency traffic, it may continue exchanging frames after the limited service period begins.

[0147] A specific method for a station to terminate a TXOP before the limited service period will now be described.

[0148] A station can set a TXOP based on the limited service period. Specifically, the station can set the end point of the TXOP to be before the start of the limited service period. In this case, the station can set the duration of the start frame that starts the frame exchange sequence to be before the start of the limited service period. For example, if the station successfully accesses the channel 3 ms before the start of the limited service period, the station can set the TXOP to be 3 ms before. The station can also end the TXOP by sending a CTS-to-Self frame. In this case, the station can send the CTS-to-Self frame at the basic transmission rate of 6 Mbps. This is because many legacy stations can receive frames when the station sends frames at the basic transmission rate.

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

[0150] Furthermore, a station that is not a TXOP holder can cancel the NAV set before the start of the restricted service period at the start of the restricted service period. In this case, the station may support 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 cancel the NAV set before the start of the restricted service period at the start of the restricted service period. However, if the station completes a frame exchange and the remaining duration of the TXOP is less than twice the sum of the time required to transmit the CF-End frame and the SIFS, the station does not need to transmit the CF-End frame. In this case, the station can consider the TXOP to have been released at the start of the restricted service period. Specifically, the station can consider the basic NAV to have been released at the start of the restricted service period.

[0151] In yet another particular embodiment, stations may be limited to those that participate in a restricted TWT.

[0152] In the embodiment of FIG. 13, the AP transmits a beacon frame including a TWT element to signal that a limited service period is being established. In the embodiment of FIG. 13(a), the station transmits an RTS frame to establish a TXOP. At this time, the station sets the value of the Duration field of the RTS frame to "until the end of 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 finally transmits a CTS-to-Self frame. In the embodiment of FIG. 13(b), the station transmits an RTS frame to establish a TXOP. At this time, the station sets the value of the duration field of the RTS frame without considering the limited service period. The station exchanges frames with the AP and completes the frame exchange before the start of the limited service period. At this time, the station finally transmits a CF-end frame to release the TXOP.

[0153] In conventional WLAN operation, exceptions to the TXOP rule define operations that can be transmitted beyond the TXOP limit. For example, retransmission of a single MPDU, 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 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 recognized even during a limited service period, the transmission of low-latency traffic may be delayed. Such exceptions to the TXOP limit must not be applied in violation of the limited service period.

[0154] If the end time of the TXOP and the start time of the restricted service period are within a predetermined time difference, the station can determine that the TXOP was obtained before the start of the restricted service period. The predetermined time may be 100 us. In yet another specific embodiment, if the end time of the TXOP is within the restricted service period, the station can determine that the TXOP was obtained before the start of the restricted service period.

[0155] As described above, a station may need to complete a frame exchange before the limited service period. Therefore, a station may not be allowed to start a frame exchange if the completion time of the frame exchange falls within the limited service period. In this case, the station may perform fragmentation to complete the frame exchange before the start of the limited service period.

[0156] Also, if low latency traffic is transmitted in a frame exchange performed by a station that is a TXOP holder, the station may continue the frame exchange even after the low latency service period begins.

[0157] A channel access procedure that takes into account the limited service period is illustrated in FIG.

[0158] FIG. 14 shows a station according to an embodiment of the present invention re-performing a channel access procedure taking into account a limited service period.

[0159] As described above, even if a station completes channel access before the restricted service period, if the frame exchange completion point is after the start of the restricted service period, the station can restart the channel access procedure without transmitting. At this time, the station can acquire the backoff counter value again. At this time, the station can use the same CW size used in the previous channel access procedure. That is, the station does not need to double the size of the CW used in the previous channel access procedure, nor does it need to initialize it to the minimum value that the CW can have. In addition, the station does not need to increase the number of retries, for example, the QSRC (QoS STA Retry Counter).

[0160] Also, if the station completes channel access within a pre-specified time from the start of the limited service period, the station can restart the channel access procedure without transmitting.

[0161] In the above embodiment, a station that wishes to transmit low latency traffic can start frame exchange after completing channel access even if the frame exchange completion time is after the start of the restricted service period. This exception may be allowed only if the station that wishes to transmit low latency traffic is a station participating in the restricted TWT.

[0162] Also, as described above, the station can operate as if the NAV is set for the AC of traffic other than the low-latency traffic. Therefore, the station can determine that the CCA result for the transmission of the AC of traffic other than the low-latency traffic is not idle (BUSY).

[0163] In the embodiment of FIG. 14, the AP transmits a beacon frame including a TWT element to signal that a limited service period is being established. The station's channel access backoff counter value reaches 0 before the start of the limited service period. The station determines that the frame exchange containing the traffic to be transmitted will be completed 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 may happen that all low-latency traffic transmission is completed before the end of the limited service period. In such a case, it may be inefficient for the low-latency service period to restrict the transmission of traffic other than low-latency traffic. Therefore, a method for early termination of the limited service period may be required. This will be explained using the example of FIG. 15.

[0165] FIG. 15 illustrates an operation of an AP prematurely terminating a limited service period according to an embodiment of the present invention.

[0166] For the AP to terminate the limited service period early, it must be able to determine that all low-latency traffic transmissions of stations participating in the limited TWT have been completed. To do this, stations participating in the limited TWT can signal whether they will transmit more low-latency traffic in the frames they transmit. Specifically, the station can signal that it will transmit more 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 limited service period is 1, the More data subfield indicates that additional low-latency traffic is required, but does not need to indicate whether additional traffic other than low-latency traffic is required. For example, if a station participating in the limited TWT does not store low-latency traffic in its transmit buffer and only stores traffic other than low-latency traffic, the station can set the value of the More data subfield in the Frame Control field of the frame it transmits during the limited service period to 0. The AP can terminate a limited service period early based on whether the station participating in the limited TWT does not have a 0 in the More data subfield of the Frame Control field of the frame in the limited service period. Specifically, the AP can terminate limited service early if there is no low-latency traffic to send in the AP's transmit buffer and the station participating in the limited TWT does not have a 0 in the More data subfield of the Frame Control field of the frame in the limited service period.

[0167] The AP can terminate the limited service period early by transmitting 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 MAC address or BSSID of the AP. In addition, the AP can 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 transmitting a pre-specified management frame.

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

[0169] As described above, a quiet period for the limited service period may be set to protect the limited service period from legacy wireless communication terminals. In this case, the AP can transmit a CF-End frame to end the limited service period. When the AP transmits the CF-End frame, it can also cancel the quiet period set for legacy stations.

[0170] In the above-described embodiment, the CF-End frame may have a Frame Control field whose Type is a control frame (Type value B3 B2==01) and whose Subtype is a CF-End frame (Subtype value B7 B6 B4 B4==1110).

[0171] When a quiet interval for a restricted service period is configured, a station participating in the restricted TWT may not be allowed to transmit a CF-End frame during the restricted service period. In a specific embodiment, a station participating in the restricted TWT may not be allowed to transmit a CF-End frame during a quiet interval corresponding to the restricted service period. This is because when a station participating in the restricted TWT transmits a CF-End frame, the NAV set for the legacy station is canceled. However, as described above, if the CF-End frame is used to terminate the restricted service period early, the AP may transmit a CF-End frame during the restricted service period.

[0172] In the embodiment of FIG. 15, an AP transmits a beacon frame including a TWT element and a Quiet element. Stations supporting restricted TWT determine that a restricted service period has been established, while stations not supporting restricted TWT determine that a quiet interval has been established. When the AP determines that all low-latency traffic transmissions within the restricted service period have been completed, the AP transmits a CF-End frame to prematurely terminate the restricted service period and cancel the quiet interval established for legacy stations. At this time, stations supporting restricted TWT determine that the channel access restrictions applied during the restricted service period have been lifted. Specifically, as described above, when the embodiment in which a NAV is established during a restricted service period is applied, stations supporting restricted TWT can determine that the NAV for the restricted service period has been released. Furthermore, stations not supporting restricted TWT that receive the CF-End frame cancel their NAV.

[0173] As described above, each station included in the multilink device can associate with other stations. Therefore, each station included in the multilink device can operate an individual TWT service period. That is, an individual TWT service period may be operated on each of the multiple links on which the multilink device operates. In order for such individual TWT service periods to be operated, an individual TWT agreement may be required. To this end, a station in the multilink device transmits a TWT request frame, and a station that receives the TWT request frame can transmit a TWT response frame. The TWT request frame may be a TWT setup frame with a Command field value of 0 to 2. The TWT response frame may be a TWT setup frame with a Command field value of 3 to 7. The specific TWT agreement method may be the same as that defined in IEEE 802.11ax.

[0174] TWT operation allows stations to save power. Therefore, to improve power saving efficiency, a multilink device can set TWT service periods for 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 for the first link on which the first station operates and the second link on which the second station operates, thereby synchronizing the operating states (awake state, doze state) of the first station and the second station. In this case, the first station can transmit a TWT request frame to the first AP to which the first station is associated, and the second station can transmit a TWT request frame to the second AP to which the second station is associated. In this case, the TWT parameter values ​​indicated in the TWT request frame transmitted by the first station and the TWT request frame transmitted by the second station may be identical. Therefore, transmitting TWT request frames individually on multiple links may reduce transmission efficiency. In a specific embodiment of the present invention, a TWT request frame transmitted on one link can perform TWT agreement for multiple links. This will be described with reference to FIG. 16.

[0175] FIG. 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 over multiple links may be transmitted over a first link. In this case, the TWT request frame may include TWT parameters for TWT operations performed over the multiple links. Also, a TWT request frame for TWT agreement performed over a second link may be transmitted over the first link. In this case, the TWT request frame may include TWT parameters for TWT operations performed over the second link. For example, when a multilink device includes a first station operating over the first link and a second station operating over the second link, the first station can establish a TWT agreement for the second station. In this case, when the first station is associated with a first AP and the second station is associated with a second AP, and the first AP and the second AP are included in one multilink device, the first station can establish a TWT agreement with the first AP. This is because stations included in the multilink device can share some MAC layer functions or information. A new format of the TWT element may be required for the TWT agreement operation described above.

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

[0178] The aforementioned bitmap can be called a Link ID (identifier) ​​bitmap. The size of the Link ID bitmap can be two octets. For example, if the value of the Link ID bitmap is 1110 0000 0000 0000 2bIn this case, the Link ID bitmap may indicate TWT negotiation 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 may be transmitted containing information about TWT parameters for only links other than the link for which the link element is transmitted. Also, in such an embodiment, an element for one link may be transmitted for TWT negotiation across multiple links.

[0179] The TWT element may also include a TWT flow ID indicating an identifier applied to the TWT agreement. When the TWT element is used for TWT agreement across multiple links, the TWT flow ID included in the TWT element may be a value that is not used in TWT agreements across all links for which the TWT element may perform TWT agreement. In yet another specific embodiment, when the TWT element is used for TWT agreement across multiple links, the TWT element may include a field for indicating multiple TWT flow IDs. For example, when the TWT element is used for TWT agreement across multiple links, the TWT element may include multiple subfields indicating multiple TWT flow IDs, respectively. In this case, the multiple subfields may correspond to multiple links for which the TWT element may perform TWT agreement. In these embodiments, a TWT flow ID not used by the link corresponding to each subfield may be used. When the TWT element attempts to change the TWT agreement of a link corresponding to a subfield, a TWT flow ID previously used by the link corresponding to the subfield may be used in the subfield. This is because there is already a TWT agreement using the TWT flow ID. Therefore, when a station attempts to perform a new TWT agreement, the station may be restricted to using a TWT flow ID for the TWT agreement that does not correspond to a TWT flow ID of an existing TWT agreement. In this case, when a station attempts to change an existing TWT agreement, the station may use a TWT flow ID for the TWT agreement that corresponds to the TWT agreement to be changed.

[0180] 16(a) shows the format of a TWT element according to an embodiment of the present invention. The 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 a specific format of the control field of a TWT element. The Control field includes an NDP Paging Indicator field, a Responder PM Mode field, a Negotiation Type field, a TWT Information Frame Disabled field, a Wake Duration Unit field, a Link ID Bitmap Present field, and a Reserved field. Compared to the TWT element defined in IEEE 802.11ax, Figure 16(b) further includes a Link ID Bitmap Present field. Here, the Link ID Bitmap Present field indicates whether 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 a Link ID bitmap. If the value of the Link ID Bitmap Present field is 0, the TWT element does not include a Link ID bitmap. A station receiving a TWT element can determine whether the TWT element includes a 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 the TWT element. The Individual TWT Parameter Set field included in the TWT element may include a Request Type field, a Target Wake Time field, a TWT Group Assignment field, a Nominal Minimum TWT Wake Duration field, a TWT Wake Interval Mantissa field, a TWT Channel field, an NDP Paging field, and a Link ID Bitmap field. Figure 16(b) further includes a Link ID Bitmap field in addition to the Individual TWT Parameter Set field defined in IEEE 802.11ax. If the TWT element includes a Link ID Bitmap field, it may indicate that the TWT request is for the link indicated by the Link ID Bitmap field. If the TWT request frame includes a TWT element and the TWT element includes a Link ID Bitmap field, a 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] 16(d) shows a 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 including the TWT element. In this case, the TWT Flow ID may be set according to the above-described embodiment.

[0184] FIG. 17 illustrates how a multi-link device according to an embodiment of the present invention performs TWT agreement.

[0185] The AP multilink device includes a first AP (AP1), a second AP (AP2), and a third AP (AP3). The non-AP multilink device includes a first station (STA1), a second station (STA2), and a third station (STA3). The first AP (AP1), the second AP (AP2), and the third AP (AP3) operate on a first link (Link1), a second link (Link2), and a third link (Link3), respectively. The first station (STA1), the second station (STA2), and the third station (STA3) operate on a first link (Link1), a second link (Link2), and a third link (Link3), respectively. The non-AP multilink device can transmit a TWT request frame to perform TWT agreement on the first link (Link1) to the third link (Link3). In this case, the TWT request frame may include one TWT element. Specifically, if a non-AP multilink device wishes to operate a TWT service period in which the same TWT parameters are used, the TWT request frame may include one TWT element.

[0186] Specifically, the TWT element can indicate the start and end points of a TWT service period. The TWT element may also include a Link ID bitmap, as described with reference to Fig. 16. Specifically, the TWT element can indicate a first link (Link 1), a second link (Link 2), and a third link (Link 3) in the Link ID Bitmap subfield.

[0187] Since the Link ID Bitmap subfield of the TWT element of the received TWT request frame indicates the first link (Link 1), the second link (Link 2), and the third link (Link 3), 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 (Link 1), the second link (Link 2), and the third link (Link 3).

[0188] The AP multilink device can send a TWT response frame to the non-AP multilink device to accept the TWT setup. At this time, TWT agreements are established for each of the first link (Link 1) to the third link (Link 3). At this time, the TWT agreements for each link can indicate a TWT agreement between the first station (STA1) and the first AP (AP1), a TWT agreement between the second station (STA2) and the second AP (AP2), and a TWT agreement between the third station (STA3) and the third AP (AP3).

[0189] FIG. 18 illustrates a station included in a multilink device performing TWT negotiation for another station included in the multilink device in which the station is included, according to an embodiment of the present invention.

[0190] As described above, a TWT request frame for TWT agreement over the second link may be transmitted over the first link. To this end, a first station operating over the first link may transmit a TWT request frame over the first link. In this case, the TWT element of the TWT request frame may include a TWT Link ID bitmap, which may indicate the second link. The first AP operating over the first link may determine, based on the TWT Link ID bitmap, that the TWT request frame was transmitted for TWT agreement over the second link.

[0191] In the embodiment of FIG. 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). The first AP (AP1) and the second AP (AP2) operate on a first link (Link1) and a second link (Link2), respectively. The first station (STA1) and the second station (STA2) operate on a first link (Link1) and a second link (Link2), respectively. The first station (STA1) transmits a TWT request frame for TWT agreement on the second link (Link2) on the first link (Link1). The first AP (AP1) transmits a TWT response frame to the first station (STA1) to accept the TWT agreement on the second link (Link2). 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 is different from the station to which the TWT agreement applies. Also, as mentioned above, although the station that sent the TWT request frame is a single station, the TWT agreement may apply to multiple stations. Therefore, the station that can cancel the TWT agreement may become an issue.

[0193] In the existing TWT operation, a 3-bit TWT Flow ID and the MAC addresses of the two stations that have made the TWT agreement may be used to identify the TWT agreement. Specifically, the TWT agreement can be identified by the MAC address of the TWT requesting station, the MAC address of the TWT responding station, and the TWT Flow ID. As described above, the TWT agreement established by the 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 differ. For example, in the embodiments of FIGS. 17 and 18, the TWT requesting station is the first station and the TWT responding station is the first AP. However, in the embodiment of FIG. 17, the TWT agreement applies to the first station and the first AP, the second station and the second AP, and the third station and the third AP. In the embodiment of FIG. 18, the TWT agreement applies to the second station and the second AP. 17, one TWT Flow ID may be applied to the first station and the first AP, the second station and the second AP, and the third station and the third AP. Therefore, the TWT agreement cannot be identified. To solve this problem, the following embodiment can be applied.

[0194] A station that can cancel the TWT agreement may be a station to which the TWT agreement applies. To this end, the TWT requesting station may not be a station that transmitted a TWT request frame, but may be a station operating on a link to which the TWT agreement applies. Specifically, the TWT requesting station may be a station operating on a link to which the TWT agreement applies, among the stations of the multi-link device that transmitted the TWT request frame. Furthermore, the TWT responding station may not be a station that transmitted a TWT response frame, but may be a station operating on a link to which the TWT agreement applies. Specifically, the TWT responding station may be a station operating on a link to which the TWT agreement applies, among the stations of the multi-link device that transmitted a TWT response frame.

[0195] In addition, the following embodiment may be applied as a method for identifying the TWT agreement.

[0196] In a specific embodiment, a TWT agreement may be identified based on a link ID. Specifically, a TWT agreement may be identified based on a TWT Flow ID, a MAC address of a TWT requesting station, a MAC address of a TWT responding station, and an ID of a link to which the TWT agreement applies. In the example of FIG. 17, a first TWT agreement established between a first station and a first AP may be identified by a TWT Flow ID, a MAC address of the first station, a MAC address of the first AP, and an ID of the first link. A second TWT agreement established between a second station and a second AP may be identified by a TWT Flow ID, a MAC address of the first station, a MAC address of the first AP, and an ID of the second link. A third TWT agreement established between a third station and a third AP may be identified by a TWT Flow ID, a MAC address of the first station, a MAC address of the first AP, and an ID of the third link. In a specific embodiment, a TWT Flow ID may be set for each link.

[0197] Furthermore, the TWT agreement may be considered to be made for each multilink device. Therefore, to identify the 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 responding multilink device may be used instead of the MAC address of the TWT responding station. In the embodiment of FIG. 17 , the first TWT agreement established between the first station and the first AP may be identified by a TWT Flow ID, a MAC address of the non-AP multilink device, a MAC address of the AP multilink device, and an ID of the first link. The second TWT agreement established between the second station and the second AP may be identified by a TWT Flow ID, a MAC address of the non-AP multilink device, a MAC address of the AP multilink device, and an ID of the second link. The third TWT agreement established between the third station and the third AP may be identified by a TWT Flow ID, a MAC address of the non-AP multilink device, a MAC address of the AP multilink device, and an ID of the third link. Depending on the specific embodiment, the TWT Flow ID may be set for each link. According to a specific embodiment, a TWT Flow ID may be set for each link.

[0198] Furthermore, the TWT requesting station may not be the station that transmitted the TWT request frame but may be a station operating on a link to which the TWT agreement applies. Specifically, the TWT requesting station may be a station in the multi-link device that transmitted the TWT request frame but operates on a link to which the TWT agreement applies. Furthermore, the TWT responding station may not be the station that transmitted the TWT response frame but may be a station operating on a link to which the TWT agreement applies. Specifically, the TWT responding station may be a station in the multi-link device that transmitted the TWT response frame but operates on a link to which the TWT agreement applies. In the embodiment of FIG. 17 , the first TWT agreement established between the first station and the first AP may be identified by a TWT Flow ID, a MAC address of the first station, and a MAC address of the first AP. The second TWT agreement established between the second station and the second AP may be identified by a TWT Flow ID, a MAC address of the second station, and a MAC address of the second AP. A third TWT agreement established between the third station and the third AP may be identified by a TWT Flow ID, a MAC address of the third station, and a MAC address of the third AP. According to a specific embodiment, the TWT Flow ID may be set for each link.

[0199] Furthermore, the TWT agreement may be identified based on the link through which the TWT request frame is transmitted. Specifically, the 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 responding station, and the ID of the link through which the TWT request frame is transmitted. In the embodiment of FIG. 17 , the first TWT 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 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 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. Depending on the specific embodiment, the TWT Flow ID may be set for each link.

[0200] The method by which the multilink device sets up a TWT agreement has been described above. The method by which the multilink device tears down a TWT agreement will now be described with reference to FIG.

[0201] FIG. 19 illustrates an operation of the multi-link device according to an embodiment of the present invention to release the TWT agreement.

[0202] In an embodiment of the present invention, a multi-link device can terminate a TWT agreement applied to multiple links via one link. In a conventional WLAN, a station transmits a TWT release frame to terminate a TWT agreement. The TWT release frame can be transmitted by a TWT request station or a TWT responder station. The TWT release frame includes a TWT Flow Identifier field indicating a TWT Flow ID. The TWT Flow Identifier field can be a 3-bit field. When a station to which a TWT agreement applies receives the TWT release frame, the station can terminate the TWT agreement corresponding to the TWT Flow ID indicated by the TWT release frame. When the TWT release frame is successfully transmitted, the station that transmitted the TWT release frame can terminate the TWT agreement corresponding to the TWT Flow ID indicated by the TWT release frame. Therefore, the station that terminates the TWT agreement and the TWT agreement to be terminated can be identified based on the MAC address of the sender of the TWT release frame, the MAC address of the receiver of the TWT release frame, and the TWT Flow ID.

[0203] However, as described above, when a TWT agreement is established among stations in a multi-link device, the station that transmitted the TWT request frame may be different from the station to which the TWT agreement applies. Also, as described above, the station that transmitted the TWT request frame may be a single station, but the TWT agreement may apply to multiple stations. Therefore, a TWT agreement cancellation method that can be applied in such cases is required.

[0204] The TWT release frame may include information regarding a link identifier. In this case, a station in the multilink device can release at least one of the multiple TWT agreements based on the link identifier, e.g., link ID, indicated by the TWT release frame. Specifically, when a station in the multilink device operates on a first link and releases a TWT agreement made on a second link, the station can transmit a TWT release frame including information regarding the link identifier on the first link. In these embodiments, the link identifier may be the identifier of the link to which the TWT agreement to be released applies. For example, the TWT release frame may include a TWT Flow Identifier field indicating a TWT Flow ID and a Link ID field indicating the identifier of the link to which the TWT agreement to be released applies. Alternatively, the TWT release frame may include one Link ID field. Alternatively, the TWT release frame may include multiple Link ID fields. Therefore, the format of a TWT release frame transmitted by a station included in the multilink device may differ from the format of a TWT release frame transmitted by a station not included in the multilink device. In yet another specific embodiment, the format of the TWT release frame transmitted by a station included in the multilink device may be the same as the format of the TWT release 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 via the first link and the second multilink device successfully receives the TWT release frame, the first and second multilink devices can cancel the TWT agreement established between them, which corresponds to the TWT Flow ID indicated in the TWT release frame. At this time, the first and second multilink devices can cancel the TWT agreement established between them, which corresponds to information related to the link indicated in the TWT release frame. Specifically, the first and second multilink devices can cancel the TWT agreement established between them, which corresponds to the TWT Flow ID indicated in the TWT release frame and information related to the link indicated in the TWT release frame.

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

[0207] Furthermore, when a TWT agreement is established for multiple links using one TWT element, the TWT agreements established for the multiple links may be terminated using one TWT termination frame. In this case, the TWT parameters of the TWT agreements established for the multiple links may be the same. Furthermore, the TWT Flow IDs of the TWT agreements established for the multiple links may be the same. For example, when a TWT agreement is established for the first to third links between a first multilink device and a second multilink device at the same time using, for example, one TWT element, the first or second multilink device can transmit a TWT termination frame for any one of the first to third links to terminate the TWT agreement established for the first to third links.

[0208] The AP multilink device includes a first AP (AP1), a second AP (AP2), and a third AP (AP3). The non-AP multilink device includes a first station (non-AP STA1), a second station (non-AP STA2), and a third station (non-AP STA3). The first AP (AP1), the second AP (AP2), and the third AP (AP3) operate on a first link (Link1), a second link (Link2), and a third link (Link3), respectively. The first station (non-AP STA1), the second station (non-AP STA2), and the third station (non-AP STA3) operate on a first link (Link1), a second link (Link2), and a third link (Link3), respectively. A first station (non-AP STA1) is associated with a first AP (AP1), a second station (non-AP STA2) is associated with a second AP (AP2), and a third station (non-AP STA3) is associated with a third AP (AP3). A TWT agreement is established between the first station (non-AP STA1) and the first AP (AP1), with the TWT Flow ID of the TWT agreement being x. A TWT agreement is established between the second station (non-AP STA2) and the second AP (AP2), with the TWT Flow ID of the TWT agreement being y. A TWT agreement is established between the third station (non-AP STA3) and the third AP (AP3), with the TWT Flow ID of the TWT agreement being z.

[0209] At this time, the non-AP multilink device transmits a TWT Cancel frame to cancel the TWT agreement between the first station (non-AP STA1) and the first AP (AP1) and the TWT agreement between the third station (non-AP STA3) and the third AP (AP3). At this time, the TWT Cancel 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 for the TWT cancellation frame to the non-AP multilink device. The AP multilink device then cancels the TWT agreement between the first station (non-AP STA1) and the first AP (AP1), and the TWT agreement between the third station (non-AP STA3) and the third AP (AP3). The non-AP multilink device receives the ACK for the TWT cancellation frame. The non-AP multilink device then cancels the TWT agreement between the first station (non-AP STA1) and the first AP (AP1), and the TWT agreement between the third station (non-AP STA3) and the third AP (AP3).

[0211] The TWT elements for establishing and releasing TWT agreements according to the above-described embodiment will be described with reference to FIG.

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

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

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

[0215] The TWT Setup Command subfield may 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 set to 0 to 7, the TWT Setup Command subfield may indicate that the TWT element including 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 setting of the conventionally used TWT Setup Command subfield.

[0216] If the value of the Trigger subfield is 1, the Trigger subfield may indicate that one or more trigger frames are to be transmitted during the TWT service period if a TWT agreement is established by the TWT element.

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

[0218] The Flow Type subfield indicates the interaction method between the TWT request station and the TWT responder station during the TWT service period. The value of the Flow Type subfield may be set to the same value as the Flow Type subfield defined in the conventional WLAN standard.

[0219] The TWT Flow Identifier subfield indicates an ID value for distinguishing TWT agreements. In conventional WLAN standards, a TWT element includes only one TWT Flow Identifier subfield. However, as described above, when a TWT agreement is established for multiple links using one TWT element, the TWT element may include 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 multiple links.

[0220] The TWT wake interval subfield indicates the average interval between TWT service periods configured 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 the conventional WLAN standard.

[0221] If the value of the TWT protection subfield is 1, the TWT protection subfield indicates that the TWT requesting station requests the TWT responding station to support protection for the TWT service period. In this case, the protection method for the TWT service period may be the same as that defined in the conventional WLAN standard.

[0222] The Target Wake Time field, TWT Group Assignment field, Nominal Minimum TWT Wake Duration field, TWT Wake Interval Maximum field, TWT Channel field, and NDP Paging field of the Individual TWT Parameter Set field may be set to the same as defined in conventional WLAN standards.

[0223] The Individual TWT Parameter Set field may include a Link ID Bitmap subfield, as in the embodiment described with reference to FIG. 16. If the Link ID Bitmap subfield indicates multiple links, the TWT element may request TWT agreement for multiple links. In this case, if TWT agreement is established for multiple links, TWT service periods with the same TWT parameters may be applied to the multiple links.

[0224] Furthermore, even if a TWT agreement is established for multiple links by one TWT element, the multiple TWT agreements established for the multiple links may have different TWT Flow IDs. This is because the TWT agreements are established at once but applied to different links and to different stations and APs. A TWT element may include multiple TWT Flow Identifier fields. Specifically, a TWT element may include multiple TWT Flow Identifier fields corresponding to the multiple links to which the TWT agreement applies. In this case, the number of TWT Flow Identifier fields included in a 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 including a Link ID Bitmap subfield may include two TWT Flow Identifier fields. The first TWT Flow Identifier subfield among the multiple TWT Flow Identifier fields included in a TWT element may be the TWT Flow ID included in the Request Type field. The remaining subfields other than the first TWT Flow Identifier subfield may be included in another field of the TWT element, such as the Additional TWT Flow ID field in FIG. 20. Also, the first TWT Flow Identifier subfield may indicate the TWT Flow ID of the TWT agreement established for the link over which the TWT request frame is transmitted. The remaining TWT Flow Identifier subfields other than the first TWT Flow Identifier subfield may indicate the TWT Flow ID of the TWT agreement established for the remaining links over which the TWT agreement is established, other than the link over which the TWT request frame is transmitted. As described above, the remaining links over which the TWT agreement is established, other than the link over which the TWT request frame is transmitted, may be indicated by the Link ID Bitmap subfield.Furthermore, the remaining TWT Flow Identifier subfields other than the first TWT Flow Identifier subfield may be mapped to links in the order of Link ID value size. Among the remaining TWT Flow Identifier subfields other than the first TWT Flow Identifier subfield, the first subfield may be mapped to the link with the smallest Link ID value among the remaining links other than the link through which the TWT request frame is transmitted, the second subfield may be mapped to the link with the second smallest Link ID value among the remaining links other than the link through which the TWT request frame is transmitted, 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 through which the TWT request frame is transmitted.

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

[0226] FIG. 21 illustrates the format of the remaining TWT Flow Identifier subfields other than the first TWT Flow Identifier subfield according to an embodiment of the present invention.

[0227] As described 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 WLAN, the maximum number of TWT agreements that a station can establish is eight. Therefore, in a conventional WLAN, the TWT Flow Identifier subfield is a 3-bit field. If the maximum number of TWT agreements that a multi-link device can establish is eight, the TWT Flow Identifier subfield may be a 3-bit field. Furthermore, the Additional TWT Flow ID field may include one or more subfields having a size of 3 bits. If a TWT element requests n TWT agreements, the Additional TWT Flow ID field may include n-1 3-bit subfields. In this case, as described above, the first TWT Flow Identifier subfield may be the TWT Flow ID included in the Request Type field. In yet another specific embodiment, if a TWT element requests n TWT agreements, the Additional TWT Flow ID field may include n 3-bit subfields. Also, the Additional TWT Flow ID field may include a reserved field so that the TWT Parameter Set field has a length in octets. Such an embodiment is shown in Figure 21(a).

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

[0229] Also, if the Additional TWT Flow ID field indicates an odd number of TWT Flow IDs, the last octet included in the Additional TWT Flow ID field may indicate one TWT Flow ID, and the remaining 5 bits may be set as a reserved field. Such an embodiment is shown in Figure 22(b).

[0230] In the above embodiment, the size of the TWT Flow ID subfield is 3 bits, but the above embodiment may also be applied to a case where the size of the TWT Flow ID subfield is 4 bits.

[0231] As mentioned above, one TWT element can request TWT agreements on multiple links. Therefore, it is necessary to transmit additional information required for this. This will be explained using Figure 22.

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

[0233] When one TWT element requests TWT agreement for multiple links, the additional information required may include a Link ID Bitmap, which indicates the links on which the TWT agreement is made, and an Additional TWT Flow Identifier field, which is the TWT Flow ID corresponding to the TWT agreement. However, when a station in a multi-link device transmits a TWT request frame to a station to which it is associated, the TWT element included in the TWT request frame may not include such additional information. The TWT element may include a field indicating whether to include 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 to include the Link ID Bitmap field and the Additional TWT Flow Identifier field.

[0234] If the TWT element sent by the TWT requesting station includes a Link ID Bitmap subfield, the TWT requesting 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, the TWT responding 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 multiple links or on a link different from the link on which the TWT request frame containing the TWT element was sent.

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

[0236] In another specific embodiment, the Additional TWT Flow ID Present subfield may be omitted. In this case, the TWT responding station receiving the TWT element can determine whether the TWT element includes the Additional TWT Flow ID subfield based on the Link ID Bitmap subfield. Also, the TWT responding station receiving the TWT element can determine the size of the Additional TWT Flow ID subfield included in the TWT element based on the Link ID Bitmap subfield.

[0237] As described above, a multi-link device can transmit a TWT release frame on a first link to release a TWT agreement that applies to a second link, and a multi-link device can transmit a TWT release frame on one link to release a TWT agreement that applies to multiple links.

[0238] Similarly, the TWT release frame may include additional information in the TWT release frame in a conventional WLAN. This will be described with reference to FIG.

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

[0240] A TWT release frame transmitted by a multilink device may be defined as a new action frame. For ease of explanation, a TWT release frame transmitted by a multilink device is referred to as an MLD TWT release frame. The MLD TWT release frame may be specified as having Unprotected S1G as the category in the Action field. A value of the Unprotected S1G Action field that is not used in conventional WLANs may be assigned to the MLD TWT release frame. For example, as in the embodiment of FIG. 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 to 22 and the Unprotected S1G Action field value to 12 in the action frame.

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

[0242] The MLD TWT Flow field may be indicated by the Action field of other categories as well as the Unprotected S1G category. For example, an MLD TWT release frame may be transmitted in the Protected Action frame format of the S1G category. In this case, the Action field of the S1G category action frame may include the MLD TWT Flow field.

[0243] The TWT release frame may be used in a format different from the action frame described in this embodiment, and a frame other than the action frame may be used as the TWT release frame. A specific format of the MLD TWT Flow field will be described with reference to FIG.

[0244] FIG. 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 having a variable length. Specifically, the MLD TWT Flow field may include a variable-length field indicating a TWT Flow ID corresponding to the TWT agreement to be released by the MLD TWT Release frame. In a specific embodiment, the MLD TWT Flow field may include an MLD TWT Flow Control field having a fixed length and an MLD TWT Flow IDs field having a variable length. The MLD TWT Flow Control field may be a one-octet field. Furthermore, the MLD TWT Flow Control field may indicate information for parsing the MLD TWT Flow IDs field. Specifically, the MLD TWT Control field may indicate information regarding the size of the MLD TWT Flow IDs field. The MLD TWT Flow IDs field may indicate a TWT Flow ID corresponding to the TWT agreement to be released. Furthermore, the MLD TWT Flow IDs field may 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 FIG. 24(a).

[0246] The MLD TWT Flow Control field may include a field indicating the length of the MLD TWT Flow IDs field. In this case, this field may be referred to as the Length of MLD Flow IDs field. The Length of MLD Flow IDs field may indicate the length of the MLD TWT Flow IDs field in 1-octet units. 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 this embodiment is shown in FIG. 24(b).

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

[0248] The MLD TWT Flow IDs field may include a 3-bit TWT Identifier subfield, a 4-bit Link ID field, and a 1-bit Teardown All TWT subfield, repeated every octet. In this case, the consecutive TWT Identifier subfield and Link ID field can identify the TWT agreement to be 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] In addition, the Teardown All TWT subfield may indicate that all TWT agreements related to the link corresponding to the Teardown All TWT subfield are released. In this case, the link corresponding to the Teardown All TWT subfield is the link corresponding to the Link Id field included in the same octet as the Teardown All TWT subfield. In addition, if the value of the Teardown All TWT subfield is 1, the TWT Identifier subfield may be set as a reserved field. An MLD TWT Flow IDs field according to this embodiment is shown in FIG. 24(e).

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

[0251] In yet another specific embodiment, the MLD TWT Flow IDs field may include multiple consecutive TWT Identifier subfields, multiple consecutive Link ID fields, and multiple consecutive Teardown All TWT subfields. In such an embodiment, the TWT Identifier subfields and Link ID fields in the same order can identify the TWT agreement to be terminated 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 to be terminated 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 to be terminated by the MLD TWT Release frame. At least one of the number of TWT Flow Identifier subfields, the number of Link ID subfields, and the number of Teardown All TWT subfields included in the MLD TWT Flow IDs field may be proportional to the size of the MLD TWT Flow IDs field. Furthermore, the Teardown All TWT subfields and the 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. Furthermore, the Teardown All TWT subfields and the TWT Flow Identifier subfields 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 yet another specific embodiment, the MLD TWT Cancellation frame may include a Link ID bitmap for indicating multiple links. This may have the same format as the Link ID Bitmap field included in the TWT element described above. Additionally, the MLD TWT Cancellation frame may include a bitmap for signaling information for canceling multiple TWT agreements. This will be described with reference to FIG. 25.

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

[0254] As described 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 FIG. 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 this embodiment is shown in FIG. 25(a).

[0255] The MLD TWT Control field may include a subfield indicating information related to the size of the MLD TWT Bitmap field. This subfield is called the Length of Bitmap subfield. The Length of Bitmap field can indicate the size of the MLD TWT Bitmap field in units of 3 octets. For example, if the size of the MLD TWT Bitmap field is 9 octets, the value of the Length of Bitmap field may be set to 3 or 2. The Length of Bitmap subfield may be a 3-bit field. In this case, the number of lengths that the MLD TWT Bitmap field can have 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 this embodiment is shown in FIG. 25(b).

[0256] As described in FIG. 24, the MLD TWT Flow Control field may include a subfield indicating that all TWT agreements established between the multilink device transmitting the MLD TWT release frame and the multilink device receiving the MLD TWT release frame are to be terminated. Such a subfield is called the Teardown All TWT of All Link field. When the multilink device intends to terminate all TWT agreements established with the recipient of the MLD TWT release frame, the multilink device may set the value of the Teardown All TWT of All Link subfield of the MLD TWT release frame to 1. When an MLD TWT release frame with the Teardown All TWT of All Link subfield set to 1 is successfully received, all TWT agreements established between the multilink device transmitting the MLD TWT release frame and the multilink device receiving the MLD TWT release frame are terminated. When the Teardown All TWT of All Link subfield is set to 1, the Length of TWT Bitmap field may be set as a reserved field. Therefore, the MLD TWT Flow field does not need to include the TWT Bitmap field when the Teardown All TWT of All Link subfield is set to 1. A TWT Flow Control field according to such an embodiment is shown in Figure 25(c).

[0257] The TWT Bitmap field may include a 1-octet TWT Flow ID Bitmap subfield and a 2-octet Link ID Bitmap subfield, repeated every 3 octets. A TWT Bitmap field according to such an embodiment is shown in FIG. 25(d). The TWT Flow ID Bitmap subfield may indicate the TWT Flow ID corresponding to the TWT agreement that the TWT Release frame intends to release. When the MLD TWT Release frame releases a TWT agreement whose TWT Flow ID is 1 to 3, the TWT Flow ID Bitmap subfield is set to 1110 0000. 2b In this case, the TWT Flow ID values ​​1 to 8 are mapped to the first to eighth bits of the TWT Flow ID Bitmap subfield. In addition, the Link ID Bitmap subfield can indicate the link ID of the link corresponding to the TWT agreement that the TWT release frame intends to release. When the MLD TWT release frame releases the TWT agreement established for the link whose Link ID is 1 to 3, the Link ID Bitmap subfield is set to 1110 0000. 2b In this case, the Link ID values ​​1 to 8 are mapped to the first to eighth bits of the Link ID Bitmap subfield, respectively. Also, as described above, the TWT Flow ID may be indicated by three bits. Therefore, the TWT Flow ID Bitmap can indicate one TWT Flow ID value in a three-bit field. In this case, five bits of the TWT Flow ID Bitmap subfield may be a reserved field. A TWT Bitmap field according to this embodiment is shown in FIG. 25(e).

[0258] In yet another specific embodiment, the TWT Bitmap field may include consecutive TWT Flow ID Bitmap subfields and consecutive Link ID Bitmap subfields, and 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 to be released by the TWT release frame 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 above-mentioned MLD TWT Cancellation frame is not a TWT Cancellation frame used in conventional WLANs, but a newly defined frame for canceling a TWT agreement established between multi-link devices. This section describes a method for canceling a TWT agreement established between multi-link devices using a conventional TWT Cancellation frame. Specifically, the following methods are described: 1) a method for canceling all TWT agreements established on the link where the TWT Cancellation frame is transmitted; 2) a method for canceling all TWT agreements established on a specific link; 3) a method for canceling a TWT agreement corresponding to a specific TWT Flow ID on all links; and 4) a method for canceling all TWT agreements established on all links.

[0261] FIG. 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 release frame includes a one-octet TWT Flow field. The first to third bits (B0-B2) of the TWT Flow field are a TWT Flow Identifier subfield that indicates the TWT Flow ID. The fourth to fifth bits (B3-B4) of the TWT Flow field are a Reserved subfield. The sixth to seventh bits (B5-B6) of the TWT Flow field are a Negotiation Type subfield that indicates the negotiation type. The sixth to eighth bits (B7) of the TWT Flow field may be set as a Teardown All TWT subfield. The Teardown All TWT subfield may indicate an attempt to release all TWT agreements established between the station transmitting the TWT release frame and the station receiving the TWT release frame. The format of the TWT Flow field described above may be when the Negotiation Type subfield is set to 0 or 1. If the value of the Teardown All TWT subfield is 1, the TWT Flow Identifier subfield may be set as a reserved field and the value of the TWT Flow Identifier subfield may be set to 0.

[0263] First, a method for canceling all TWT agreements established on the link through which the TWT release frame is transmitted will be described. To signal the cancellation of all TWT agreements established on the link through which the TWT release frame is transmitted, the Teardown all TWT subfield (B7) of the TWT release frame may be set to 1, and 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 reserved fields. The format of the TWT Flow field according to this embodiment is shown in FIG. 26(a). When the Teardown all TWT subfield of the TWT Flow field has a value of 1 and the Teardown Type subfield has a value of 0, the multilink device that transmitted and the multilink device that received the TWT release frame including the TWT Flow field can cancel all TWT agreements established on the link through which the TWT release frame is transmitted, among all TWTs established between the two multilink devices.

[0264] A method for canceling all TWT agreements established on a specific link will now be described. To signal the cancellation of all TWT agreements established on a specific link, the Teardown all TWT subfield (B7) of the TWT Cancellation frame may be set to 0 and the Teardown Type subfield (B4) may be set to 1. In this case, the first to fourth bits (B0-B3) of the TWT Flow field may be set as a Link ID field indicating the link corresponding to the TWT agreement to be cancelled by the TWT Cancellation frame. The format of the TWT Flow field according to this embodiment is shown in FIG. 26(b). When the Teardown all TWT subfield of the TWT Flow field is set to 0 and the Teardown Type subfield is set to 1, the multilink device that transmitted the TWT Cancellation frame including the TWT Flow field and the multilink device that received the frame can cancel all TWT agreements established on the link indicated by the Link ID field.

[0265] A method for releasing a TWT agreement corresponding to a specific TWT Flow ID across all links will now be described. To signal the release of a TWT agreement corresponding to a specific TWT Flow ID across all links, the value of the Teardown all TWT subfield (B7) of the TWT Release frame may be set to 0, the value of the Teardown Type subfield (B4) may be set to 0, and the value of the All Link subfield (B3) may be set to 1. The format of the TWT Flow field according to this embodiment is shown in FIG. 26(c). When the value of the Teardown all TWT subfield is 0, the value of the Teardown Type subfield is 0, and the value of the All Link subfield is 1 in the TWT Release frame, the multilink device that transmitted and the multilink device that received the TWT Release frame including the TWT Flow field can release all TWT agreements corresponding to the TWT Flow IDs indicated by the TWT Flow Identifier field among the TWT agreements established between both multilink devices.

[0266] A method for canceling all TWT agreements established on all links will now be described. To signal the cancellation of all TWT agreements established on all links, the Teardown all TWT subfield (B7) of the TWT release frame may be set to 1, and the Teardown Type subfield (B4) 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 field according to this embodiment is shown in FIG. 26(d). When the Teardown all TWT subfield of the TWT release frame has a value of 1 and the Teardown Type subfield has a value of 1, the multilink device that transmitted the TWT release frame including the TWT Flow field and the multilink device that received the TWT release frame can cancel the TWT agreements established with both multilink devices.

[0267] In the above-described embodiment, the TWT agreement is terminated by a TWT release frame. However, the TWT agreement may also be terminated when a TWT release frame is not transmitted or received. This is called implicit termination. This will be explained using FIG. 27.

[0268] FIG. 27 illustrates the implicit cancellation of a TWT agreement established between multilink devices according to an embodiment of the present invention.

[0269] When an association between an AP and a non-AP station is disassociated, the TWT agreement established between the AP and the non-AP station may be implicitly terminated. Furthermore, when a link through which the AP and the non-AP station are associated is disabled, the TWT agreement established between the AP and the non-AP station may be implicitly terminated. In this case, the deactivation of the link may include the disappearance of the TID mapped to the link. For convenience of explanation, the following description focuses on the case where the association between the AP and the non-AP station is disassociated, but this may also apply to the case where a link through which the AP and the non-AP station are associated is disabled.

[0270] As described above, one TWT element may establish a TWT agreement for multiple links. In this case, the TWT Flow IDs of the TWT agreements established for multiple links may be the same. Furthermore, the requesting station for the TWT agreements established for multiple links may be the same, and the responding station for the TWT agreements established for multiple links may be the same. For this reason, it may be difficult to distinguish between the TWT agreements established for multiple links, and the TWT agreements may have to be terminated simultaneously when the TWT agreement is terminated. Furthermore, in conventional WLAN standards, when an AP and a non-AP station are decoupled, the AP and the non-AP station implicitly terminate the TWT agreement established between the AP and the non-AP station. At this time, information about the TWT agreement established between the AP and the non-AP station is deleted.

[0271] A single TWT element establishes TWT agreements across multiple links, and the TWT Flow IDs of the TWT agreements established across multiple links are the same. When the TWT request station and the TWT response station are decoupled, all of the multiple TWT agreements may be implicitly terminated.

[0272] In yet another specific embodiment, when a first station included in a multilink device is disassociated with a second station associated with the first station, a TWT agreement in which the first station is a TWT responding station or a TWT requesting station may be implicitly terminated. In this case, the first station operates on the first link. The terminated TWT agreement may be inherited by a station operating on a link other than the first link among the links operated by the multilink device including the first station. In this case, signaling including a link ID may be performed to inherit the TWT agreement. Furthermore, signaling for inheriting the TWT agreement may be transmitted using a management frame. Furthermore, such inheritance of the TWT agreement may be applied even when one station is not associated with a station associated with the first station. When inheritance of the TWT agreement is performed, the TWT agreement established before the inheritance may be terminated. In the above-described embodiment, TWT agreement inheritance may indicate that the TWT parameters applied to the previously established TWT agreement are applied to the new TWT agreement.

[0273] In the embodiment of Figure 27, the non-AP multi-link device (non-AP MLD) includes a first station (STA1), a second station (STA2), and a third station (STA3). The first station (STA1), the second station (STA2), and the third station (STA3) operate on a first link (Link1), a second link (Link2), and a third link (Link3), respectively. The AP multi-link device (AP MLD) includes a first AP (AP1), a second AP (AP2), and a third AP (AP3). The first AP (AP1), the second AP (AP2), and the third AP (AP3) operate on a first link (Link1), a second link (Link2), and a third link (Link3), respectively. The first station (STA1) and the first AP (AP1) are associated and establish TWT agreements (TWT1, TWT2, TWT3) on the first link (Link1), the second link (Link2), and the third link (Link3). The first station (STA1) and the first AP (AP1) are the requesting station and the responding station of the TWT agreements (TWT1, TWT2, TWT3) on the first link (Link1), the second link (Link2), and the third link (Link3). The non-AP multilink device (non-AP MLD) and the AP multilink device (AP MLD) perform a reassociation procedure, and the first station (STA1) and the first AP (AP1) may be deassociated. All TWT agreements in which the first station (STA1) and the first AP (AP1) are the TWT responding station or the TWT requesting station may be implicitly terminated. Therefore, the TWT agreements (TWT1, TWT2, TWT3) for the first link (Link1), the second link (Link2), and the third link (Link3) are all cancelled.

[0274] Through reassociation, the first station (STA1) can be associated with a fourth AP (AP4), which is a different AP from the first AP (AP1) in the AP Multilink Device (AP MLD), and operate on another link. In this case, the TWT agreement between the first station (STA1) and the first AP (AP1) can be inherited by the first station (STA1) and the fourth AP (AP4). In this way, a TWT agreement can be established on a new link through TWT agreement inheritance, regardless of the link on which the initial TWT setting was performed.

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

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

[0277] Although the above description has focused on the embodiments, these are merely examples and are not intended to limit the present invention. Those skilled in the art will appreciate that various modifications and applications not exemplified above are possible within the scope of the essential characteristics of the present invention. For example, each component specifically illustrated in the embodiments can be modified. Furthermore, differences related to such modifications and applications should be construed as being included within the scope of the present invention as defined by the appended 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 IP address acquisition step

Claims

1. A multi-link device including a first station and a second station operating on a first link and a second link, respectively, a transceiver; and a processor; The processor: transmitting a target wake time (TWT) element from the first station to a first AP associated with the first station over the first link to request a TWT agreement for the second station and a second AP associated with the second station; When the second link is deactivated, canceling the TWT agreement for the second station and the second AP without receiving or transmitting a TWT cancellation frame for canceling the TWT agreement for the second station and the second AP; If the multilink device receives the TWT release frame from the first AP or successfully sends the TWT release frame to the first AP, it releases the TWT agreement for the second station and the second AP. It is configured as follows: In the TWT release frame, the TWT agreement is identified based on a link identifier (ID) of the second link, a medium access control (MAC) address of a TWT request station, a MAC address of a TWT responder station of the TWT agreement, and a TWT FLOW ID of the TWT agreement; The TWT requesting station in the TWT agreement for the second station and the second AP is the second station, and the TWT responding station in the TWT agreement for the second station and the second AP is the second AP. Multi-link device.

2. The TWT element includes a bitmap indicating the links to which the TWT agreement that the TWT element is to establish applies.

2. The multi-link device according to claim 1.

3. The bitmap indicates a number of links to which the TWT agreement established by the TWT element applies.

3. The multi-link device according to claim 2.

4. 1. A method of operating a multi-link device including a first station and a second station operating on a first link and a second link, respectively, comprising: transmitting a target wake time (TWT) element from the first station to a first AP associated with the first station over the first link to request a TWT agreement for the second station and a second AP associated with the second station; When the second link is deactivated, releasing the TWT agreement for the second station and the second AP without receiving or transmitting a TWT release frame for releasing the TWT agreement for the second station and the second AP; canceling the TWT agreement for the second station and the second AP when the multilink device receives the TWT release frame from the first AP or successfully sends the TWT release frame to the first AP; Equipped with In the TWT release frame, the TWT agreement is identified based on a link identifier (ID) of the second link, a medium access control (MAC) address of a TWT request station, a MAC address of a TWT responder station of the TWT agreement, and a TWT FLOW ID of the TWT agreement; The TWT requesting station in the TWT agreement for the second station and the second AP is the second station, and the TWT responding station in the TWT agreement for the second station and the second AP is the second AP. method.

5. The TWT element includes a bitmap indicating the links to which the TWT agreement that the TWT element is to establish applies. The method of claim 4.

6. The bitmap indicates a number of links to which the TWT agreement established by the TWT element applies. The method of claim 5.

Images