Method and apparatus for performing link switching by type field in wireless LAN system

Abstract

A method and an apparatus for performing link switching based on a type field in a wireless LAN system are presented. Specifically, a first non-AP STA transmits an MLD roaming request frame to a first AP, and receives an MLD roaming response frame from the first AP. The first non-AP STA roams from the first AP to the third AP based on the MLD roaming response frame. A first AP operating on the first link and a second AP operating on the second link belong to the first AP MLD. A first non-AP STA operating on the first link and a second non-AP STA operating on the second link belong to the first non-AP MLD. The third AP belongs to the second AP MLD.

Description

Technical Field

[0001] This disclosure relates to a scheme for performing link switching based on a type field in a wireless LAN system, and more specifically, to a method and apparatus for defining a type field for requesting simultaneous link switching for deletion and connection. Background Technology

[0002] Wireless local area networks (WLANs) have been improved in various ways. Improved communication environments have been proposed based on standards such as IEEE 802.11ax, using orthogonal frequency division multiple access (OFDMA) and downlink multiple user multiple input multiple output (DLMU MIMO) schemes.

[0003] This specification outlines technical features that can be used in new communication standards. For example, a new communication standard could be the recently discussed Extremely High Throughput (EHT) specification. The EHT specification could utilize newly proposed features such as increased bandwidth, improved PHY layer Protocol Data Unit (PPDU) structures, improved sequencing, Hybrid Automatic Repeat Request (HARQ) schemes, and so on. The EHT specification could be referred to as the IEEE 802.11be specification.

[0004] The new WLAN specification allows for the use of an increased number of spatial streams. In this case, it may be necessary to improve the signaling scheme within the WLAN system to properly utilize the increased number of spatial streams. Summary of the Invention

[0005] Technical issues

[0006] This specification proposes a method and device for performing link switching based on the type field in a wireless local area network system.

[0007] Technical solution

[0008] The examples disclosed herein present a method for performing link switching based on a type field.

[0009] This implementation can be performed in network environments that support next-generation WLAN systems (Ultra-High Reliability (UHR) WLAN systems or next-generation Wi-Fi). Next-generation WLAN systems are WLAN systems that improve upon the 802.11be system and can meet backward compatibility requirements with the 802.11be system.

[0010] This implementation is performed in a receiving STA, and the receiving STA can be associated with at least one station (STA). The transmitting STA in this implementation can be associated with an access point (AP).

[0011] This embodiment proposes a method for a non-AP MLD to perform roaming from a serving AP MLD to a target AP MLD. Specifically, this embodiment proposes a roaming scheme that immediately switches to another link, rather than a roaming scheme that involves the non-AP MLD disconnecting its link from the serving AP MLD and adding a link connection to the target AP MLD. MLD roaming from the serving AP MLD to the target AP MLD is defined as the operation of seamlessly moving from one AP to another within the MLD without disconnecting between the AP and STA. In particular, this embodiment has the following advantages: by defining the operations and information required to simultaneously perform link connection to the target AP MLD and link deletion with the serving AP MLD based on roaming from a non-AP MLD to the target AP MLD, disconnection states are prevented, enabling seamless roaming without packet loss or latency.

[0012] The first non-access point station (non-AP STA) sends a multi-link device (MLD) roaming request frame to the first AP.

[0013] The first non-AP STA receives the MLD roaming response frame from the first AP.

[0014] The first non-AP STA performs roaming from the first AP to the third AP based on the MLD roaming response frame.

[0015] The first AP operating on the first link and the second AP operating on the second link belong to the first AP MLD. The first non-AP STA operating on the first link and the second non-AP STA operating on the second link belong to the first non-AP MLD.

[0016] The third AP belongs to the second AP MLD. The first AP MLD and the second AP MLD are included in the roaming group.

[0017] Additionally, the second non-AP STA can perform roaming from the second AP to the fourth AP based on the MLD roaming response frame. The fourth AP can also be a member of the second AP MLD.

[0018] The first and second APs can be referred to as the old AP (O_AP), the serving AP, or the current AP. The third and fourth APs can be referred to as the new AP (N_AP) or the target AP. The first AP MLD, which includes the first and second APs, can be referred to as the serving AP MLD. The second AP MLD, which includes the third and fourth APs, can be referred to as the target AP MLD.

[0019] A roaming group can be referred to as a UHR AP MLD. Although the first AP MLD and the second AP MLD are not co-located, they are included in the same roaming group, and therefore roaming (or moving) from an AP in the first AP MLD to an AP in the second AP MLD is possible. The first AP and the second AP in the first AP MLD are co-located. The third AP and the fourth AP in the second AP MLD are also co-located.

[0020] The MLD roaming request frame includes a type field. In this case, based on the type field, for the first link, the deletion of a connection for the first AP and the addition of a connection for the third AP are performed simultaneously. Additionally, based on the type field, for the second link, the deletion of a connection for the second AP and the addition of a connection for the fourth AP can be performed simultaneously.

[0021] Beneficial effects

[0022] This embodiment proposes a method that performs seamless MLD roaming by defining a type field with added link switching functionality for simultaneously performing link addition and deletion operations for MLD roaming. Based on this type field (using a single signaling), the method enables seamless MLD roaming by switching links from one AP to another. Therefore, it achieves the following effect: it resolves the problems of disconnection between AP and STA, resulting in packet loss and latency, present in conventional Fast BSS Switching (FT) schemes, while allowing uninterrupted migration to another AP. Attached Figure Description

[0023] Figure 1 Examples of transmitting and / or receiving devices are shown in this specification.

[0024] Figure 2 This is a conceptual diagram illustrating the structure of a wireless local area network (WLAN).

[0025] Figure 3 This illustrates a typical link establishment process.

[0026] Figure 4 An example of multi-link (ML) is shown.

[0027] Figure 5 Examples of Physical Protocol Data Units or Physical Layer (PHY) Protocol Data Units (PPDUs) transmitted / received by the STA of this disclosure are shown.

[0028] Figure 6 This is a diagram illustrating the layout of a resource unit (RU) for a 20 MHz PPDU.

[0029] Figure 7The layout of a resource unit (RU) for a 40 MHz PPDU is illustrated.

[0030] Figure 8 This is a diagram illustrating the layout of a resource unit (RU) for an 80 MHz PPDU.

[0031] Figure 9 The operation related to UL-MU is shown.

[0032] Figure 10 An example of using / supporting / defining a channel within the 2.4 GHz band is shown.

[0033] Figure 11 An example of using / supporting / defining a channel within the 5 GHz band is shown.

[0034] Figure 12 An example of using / supporting / defining a channel within the 6 GHz band is shown.

[0035] Figure 13 An example of a MAC frame header is shown.

[0036] Figure 14 Examples of modifications to the transmitting and / or receiving apparatus described herein are illustrated.

[0037] Figure 15 An example of an over-the-air (OTA) FT protocol in a robust secure network (RSN) is given.

[0038] Figure 16 An example of a high-level architecture for AP MLD is shown.

[0039] Figure 17 An example of a high-level architecture for UHR AP MLD is shown.

[0040] Figure 18 Another example of a high-level architecture for UHR AP MLD is shown.

[0041] Figure 19 An example of a roaming architecture in an AP MLD region is shown.

[0042] Figure 20 An example of an RNR IE is shown.

[0043] Figure 21 Another example of an RNR IE is shown.

[0044] Figure 22 This shows yet another example of an RNR IE.

[0045] Figure 23An example is shown in the public information field for enabling the AP roaming recommendation field.

[0046] Figure 24 An example is shown in the Link Information field for enabling the AP roaming recommendation field.

[0047] Figure 25 An example of the common information field for reconfiguring multi-link IEs as proposed in this embodiment is shown.

[0048] Figure 26 An example of the link information field for reconfiguring multi-link IEs as proposed in this embodiment is shown.

[0049] Figure 27 An example is shown in this embodiment where the common information fields of the reconfigured multi-link IE include the UHR APMLD ID and AP MLD ID.

[0050] Figure 28 An example is shown in this embodiment where the common information field of the reconfigured multi-link IE includes the AP MLDID.

[0051] Figure 29 An example is shown in this embodiment where the link information field of the reconfigured multi-link IE includes the UHR APMLD ID and AP MLD ID.

[0052] Figure 30 An example is shown in this embodiment where the link information field of the reconfigured multi-link IE includes the AP MLDID.

[0053] Figure 31 Another example is shown in this embodiment where the link information field of the reconfigured multi-link IE includes the UHR APMLD ID and AP MLD ID.

[0054] Figure 32 Another example is shown in this embodiment where the link information field of the reconfigured multi-link IE includes the AP MLDID.

[0055] Figure 33 An example is shown in this embodiment where the public information field for reconfiguring multi-link IE includes a temporary field.

[0056] Figure 34 An example is shown in this embodiment where the link information field of the reconfigured multi-link IE includes a temporary field.

[0057] Figure 35 This example illustrates another instance where the link information field of the reconfigured multi-link IE proposed in this embodiment includes a temporary field.

[0058] Figure 36 An example is shown in this embodiment where the common information field for reconfiguring multi-link IE includes an AP removal timer field.

[0059] Figure 37 An example of the common information field of the basic multi-link IE proposed in this embodiment is shown.

[0060] Figure 38 An example of the link information field of the basic multi-link IE proposed in this embodiment is shown.

[0061] Figure 39 An example of a group key information field is shown.

[0062] Figure 40 The procedure for checking whether N_AP can perform roaming using the common enable field is illustrated.

[0063] Figure 41 The procedure for checking whether N_AP can perform roaming using a common ID is illustrated.

[0064] Figure 42 An example of an MLD roaming process based on a reconfiguration element that includes the UHR AP MLD ID is shown.

[0065] Figure 43 An example of an MLD roaming process based on a reconfiguration element that does not include the UHR AP MLD ID is shown.

[0066] Figure 44 An example of a co-located AP set is shown.

[0067] Figure 45 Example 1 illustrates the MLD roaming process.

[0068] Figure 46 Example 1 illustrates the operation process of the MLD roaming process.

[0069] Figure 47 Example 2 illustrates the MLD roaming process.

[0070] Figure 48 Example 2 illustrates the operation process of the MLD roaming process.

[0071] Figure 49 Example 3 illustrates the MLD roaming process.

[0072] Figure 50 Example 3 illustrates the operation process of the MLD roaming process.

[0073] Figure 51 Example 4 illustrates the MLD roaming process.

[0074] Figure 52 Examples 3 and 4 illustrate the operation process of MLD roaming.

[0075] Figure 53 Example 5 illustrates the MLD roaming process.

[0076] Figure 54 Example 6 illustrates the MLD roaming process.

[0077] Figure 55 An example of MLD roaming using TIM is shown.

[0078] Figure 56 This demonstrates the operation process of using TIM for MLD roaming.

[0079] Figure 57 This is a flowchart illustrating the operation of the transmitting device according to this embodiment.

[0080] Figure 58 This is a flowchart illustrating the operation of the receiving device according to this embodiment.

[0081] Figure 59 This is a flowchart illustrating the process by which an AP sends and receives request frames and response frames for MLD roaming according to this embodiment.

[0082] Figure 60 This is a flowchart illustrating the process by which a STA sends and receives request frames and response frames for MLD roaming according to this embodiment. Detailed Implementation

[0083] In this disclosure, "A or B" can mean "A only", "B only", or "both A and B". In other words, in this disclosure, "A or B" can be interpreted as "A and / or B". For example, in this disclosure, "A, B or C" can mean "A only", "B only", "C only", or "any combination of A, B, and C".

[0084] The forward slash ( / ) or comma used in this disclosure can represent "and / or". For example, "A / B" can mean "A and / or B". Therefore, "A / B" can mean "A only", "B only", or "both A and B". For example, "A, B, C" can mean "A, B, or C".

[0085] In this disclosure, "at least one of A and B" can mean "only A", "only B" or "both A and B". Additionally, in this disclosure, the expression "at least one of A or B" or "at least one of A and / or B" can be interpreted as "at least one of A and B".

[0086] The brackets used in this disclosure may indicate "for example". Specifically, when indicated as "control information (UHR-signal field)", it may indicate that the "UHR-signal field" is cited as an example of "control information". In other words, the "control information" of this disclosure is not limited to the "UHR-signal field", and the "UHR-signal field" may also be cited as an example of "control information". Furthermore, when indicated as "control information (i.e., UHR-signal field)", it may also indicate that the "UHR-signal field" is cited as an example of "control information".

[0087] Furthermore, as used in this disclosure, "a" can mean "at least one" or "one or more". Additionally, terms ending in "(s)" can mean "at least one" or "one or more".

[0088] Furthermore, as used in this disclosure, the expressions “based on”, “within”, or “according to” mean “at least partially based on”, and not “based on only”.

[0089] The technical features described individually in one of the accompanying drawings of this disclosure may be implemented individually or simultaneously.

[0090] The following examples of this disclosure can be applied to various wireless communication systems. For example, the following examples of this disclosure can be applied to wireless local area network (WLAN) systems. For example, this disclosure can be applied to the IEEE 802.11 a / g / n / ac / ax / be / bn standards. Furthermore, the examples of this disclosure can also be applied to next-generation wireless LAN standards such as enhanced Ultra-High Reliability (UHR) standards or IEEE 802.11 bn. Furthermore, the examples of this disclosure can also be applied to new WLAN standards enhanced from EHT standards or IEEE 802.11 be standards. Furthermore, the examples of this disclosure can be applied to mobile communication systems. For example, it can be applied to mobile communication systems based on Long Term Evolution (LTE), which relies on 3GPP standards and is based on LTE evolution. Furthermore, the examples of this disclosure can be applied to communication systems based on the 5G NR standard of 3GPP standards.

[0091] In the following text, for the purpose of describing the technical features of this disclosure, technical features applicable to this disclosure will be described.

[0092] Figure 1 Examples of transmitting and / or receiving devices of this disclosure are shown.

[0093] exist Figure 1 In the example, the various technical features described below can be performed. Figure 1At least one station (STA) is involved. For example, STA 110 and 120 of this disclosure may also be referred to by various terms such as mobile terminal, wireless device, wireless transceiver unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, or simply user. STA 110 and 120 of this disclosure may also be referred to by various terms such as network, base station, Node B, access point (AP), repeater, router, relay, etc. STA 110 and 120 of this disclosure may also be referred to by various names such as receiving device, transmitting device, receiving STA, transmitting STA, receiving apparatus, transmitting apparatus, etc.

[0094] For example, STA 110 and 120 can be used as AP or non-AP. That is, STA 110 and 120 of this disclosure can be used as AP and / or non-AP. In this disclosure, AP can be indicated as AP STA.

[0095] In addition to the IEEE 802.11 standard, the STAs 110 and 120 of this disclosure can together support various communication standards. For example, they can support communication standards based on 3GPP standards (e.g., LTE, LTE-A, 5G NR standards). Furthermore, the STAs of this disclosure can be implemented in various devices such as mobile phones, vehicles, and personal computers. Additionally, the STAs of this disclosure can support communication for various communication services such as voice calls, video calls, data communication, and autonomous driving.

[0096] The STA 110 and 120 disclosed herein may include media access control (MAC) conforming to the IEEE 802.11 standard and a physical layer interface for radio media.

[0097] The following will refer to Figure 1 The subgraph (a) is used to describe STA 110 and 120.

[0098] The first STA 110 may include a processor 111, a memory 112, and a transceiver 113. The illustrated processor, memory, and transceiver may be implemented as separate chips, or at least two blocks / functions may be implemented as a single chip.

[0099] The transceiver 113 of the first STA performs signal transmission / reception operations. Specifically, it can transmit / receive IEEE 802.11 packets (e.g., IEEE 802.11a / b / g / n / ac / ax / be, etc.).

[0100] For example, the first STA 110 can perform the operations expected by the AP. For example, the AP's processor 111 can receive signals via transceiver 113, process receive (RX) signals, generate transmit (TX) signals, and provide control over signal transmission. The AP's memory 112 can store signals received via transceiver 113 (e.g., RX signals) and can store signals to be transmitted via transceiver 113 (e.g., TX signals).

[0101] For example, the second STA 120 can perform operations not expected of an AP STA. For example, a non-AP transceiver 123 performs signal transmission / reception operations. Specifically, it can transmit / receive IEEE 802.11 packets (e.g., IEEE 802.11a / b / g / n / ac / ax / be packets, etc.).

[0102] For example, a non-AP STA processor 121 can receive signals via transceiver 123, process RX signals, generate TX signals, and provide control over signal transmission. A non-AP STA memory 122 can store signals received via transceiver 123 (e.g., RX signals) and can store signals to be transmitted via transceiver 123 (e.g., TX signals).

[0103] For example, the operation of a device designated as an AP in the disclosure described below can be performed in either the first STA 110 or the second STA 120. For instance, if the first STA 110 is an AP, the operation of the device designated as an AP can be controlled by the processor 111 of the first STA 110, and related signals can be transmitted or received via a transceiver 113 controlled by the processor 111 of the first STA 110. Additionally, control information related to the operation of the AP or the AP's TX / RX signals can be stored in the memory 112 of the first STA 110. Similarly, if the second STA 120 is an AP, the operation of the device designated as an AP can be controlled by the processor 121 of the second STA 120, and related signals can be transmitted or received via a transceiver 123 controlled by the processor 121 of the second STA 120. Furthermore, control information related to the operation of the AP or the AP's TX / RX signals can be stored in the memory 122 of the second STA 120.

[0104] For example, in the disclosure described below, the operation of a device indicated as a non-AP (or user STA) can be performed in either the first STA 110 or the second STA 120. For instance, if the second STA 120 is a non-AP, the operation of the device indicated as a non-AP can be controlled by the processor 121 of the second STA 120, and related signals can be transmitted or received via a transceiver 123 controlled by the processor 121 of the second STA 120. Additionally, control information related to the operation of a non-AP or non-AP TX / RX signals can be stored in the memory 122 of the second STA 120. Similarly, if the first STA 110 is a non-AP, the operation of the device indicated as a non-AP can be controlled by the processor 111 of the first STA 110, and related signals can be transmitted or received via a transceiver 113 controlled by the processor 111 of the first STA 110. Additionally, control information related to the operation of a non-AP or non-AP TX / RX signals can be stored in the memory 112 of the first STA 110.

[0105] In the disclosure described below, devices referred to as (transmitting / receiving) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmitting / receiving) terminal, (transmitting / receiving) device, (transmitting / receiving apparatus), network, etc., may implicitly refer to Figure 1 STAs 110 and 120. For example, devices indicated as (but without specific labels) (transmitting / receiving) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmitting / receiving) terminal, (transmitting / receiving) device, (transmitting / receiving) apparatus, network, etc., can implicitly refer to... Figure 1 STAs 110 and 120. For example, in the following example, the operation of various STA transmit / receive signals (e.g., PPDU) can be... Figure 1 The operation is performed in transceivers 113 and 123. Additionally, in the following examples, various STA operations for generating TX / RX signals or pre-performing data processing and calculations on TX / RX signals can be performed within these transceivers. Figure 1The operations are executed in processors 111 and 121. Examples of operations for generating TX / RX signals or performing prior data processing and calculations may include: 1) operations to determine / obtain / configure / calculate / decode / encode bit information of subfields (SIG, STF, LTF, data) included in the PPDU; 2) operations to determine / configure / obtain time resources or frequency resources (e.g., subcarrier resources) for the subfields (SIG, STF, LTF, data) included in the PPDU; 3) operations to determine / configure / obtain specific sequences (e.g., pilot sequences, STF / LTF sequences, additional sequences applied to SIG) for the subfields (SIG, STF, LTF, data) included in the PPDU; 4) power control operations and / or power-saving operations applied to the STA; and 5) operations related to the determination / obtaining / configuration / decoding / encoding of the ACK signal. Additionally, in the following examples, various information (e.g., information related to fields / subfields / control fields / parameters / power, etc.) used by various STAs to determine / obtain / configure / calculate / decode / decode the TX / RX signal may be stored in the STA's memory. Figure 1 In memory 112 and 122.

[0106] Figure 1 The aforementioned device / STA in subgraph (a) can be as follows Figure 1 The subgraph (b) is modified as shown below. In the following text, the modifications will be based on... Figure 1 The subgraph (b) is used to describe STA 110 and STA 120 of this disclosure.

[0107] For example, Figure 1 The transceivers 113 and 123 shown in subgraph (b) can perform operations with Figure 1 The transceiver shown in sub-diagram (a) has the same function as the aforementioned transceiver. For example, Figure 1 The processing chips 114 and 124 shown in sub-figure (b) may include processors 111 and 121 and memories 112 and 122. Figure 1 The processors 111 and 121 and the memories 112 and 122 shown in sub-figure (b) can perform operations related to Figure 1 The processors 111 and 121 and the memories 112 and 122 shown in sub-figure (a) have the same functions.

[0108] The mobile terminal, wireless device, wireless transceiver unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, user, subscriber STA, network, base station, node B, access point (AP), repeater, router, relay, receiving unit, transmitting unit, receiving STA, transmitting STA, receiving device, transmitting device, receiving equipment and / or transmitting equipment described below may mean Figure 1 The STA 110 and 120 shown in subgraphs (a) / (b) may mean, or Figure 1 The processing chips 114 and 124 are shown in sub-figure (b). That is, the technical features of this disclosure can be... Figure 1 It can be performed in STA 110 and 120 as shown in subgraphs (a) / (b), or it can be performed only in... Figure 1 The processing chips 114 and 124 shown in sub-diagram (b) are executed Figure 1 Transceivers 113 and 123 are shown in sub-diagrams (a) and (b). For example, the technical features of transmitting control signals by a STA can be understood as being achieved through... Figure 1 The transceiver 113 shown in sub-diagrams (a) / (b) transmits in Figure 1 The technical features of the control signals generated in processors 111 and 121 are illustrated in sub-figures (a) and (b). Alternatively, the technical features of the STA transmitting control signals can be understood as follows: Figure 1 The technical features of generating control signals to be transmitted to transceivers 113 and 123 in processing chips 114 and 124 are shown in sub-figure (b).

[0109] For example, the technical characteristics of receiving STA control signals can be understood as through... Figure 1 The technical features of transceivers 113 and 123 receiving control signals are shown in sub-figure (a). Alternatively, the technical features of receiving STA control signals can be understood as being achieved through... Figure 1 Processors 111 and 121 shown in subgraph (a) obtain Figure 1 The technical features of the control signals received in transceivers 113 and 123 shown in sub-figure (a) are illustrated. Alternatively, the technical features of receiving control signals by the STA can be understood as being achieved through... Figure 1 The processing chips 114 and 124 shown in sub-figure (b) obtain Figure 1 Technical features of the control signals received in transceivers 113 and 123 as shown in sub-figure (b).

[0110] refer to Figure 1 Subgraph (b), software codes 115 and 125 can be included in memories 112 and 122. Software codes 115 and 125 can include instructions for controlling the operation of processors 111 and 121. Software codes 115 and 125 can be included in various programming languages.

[0111] Figure 1 The processors 111 and 121 or processing chips 114 and 124 may include application-specific integrated circuits (ASICs), other chipsets, logic circuits, and / or data processing devices. The processor may be an application processor (AP). For example, Figure 1 The processors 111 and 121 or processing chips 114 and 124 may include at least one of the following: a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modulator and demodulator (modem). For example, Figure 1 The processors 111 and 121 or the processor chips 114 and 124 may be SNAPDRAGON™ series processors manufactured by Qualcomm®, EXYNOS™ series processors manufactured by Samsung®, A series processors manufactured by Apple®, HELIO™ series processors manufactured by MediaTek®, ATOM™ series processors manufactured by Intel®, or processors enhanced from these processors.

[0112] In this disclosure, an uplink can mean a link used for communication from a non-AP STA to an AP STA, and uplink PPDUs / packets / signals, etc., can be transmitted via the uplink. Similarly, in this disclosure, a downlink can mean a link used for communication from an AP STA to a non-AP STA, and downlink PPDUs / packets / signals, etc., can be transmitted via the downlink.

[0113] Figure 2 This is a conceptual diagram illustrating the structure of a wireless local area network (WLAN).

[0114] Figure 2 The upper part illustrates the structure of the Infrastructure Basic Services Set (BSS) of the Institute of Electrical and Electronics Engineers (IEEE) 802.11.

[0115] Figure 2 The upper part illustrates the structure of the Infrastructure Basic Services Set (BSS) of the Institute of Electrical and Electronics Engineers (IEEE) 802.11.

[0116] refer to Figure 2 The upper part of the wireless LAN system may include one or more infrastructure BSS 200 and 205 (hereinafter referred to as BSS). BSS 200 and 205, as a set of APs and STAs (e.g., access point (AP) 225 and station (STA1) 200-1) that have successfully synchronized to communicate with each other, are not concepts indicating a specific area. BSS 205 may include one or more STAs 205-1 and 205-2 that can join an AP 230.

[0117] BSS may include at least one STA, APs 255 and 230 that provide distributed services, and a distributed system (DS) 210 that connects multiple APs.

[0118] Distributed system 210 can implement an Extended Service Set (ESS) 240 that is expanded by connecting multiple BSSs 200 and 205. ESS 240 can be used as a term to refer to a network configured by connecting one or more APs 225 or 230 via distributed system 210. APs included in an ESS 240 can have the same Service Set Identifier (SSID).

[0119] Portal 220 can be used as a bridge to connect a wireless LAN network (IEEE 802.11) to another network (e.g., 802.X).

[0120] exist Figure 2 The BSS shown at the top allows for networking between APs 225 and 230, as well as between APs 225 and 230 and STAs 200-1, 205-1, and 205-2. However, it also allows for networking between STAs to perform communication even without APs 225 and 230. Networks that enable communication between STAs by configuring networks even without APs 225 and 230 are defined as self-organizing networks or Independent Basic Service Sets (IBSS).

[0121] Figure 2 The lower part illustrates a concept diagram, showing the IBSS.

[0122] refer to Figure 2 The lower part of the IBSS is a BSS that operates in a self-organizing mode. Since the IBSS does not include access points (APs), there is no centralized management entity performing management functions at the center. That is, in the IBSS, STAs 250-1, 250-2, 250-3, 255-4, and 255-5 are managed in a distributed manner. In the IBSS, all STAs 250-1, 250-2, 250-3, 255-4, and 255-5 can be composed of mobile STAs, and access to DS to form a self-contained network is not permitted.

[0123] Figure 3 The diagram illustrates the typical link establishment process.

[0124] In S310, the STA can perform network discovery operations. Network discovery operations can include scanning operations by the STA. That is, in order to access a network, the STA needs to discover participating networks. The process of identifying compatible networks before joining a wireless network and identifying networks existing in a specific area is called scanning. Scanning methods include active scanning and passive scanning.

[0125] Figure 3The diagram illustrates the network discovery process in active scanning. In active scanning, the STA performing the scan sends a probe request frame and waits for a response to it, in order to identify which APs are nearby while moving to a new channel. The responder sends a probe response frame to the STA that sent the probe request frame as a response. Here, the responder can be the STA in the BSS of the channel being scanned that sent the last beacon frame. In the BSS, the AP is the responder because it sends the beacon frame. In the IBSS, the responder is not fixed because the STAs in the IBSS take turns sending beacon frames. For example, when an STA sends a probe request frame via channel 1 and receives a probe response frame via channel 1, the STA can store the BSS-related information included in the received probe response frame, move to the next channel (e.g., channel 2), and perform a scan in the same way (e.g., sending a probe request and receiving a probe response via channel 2).

[0126] Although Figure 3 As not shown, scanning can be performed using a passive scanning method. In passive scanning, the STA performing the scan can wait for beacon frames while moving to a channel. Beacon frames are one of the management frames in IEEE 802.11 and are periodically sent to indicate the presence of a wireless network and enable the STA performing the scan to find and join the wireless network. In a BSS, the AP periodically sends beacon frames. In an IBSS, STAs in the IBSS take turns sending beacon frames. Upon receiving a beacon frame, the STA performing the scan stores information about the BSS included in the beacon frame and records the beacon frame information for each channel, while moving to another channel. The STA receiving the beacon frame can store the BSS-related information included in the received beacon frame, can move to the next channel, and can perform a scan on the next channel using the same method.

[0127] After network discovery, the STA can perform authentication processing in S320. This authentication processing can be referred to as the first authentication processing to clearly distinguish it from the subsequent security establishment operation in S340. The authentication processing in S320 may include the STA sending an authentication request frame to the AP and the AP sending an authentication response frame to the STA in response. The authentication frame used for the authentication request / response is a management frame.

[0128] An authentication frame may include information about the authentication algorithm number, authentication transaction sequence number, status code, challenge text, robust security network (RSN), and finite cyclic group.

[0129] The STA can send an authentication request frame to the AP. The AP can determine whether to allow the STA's authentication based on the information included in the received authentication request frame. The AP can then provide the authentication processing result to the STA via an authentication response frame.

[0130] When a STA is successfully authenticated, it can perform association processing in S330. Association processing includes the STA sending an association request frame to the AP, and the AP responding by sending an association response frame to the STA. For example, the association request frame may include information about various capabilities, beacon listening interval, service set identifier (SSID), supported rates, supported channels, RSN, mobile domain, supported operation classes, service indication map (TIM) broadcast request, and interoperability service capabilities. Similarly, the association response frame may include information about various capabilities, status codes, association ID (AID), supported rates, enhanced distributed channel access (EDCA) parameter set, received channel power indicator (RCPI), received signal-to-noise ratio indicator (RSNI), mobile domain, timeout interval (association recovery time), overlapping BSS scan parameters, TIM broadcast response, and QoS map.

[0131] In the S340, the STA can perform security establishment processes. The security establishment processes in the S340 may include the process of establishing a private key via a four-way handshake (e.g., via Extensible Authentication Protocol (EAPOL) frames over the LAN).

[0132] Figure 4 An example of multi-link (ML) is shown.

[0133] like Figure 4 As illustrated, multiple multi-link devices (MLDs) can communicate via a remote link. MLDs can be classified as AP MLDs, which include multiple AP STAs, and non-AP MLDs, which include multiple non-AP STAs. That is, an AP MLD may include a member AP (i.e., an AP STA), and a non-AP MLD may include a member STA (i.e., a non-AP STA or a user STA).

[0134] A multi-link system may include a first link and a second link, and different channel / subchannel / frequency resources may be allocated to the first link and the second link. The first and second multi-link systems can be identified by a 4-bit (or other n-bit) link ID. The first and second links can be configured in the same 2.4 GHz, 5 GHz, or 6 GHz frequency band. Alternatively, the first and second links can be configured in different frequency bands.

[0135] Figure 4 The AP MLD includes three subordinate APs. Figure 4 In the example, AP1 can operate in the 2.4 GHz band, AP2 can operate in the 5 GHz band, and AP3 can operate in the 6 GHz band. Figure 4In the example, the first link in which AP1 and non-AP1 operate can be defined as a channel / subchannel / frequency resource within the 2.4 GHz band. Furthermore, in Figure 4 In the example, the second link in which AP2 and non-AP2 operate can be defined as a channel / subchannel / frequency resource within the 5 GHz band. Furthermore, in Figure 4 In the example, the third link in which AP3 and non-AP3 operate can be defined as a channel / subchannel / frequency resource within the 6GHz band.

[0136] exist Figure 4 In the example, AP1 can initiate the multi-link establishment process (ML establishment process) by sending an association request frame to a non-AP STA1. Figure 4 In the example, a non-AP STA1 can send an association response frame in response to an association request frame. Figure 4 The individual APs shown (e.g., AP1 / 2 / 3) can be compared with... Figure 1 and / or Figure 2 The APs shown are the same, and Figure 4 The various non-APs shown (e.g., non-AP1 / 2 / 3) can be compared with... Figure 1 and / or Figure 2 The STAs shown are the same (i.e., user STAs or non-AP STAs).

[0137] The specific features of this disclosure are not limited to Figure 4 The specific characteristics are as follows. That is, the number of links can be defined in various ways, and multiple links can be defined in at least one frequency band in various ways.

[0138] Figure 5 Examples of Physical Protocol Data Units or Physical Layer (PHY) Protocol Data Units (PPDUs) transmitted / received by the STA of this disclosure are shown.

[0139] The STA (e.g., AP STA, non-AP STA, AP MLD, non-AP MLD) disclosed herein can send and / or receive. Figure 5 The PPDU described in this disclosure may have, for example... Figure 5 The structure is as follows. Furthermore, the PPDU described in this disclosure may be referred to by various names, such as transmit PPDU, receive PPDU, type 1 or type N PPDU, etc. The PPDU described in this disclosure can be used in WLAN systems defined according to IEEE 802.11bn and / or in next-generation WLAN systems that improve upon IEEE 802.11bn.

[0140] Figure 5 The PPDU can encompass various PPDU types used in UHR systems. For example, Figure 5 Examples can be used for at least one of the following modes related to channel detection: single-user (SU) mode / type / transmission, multi-user (MU) mode / type / transmission, and null packet (NDP) mode / type / transmission. For example, if Figure 5 If the example involves NDP, the data fields shown can be omitted. Figure 5 The PPDU is used in trigger-based (TB) mode and can be omitted. Figure 6 The UHR-SIG. In other words, a STA that has received a trigger frame for uplink-MU (UL-MU) communication can send a UHR-SIG. Figure 5 The UHR-SIG PPDU is omitted in the example.

[0141] exist Figure 5 In this context, L-STF or UHR-LTF can be referred to as a preamble or physical preamble, and can be generated / transmitted / received / acquired / decoded at the physical layer (including in the transmit / receive STA).

[0142] Figure 5 The blocks shown in the diagram can be referred to as fields / subfields / signals, etc. These fields / subfields / signals can be named as Traditional Short Training Field (L-STF), Traditional Long Training Field (L-LTF), Traditional Signal (L-SIG), Repeated L-SIG (RL-SIG), Universal Signal (U-SIG), UHR Signal (UHR-SIG), etc. Figure 5 As shown in the diagram.

[0143] Figure 5 The subcarrier spacing of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields can be determined to be 312.5 kHz, and the subcarrier spacing of the UHR-STF, UHR-LTF, and Data fields can be determined to be 78.125 kHz. That is, the tone index (or subcarrier index) of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields can be represented in units of 312.5 kHz, and the tone index (or subcarrier index) of the UHR-STF, UHR-LTF, and Data fields can be represented in units of 78.125 kHz.

[0144] exist Figure 5 In the PPDU, the L-LTF and L-STF can be the same as those in the conventional domain (e.g., non-HT LTF and non-HT STF defined in conventional WLAN standards).

[0145] Figure 5The L-SIG field can include, for example, 24 bits of bit information. For instance, the 24 bits could include a 4-bit rate field, a 1-bit reserved bit, a 12-bit length field, a 1-bit parity bit, and a 6-bit tail bit. For example, the 12-bit length field could include information related to the length or duration of the PPDU. For example, the 12-bit length field can be determined based on the type of PPDU. For example, when the PPDU is a Non-High Throughput (HT), High Throughput (HT), Very High Throughput (VHT) PPDU, Extremely High Throughput (EHT) PPDU, or UHR PPDU, the value of the length field can be determined to be a multiple of 3. For example, when the PPDU is an HE PPDU, the length field can be determined to be a multiple of 3 + 1 or a multiple of 3 + 2. In other words, for non-HT, HT, VHT, EHT, or UHR PPDUs, the length field value can be set to a multiple of 3, and for high-efficiency (HE) PPDUs, the length field value can be set to either a multiple of 3 + 1 or a multiple of 3 + 2. In other words, the LENGTH field in a UHR PPDU is set to a value that satisfies the condition that LENGTH divided by 3 leaves a remainder of 0.

[0146] For example, a (non-AP and AP) STA can apply BCC encoding based on a 1 / 2 coding rate to the 24-bit information of the L-SIG field. The transmitting STA then obtains 48 bits of BCC compiled bits. BPSK modulation can be applied to these 48 compiled bits to generate 48 BPSK symbols. The transmitting STA can map these 48 BPSK symbols to positions other than the pilot subcarriers {subcarrier indices -21, -7, +7, +21} and the DC subcarrier {subcarrier index 0}. As a result, the 48 BPSK symbols can be mapped to subcarrier indices -26 to -22, -20 to -8, -6 to -1, +1 to +6, +8 to +20, and +22 to +26. The transmitting STA can additionally map the signal {-1, -1, -1, 1} to subcarrier indices {-28, -27, +27, +28}. The aforementioned signals can be used for channel estimation in the frequency domain corresponding to {-28, -27, +27, +28}.

[0147] For example, a (non-AP and AP) STA can generate an RL-SIG in the same way as the L-SIG. BPSK modulation can be applied to the RL-SIG. Based on the presence of the RL-SIG, the (non-AP and AP) STA can know that the RX PPDU is an HE PPDU, EHT PPDU, or UHR PPDU. In other words, if the RL-SIG is present, the receiving (non-AP and AP) STA can know that the received PPDU is one of an HE PPDU, EHT PPDU, or UHR PPDU. In other words, if the RL-SIG is not present, the receiving (non-AP and AP) STA can know that the received PPDU is one of a non-HT PPDU, HT PPDU, or VHT PPDU. In other words, the RL-SIG field is a repetition of the L-SIG field and is used to distinguish UHR PPDUs from non-HT PPDUs, HT PPDUs, and VHT PPDUs.

[0148] Universal SIG (U-SIG) can be inserted in Figure 6 Following RL-SIG, U-SIG can be referred to by various terms such as First SIG Field, First SIG, First Type SIG, Control Signal, Control Signal Field, First (Type) Control Signal, Common Control Field, Common Control Field, etc.

[0149] U-SIG can include N bits of information and may include information to identify the type of EHT PPDU. For example, U-SIG can be configured based on two symbols (e.g., two consecutive OFDM symbols). Each symbol used for U-SIG (e.g., an OFDM symbol) can have a duration of 4 μs. Each symbol of U-SIG can be used to transmit 26 bits of information. For example, each symbol of U-SIG can be transmitted / received based on 52 data tones and 4 pilot tones.

[0150] Through U-SIG, for example, A bits of information (e.g., 52 uncompiled bits) can be transmitted. The first symbol of U-SIG can transmit the first X bits of the A bits of information (e.g., 26 uncompiled bits), and the second symbol of U-SIG can transmit the remaining Y bits of the A bits of information (e.g., 26 uncompiled bits). For example, the transmitting STA can obtain the 26 uncompiled bits included in each U-SIG symbol. The transmitting STA can perform convolutional coding (i.e., BCC coding) based on a rate of R=1 / 2 to generate 52 compiled bits, and can perform interleaving on the 52 compiled bits. The transmitting STA can perform BPSK modulation on the interleaved 52 compiled bits to generate 52 BPSK symbols to be assigned to each U-SIG symbol. A U-SIG symbol can be transmitted based on 65 tones (subcarriers) from subcarrier index -28 to subcarrier index +28, except for DC index 0. The 52 BPSK symbols generated by the transmitting STA can be transmitted based on the remaining tones (subcarriers) other than the pilot tone, namely tones -21, -7, +7, and +21.

[0151] For example, the A-bit information generated by U-SIG (e.g., 52 uncompiled bits) may include a CRC field (e.g., a 4-bit field) and a tail field (e.g., a 6-bit field). The CRC and tail fields can be sent via a second symbol of U-SIG. The CRC field can be generated based on the 26 bits allocated to the first symbol of U-SIG and the remaining 16 bits from the second symbol excluding the CRC / tail field, and can be generated based on a standard CRC calculation algorithm. Additionally, the tail field can be used to terminate the trellis of the convolutional decoder and can be set to, for example, "000000".

[0152] The A-bit information (e.g., 52 uncompiled bits) sent by U-SIG (or the U-SIG field) can be divided into version-independent bits and version-dependent bits. For example, version-independent bits can have a fixed or variable size. For example, version-independent bits can be assigned only to the first symbol of U-SIG, or version-independent bits can be assigned to both the first and second symbols of U-SIG. For example, version-independent bits and version-dependent bits can be referred to using various terms such as first control bit, second control bit, etc.

[0153] For example, the version-independent bits of the U-SIG can include a 3-bit PHY version identifier. For example, the 3-bit PHY version identifier can include information related to the PHY version of the TX / RX PPDU. For example, the first value of the 3-bit PHY version identifier (e.g., a value of 000) can indicate that the TX / RX PPDU is an EHT PPDU. Furthermore, the second value of the 3-bit PHY version identifier (e.g., a value of 001) can indicate that the TX / RX PPDU is a UHR PPDU.

[0154] In other words, when an (AP / non-AP) STA sends an EHT PPDU, the 3-bit PHY version identifier can be set to a first value, and when an (AP / non-AP) STA sends a UHR PPDU, the 3-bit PHY version identifier can be set to a second value. In other words, the receiving (AP / non-AP) STA can determine that the received PPDU is an EHT PPDU based on the PHY version identifier with the first value, and can determine that the received PPDU is a UHR PPDU based on the PHY version identifier with the second value.

[0155] For example, the version-independent bits of U-SIG may include a 1-bit UL / DL flag field. The first value of the 1-bit UL / DL flag field is related to UL communication, and the second value of the UL / DL flag field is related to DL communication.

[0156] For example, the version-independent bits of U-SIG can include information related to the transmission opportunity (TXOP) length and information related to the BSS color ID.

[0157] For example, if the UHR PPDU is classified into various types (e.g., types related to SU transmission (based on UL or DL), types related to DL transmission, types related to NDP transmission, types related to DL non-MU-MIMO, types related to DL MU-MIMO, types related to multi-AP operation, types related to Co-BF beamforming (Co-BF), spatial reuse (SR), types related to Co-OFDMA (C-OFDMA), and types related to Co-TDMA (Co-TDMA), then information about the type of UHR PPDU (e.g., 2-bit or 3-bit information) can be included in the version-related bits of the U-SIG.

[0158] For example, U-SIG may include: 1) a bandwidth field including information related to bandwidth; 2) a field including information related to the modulation and demodulation scheme (MCS) applied to UHR-SIG; 3) an indication field including information related to whether a dual subcarrier modulation (DCM) scheme is applied to UHR-SIG; 4) a field including information related to the number of symbols used for UHR-SIG; 5) a field including information related to whether UHR-SIG is generated across the entire frequency band; 6) a field including information related to the type of UHR-LTF / STF; and 7) information related to fields indicating the length of UHR-LTF and the length of CP.

[0159] Can be Figure 5 The PPDU uses a preamble puncturing. A preamble puncturing means that the puncturing is applied to a portion of the full frequency band (e.g., the secondary 20 MHz band). For example, when transmitting an 80 MHz PPDU, the STA can apply puncturing to the secondary 20 MHz band within the 80 MHz band, and can transmit the PPDU only through the primary 20 MHz band and the secondary 40 MHz band.

[0160] For example, the pattern of the preamble perforation can be pre-configured. For example, when applying the first perforation pattern, perforation can be applied only to the secondary 20 MHz band within the 80 MHz band. For example, when applying the second perforation pattern, perforation can be applied only to any one of the two secondary 20 MHz bands within the secondary 40 MHz band included in the 80 MHz band. For example, when applying the third perforation pattern, perforation can be applied only to the secondary 20 MHz band within the primary 80 MHz band included in the 160 MHz band (or 80+80 MHz band). For example, when applying the fourth perforation pattern, perforation can be applied to at least one 20 MHz channel that does not belong to the primary 40 MHz band, provided that the primary 40 MHz band within the 80 MHz band included in the 160 MHz band (or 80+80 MHz band) is present.

[0161] Information related to the prelead puncture applied to the PPDU can be included in the U-SIG and / or UHR-SIG. For example, the first field of the U-SIG may include information related to continuous bandwidth, and the second field of the U-SIG may include information related to the prelead puncture applied to the PPDU.

[0162] For example, based on the following method, U-SIG and UHR-SIG can include information related to prelead punctures. When the bandwidth of the PPDU exceeds 80 MHz, U-SIG can be configured individually in 80 MHz units. For example, when the bandwidth of the PPDU is 160 MHz, the PPDU can include a first U-SIG for a first 80 MHz band and a second U-SIG for a second 80 MHz band. In this case, the first field of the first U-SIG can include information related to the 160 MHz bandwidth, and the second field of the first U-SIG can include information related to prelead punctures applied to the first 80 MHz band (i.e., information related to the prelead puncture pattern). Additionally, the first field of the second U-SIG can include information related to the 160 MHz bandwidth, and the second field of the second U-SIG can include information related to prelead punctures applied to the second 80 MHz band (i.e., information related to the prelead puncture pattern). Meanwhile, the UHR-SIG consecutive with the first U-SIG may include information related to the prelead via applied to the second 80 MHz band (i.e., information related to the prelead via pattern), and the UHR-SIG consecutive with the second U-SIG may include information related to the prelead via applied to the first 80 MHz band (i.e., information related to the prelead via pattern).

[0163] Additionally or alternatively, U-SIG and UHR-SIG may include information related to the preamble puncture, based on the following method: U-SIG may include information related to the preamble puncture for all frequency bands (i.e., information related to the preamble puncture pattern). That is, UHR-SIG may not include information related to the preamble puncture, while only U-SIG may include information related to the preamble puncture (i.e., information related to the preamble puncture pattern).

[0164] U-SIGs can be configured in 20 MHz units. For example, when an 80 MHz PPDU is configured, U-SIGs can be duplicated. That is, four identical U-SIGs can be included in an 80 MHz PPDU. PPDUs with bandwidths exceeding 80 MHz can include different U-SIGs.

[0165] Figure 5 The UHR-SIG can include control information for receiving STAs. The UHR-SIG can be transmitted using at least one symbol, and a symbol can have a length of 4 μs. Information related to the number of symbols used for the UHR-SIG can be included in the U-SIG.

[0166] UHR-SIG provides additional signals to the U-SIG field to enable the STA to interpret / decode the UHR PPDU. The UHR-SIG field may include U-SIG overflow bits that are typically applied to all users. In addition, the UHR-SIG field includes resource allocation information, allowing the STA to locate resources used in fields including the data field / UHR-STF / UHR-LTF (i.e., the UHR modulation field of the UHR PPDU).

[0167] It can be determined based on the RU (Resource Unit) defined by multiple subcarriers / tones. Figure 5 The diagram illustrates the frequency resources of the UHR-LTF, UHR-STF, and data fields. In other words, the UHR-LTF, UHR-STF, and data fields of this disclosure can be transmitted / received via RUs (Resource Units) defined by multiple subcarriers / tones.

[0168] Figure 6 This is a diagram illustrating the layout of a resource unit (RU) for a 20 MHz PPDU. That is, the UHR-LTF, UHR-STF, and / or data fields included in the 20 MHz PPDU can be... Figure 6 At least one of the various RUs defined in the code is used to send / receive.

[0169] like Figure 6 The topmost diagram shows a configuration that can accommodate 26 units (i.e., units corresponding to 26 tones). Six tones can be used for the guard band in the leftmost band of the 20 MHz frequency band, and five tones can be used for the guard band in the rightmost band of the 20 MHz frequency band. Furthermore, seven DC tones can be inserted in the center band (i.e., the DC band), and 26 units corresponding to 13 tones on each of the left and right sides of the DC band can be arranged. Units of 26, 52, and 106 can be allocated to other frequency bands. Individual units can be assigned to receiving STAs (i.e., users).

[0170] at the same time, Figure 6 The RU layout in the diagram can be used not only for multi-user (MU) but also for single-user (SU). In the single-user case, a 242 unit can be used and three DC tones can be inserted, such as... Figure 6 The bottom part is shown in the diagram.

[0171] Although Figure 6Various sizes of RUs have been proposed, namely 26-RU, 52-RU, 106-RU, and 242-RU, but RUs of a specific size can be expanded or increased. Therefore, this embodiment is not limited to individual RUs of a specific size (i.e., the number of corresponding tones). In this specification, an N-RU can be represented as an N-tone RU, etc. For example, a 26-RU can be represented as a 26-tone RU.

[0172] Figure 7 This is a diagram illustrating the layout of a resource unit (RU) for a 40 MHz PPDU.

[0173] With the use of RUs of various sizes Figure 6 Similarly, in Figure 7 Examples of frequencies that can be used include 26-RU, 52-RU, 106-RU, 242-RU, and 484-RU. Additionally, five DC tones can be inserted into the center frequency; 12 tones can be used for the leftmost guard band of the 40 MHz band; and 11 tones can be used for the rightmost guard band of the 40 MHz band.

[0174] like Figure 7 As shown, a 484-RU can be used when the RU layout is for a single user. The specific number of RUs can be similar to... Figure 5 Change.

[0175] Figure 8 This diagram illustrates the layout of a resource element (RU) for an 80 MHz PPDU. The layout of the resource element (RU) used in this specification can vary. For example, the layout of the resource element (RU) used in the 80 MHz band can be varied.

[0176] Figure 9 The operation related to the UL-MU is illustrated. As shown, a transmitting STA (e.g., an AP) can perform channel access through contention (i.e., backoff operation) and transmit a trigger frame 930. That is, the transmitting STA (e.g., an AP) can transmit a PPDU 930 including the trigger frame. When the PPDU including the trigger frame is received, a TB (trigger-based) PPDU is transmitted after a delay of SIFS.

[0177] Multiple TB PPDUs 941, 942 can be transmitted simultaneously and can be transmitted from multiple STAs (e.g., user STAs) whose AIDs are indicated in the trigger frame 930. The ACK frame 950 for the TB PPDU can be implemented in various forms.

[0178] Figure 10 The figure shows an example of a channel used / supported / defined within the 2.4 GHz band.

[0179] The 2.4 GHz band can also be referred to by other names, such as "first band". Furthermore, the 2.4 GHz band can refer to the frequency range used / supported / defined by channels having a center frequency adjacent to 2.4 GHz (e.g., channels having a center frequency between 2.4 GHz and 2.5 GHz).

[0180] The 2.4 GHz band can include multiple 20 MHz channels. Each 20 MHz channel within the 2.4 GHz band can have multiple channel indices (e.g., indices 1 to 14). For example, the center frequency of channel index 1 for a 20 MHz channel allocation could be 2.412 GHz, the center frequency of channel index 2 for a 20 MHz channel allocation could be 2.417 GHz, and the center frequency of channel index N for a 20 MHz channel allocation could be (2.407 + 0.005 GHz). (N) GHz. The channel index can be referenced by various names such as the channel number. The specific values ​​of the channel index and the center frequency can be changed.

[0181] Figure 10 Four channels within a 2.4 GHz frequency band are illustrated exemplarily. The first frequency region 1010 to the fourth frequency region 1040 shown may each include one channel. For example, the first frequency region 1010 may include channel 1 (the 20 MHz channel with index 1). In this case, the center frequency of channel 1 may be set to 2412 MHz. The second frequency region 1020 may include channel 6. In this case, the center frequency of channel 6 may be set to 2437 MHz. The third frequency region 1030 may include channel 11. In this case, the center frequency of channel 11 may be set to 2462 MHz. The fourth frequency region 1040 may include channel 14. In this case, the center frequency of channel 14 may be set to 2484 MHz.

[0182] Figure 11 The diagram illustrates an example of a channel used / supported / defined within the 5 GHz band.

[0183] The 5 GHz band can be referred to by other names, such as second band / band, etc. The 5 GHz band can refer to the frequency range that uses / supports / defines channels with a center frequency greater than or equal to 5 GHz and less than 6 GHz (or less than 5.9 GHz). Alternatively, the 5 GHz band can include multiple channels between 4.5 GHz and 5.5 GHz. Figure 11 The specific figures shown may vary.

[0184] Multiple channels within the 5 GHz band include the unlicensed National Information Infrastructure (UNII)-1, UNII-2, UNII-3, and ISM. UNII-1 may be referred to as the lower UNII. UNII-2 may include frequency ranges referred to as the middle UNII and the extended UNII-2. UNII-3 may be referred to as the upper UNII.

[0185] Within the 5 GHz band, multiple channels can be configured, and the bandwidth of each channel can be configured differently, such as 20 MHz, 40 MHz, 80 MHz, or 160 MHz. For example, the 5170 MHz to 5330 MHz frequency domain / range within UNII-1 and UNII-2 can be divided into eight 20 MHz channels. The 5170 MHz to 5330 MHz frequency domain / range can be divided into four channels using a 40 MHz frequency domain. The 5170 MHz to 5330 MHz frequency domain / range can be divided into two channels using an 80 MHz frequency domain. Alternatively, the 5170 MHz to 5330 MHz frequency domain / range can be divided into one channel using a 160 MHz frequency domain.

[0186] Figure 12 An example of using / supporting / defining a channel within the 6 GHz band is shown.

[0187] The 6 GHz band can be referred to by other names, such as the third band / band. The 6 GHz band can refer to the frequency range that uses, supports, and defines channels with center frequencies higher than 5.9 GHz. Figure 12 The specific values ​​shown may change.

[0188] For example, it can be defined starting from 5.940 GHz. Figure 12 The 20 MHz channel. Specifically, Figure 12 The leftmost channel in the 20 MHz channel array can have an index of 1 (or channel index, channel number, etc.) and be assigned a center frequency of 5.945 GHz. In other words, the center frequency of channel index N can be determined as (5.940 + 0.005 GHz). (N) GHz.

[0189] therefore, Figure 12The index (or channel number) of the 20 MHz channel can be 1, 5, 9, 13, 17, 21, 25, 29, 33, 37, 41, 45, 49, 53, 57, 61, 65, 69, 73, 77, 81, 85, 89, 93, 97, 101, 105, 109, 113, 117, 121, 125, 129, 133, 137, 141, 145, 149, 153, 157, 161, 165, 169, 173, 177, 181, 185, 189, 193, 197, 201, 205, 209, 213, 217, 221, 225, 229, 233. Furthermore, according to the above (5.940+0.005) N)GHz rules, Figure 12 The index of the 40 MHz channel can be 3, 11, 19, 27, 35, 43, 51, 59, 67, 75, 83, 91, 99, 107, 115, 123, 131, 139, 147, 155, 163, 171, 179, 187, 195, 203, 211, 219, 227.

[0190] The structure and type / subtype of MAC frames are described below.

[0191] Figure 13 An example of a MAC frame header is shown. As illustrated, a MAC frame may include a 2-octet frame control field / information, a 2-octet duration field / information, a 6-octet receiver address (RA) field / information, and a 6-octet sender address (TA) field / information. Figure 13 As shown, the four fields can be consecutive. They can be modified in various ways. Figure 13 The MAC header, and new fields can be inserted between the four fields shown, or at least one of the fields shown can be omitted.

[0192] Figure 13 The MAC header shown can be placed at the very beginning of the MAC frame. That is, a MAC frame can include, for example... Figure 13 The diagram shows the MAC header and the MAC body fields / information that follow the MAC header. This includes... Figure 13 The MAC frame header is inserted / included in the MAC frame. Figure 5 The data fields of the PPDU shown (e.g., UHR PPDU).

[0193] MAC frames included in the data field of the PPDU of this disclosure can be classified into various types. For example, MAC frames of this disclosure can be classified into control frames, management frames, and data frames.

[0194] For example, management frames include association requests, association responses, reassociation requests, reassociation responses, probe requests, probe responses, beacons, disassociation, authentication, and deauthentication frames / signals defined in a regular WLAN. For management frames, Figure 8 The values ​​of type fields B3 and B2 are set to 00. Additionally, Figure 8 The values ​​of the subtype fields B7, B6, B5, and B4 are as follows: Association Request (0000), Association Response (0001), Re-association Request (0010), Re-association Response (0011), Probe Request (0100), Probe Response (0101), Beacon (1000), Disassociation (1010), Authentication (1011), and Disauthentication (1100).

[0195] For example, control frames include trigger beamforming report polling, NDP announcement (NDPA), control frame extension, control wrapping, block Ack request (BlockAckReq), block Ack (BlockAck), PS-polling, RTS, CTS, Ack, and CF-end frames / signals as defined in traditional WLANs. For control frames, Figure 8 The values ​​of type fields B3 and B2 are set to 01. Furthermore, Figure 8 The values ​​of the subtype fields B7, B6, B5, and B4 are as follows: Trigger (0010), Beamforming Report Poll (0100), NDP Announcement (0101), Control Frame Extension (0110), Control Wrapper (0111), BlockAckReq (1000), BlockAck (1001), PS-Polling (1010), RTS (1011), CTS (1100), Ack (1101), and CF-End (1110).

[0196] For example, data frames include (QoS) data, (QoS) space, etc., as defined in a regular WLAN. For management frames, Figure 13 The values ​​of type fields B3 and B2 are set to 10.

[0197] The MAC frames / signals used in this disclosure can be identified by the aforementioned type field / information and subtype field / information. For example, a "trigger frame" in this disclosure may refer to a MAC frame in which type bits B3 and B2 in the frame control field of the MAC header are set to 01, and subtype bits B7, B6, B5, and B4 in the frame control field are set to 0010. The various MAC frames described in this disclosure are inserted into / included in the data fields of various PPDUs (e.g., HE / VHT / HE / EHT / UHR PPDUs).

[0198] Figure 14Examples of modifications to the transmitting and / or receiving apparatus of this disclosure are shown.

[0199] It is possible Figure 14 Modifications shown Figures 1 to 4 The device shown (e.g., AP STA, non-AP STA). Figure 14 The transceiver 630 can be used with Figure 1 The transceivers 113 and 123 are the same. Figure 14 The transceiver 630 may include a receiver and a transmitter.

[0200] Figure 14 The processor 610 can be with Figure 1 The processors 111 and 121 are the same. Alternatively, Figure 14 The processor 610 can be with Figure 1 The processing chips 114 and 124 are the same.

[0201] Figure 14 The memory 150 can be with Figure 1 The memory modules 112 and 122 are identical. Alternatively, Figure 14 The memory 150 can be different Figure 1 Separate external memories for memories 112 and 122.

[0202] Reference Figure 14 The power management module 611 manages the power of the processor 610 and / or transceiver 630. The battery 612 supplies power to the power management module 611. The display 613 outputs the results processed by the processor 610. The keyboard 614 receives input to be used by the processor 610. The keyboard 614 may be displayed on the display 613. The SIM card 615 may be an integrated circuit for securely storing the International Mobile Subscriber Identity (IMSI) and its associated keys, used for identifying and authenticating users in mobile devices such as mobile phones and computers.

[0203] Reference Figure 14 The speaker (640) can output the sound-related results processed by the processor 610. The microphone (641) can receive sound-related inputs to be used by the processor 610.

[0204] 1. Problems with conventional technologies (Fast BSS Transformation (FT))

[0205] Figure 15 Example of an over-the-air (OTA) FT protocol in a robust secure network (RSN).

[0206] Currently, in 802.11, non-AP STA mobility (roaming) (e.g., performing a Basic Service Set (BSS) transition from an access point (AP) (the old AP) to another AP (the new AP)) must undergo a reassociation process within the same mobility domain. A representative example is Fast BSS Transition (FT) technology. In FT, as... Figure 15 As shown, various processes such as authentication and re-association are performed using the FT Initiator (FTO) and the Target FT Response (FTR) (e.g., the new AP).

[0207] Following this process, many operational parameters (such as protocols related to Block Acknowledgment (BA), Flow Classification Service (SCS), Sequence Number (SN), Enhanced Distributed Channel Access Function (EDCAF) parameters, etc.) are reset. Therefore, there is overhead from which protocols / configurations must be re-executed with several frame exchanges, and data loss may also occur during the FT process. Furthermore, seamless roaming (e.g., roaming without interruptions from the perspective of a non-AP STA) is not readily achievable. Therefore, this specification proposes a seamless roaming method utilizing an Access Point Multilink Device (AP MLD) to address this problem. Unlike FT, authentication / association processes are no longer performed during roaming.

[0208] In this specification, the STA performing BSS transition (e.g., roaming) is referred to as RSTA, the AP currently associated with the STA based on the STA roaming is referred to as the old AP (O_AP), and the AP to which the STA is to roam is referred to as the new AP (N_AP). Furthermore, the roaming method presented in this specification is referred to as MLD roaming. The naming conventions in this specification may be changed, and the STA may include AP STAs or non-AP STAs.

[0209] 2. UHR AP MLD structure for roaming

[0210] 2.1 General process of roaming in AP MLD

[0211] Figure 16 Example of AP MLD's high-level architecture.

[0212] Basically, an Access Point Multilink Device (AP MLD) can include one or more access points and has features such as Figure 16 The high-level architecture is shown below. Essentially, the MLD can use the upper Media Access Control (MAC) sublayer to control various processes / parameters that commonly correspond to multiple APs. For example, these processes / parameters include authentication, association, sequence number / packet number (SN / PN) assignment, power-saving buffering for individually addressed frames, and so on.

[0213] Therefore, by using the AP MLD function, MLD-level parameters can be maintained without being reset based on movement between APs belonging to the AP MLD (member APs). This specification proposes an MLD roaming method utilizing the AP MLD function.

[0214] Figure 17 An example of the high-level architecture of UHR AP MLD.

[0215] Figure 17 This illustrates the architecture of an access point (AP) supporting seamless roaming. To support seamless roaming, compatibility with previous standard versions of the device must be maintained, and seamless roaming must be possible across many devices. First, to ensure legacy compatibility with previous devices, non-UHR non-access point stations (non-UHR non-AP STAs) must be able to see non-UHR APs. For this, the definition of the multi-link device (MLD) itself should not be violated, and the conventional architecture should not be altered. Therefore, as... Figure 17 As shown, a new UHR AP MLD is defined that belongs to a hierarchically roaming MLD while maintaining the conventional MLD architecture. In this case, each lower-level Media Access Control (LMAC) of the AP MLD interfaces with the upper-level MAC of the UHR (UHR UMAC), and the UMAC function of the AP MLD performing seamless roaming is managed by the UHR UMAC. This architecture also addresses the scalability issue caused by the bit size limitation of the link ID. Essentially, the link ID is 4 bits and only a maximum of 16 link IDs can be supported. During roaming, this link ID is required to move from one link to another, and in the conventional scheme, the number of APs that can roam is limited to 16. To solve this problem, the scalability issue is addressed by grouping link IDs using the AP MLD ID. This will be described in more detail in section 2.2, which will be discussed later.

[0216] Figure 18 Another example of the high-level architecture of UHR AP MLD.

[0217] Figure 18 Adopted and Figure 17 A similar architecture, but showing another example with a different interface. In Figure 18 In this architecture, the lower-level Media Access Control (LMAC) of the AP MLD and the UHR UMAC are not directly connected. Instead, the interface to the UMAC uses a Service Identifier to Link Mapping (TID to Link Mapping). Based on this architecture, TID to Link Mapping can be performed separately in the AP MLD's UMAC or in the UHR UMAC. There are no restrictions on the exploit schemes used for this architecture or on the type and number of functions that interface with the UHR UMAC.

[0218] Figure 19 An example of a roaming architecture in an AP MLD region.

[0219] Figure 19 The structure and process used for basic roaming are shown.

[0220] Each AP MLD is located in a different location (e.g., non-co-located), and APs belonging to each AP MLD are located in the same or similar locations (e.g., co-located). This "co-location" can mean that they belong to exactly the same physical device, or it can mean that they are logically similar in location even if they do not belong to the same physical device. Essentially, since an AP MLD is a logical entity, it can be any physical device, but it includes member APs (regardless of their location) and can be operated as an MLD that can apply multi-link operation (MLO). Ultimately, all APs belonging to each AP MLD become member APs of a single AP MLD. For example, Figure 19 AP MLD 1 includes AP 1, 2 and 3.

[0221] based on Figure 19 Based on non-AP MLD mobility, roaming typically involves moving from one AP MLD to another. For example, based on a non-AP MLD with multiple links established with the AP MLD and each STA 1 and STA 2 connected to AP2 and AP3 of AP MLD 1, roaming to AP MLD 2 allows STA 1 to connect to AP4 and STA 2 to AP5. In this case, each STA can temporarily establish associations with AP4 and AP5, allowing AP4 and AP5 to send frames to each STA during the roaming process.

[0222] For reference, Figure 19 In this context, the architecture can be applied to non-AP MLDs with one affiliated STA or non-AP STAs that are not MLDs, rather than non-AP MLDs with multiple affiliated STAs.

[0223] However, roaming is not only considered when moving between different AP MLDs. For example, even within an AP MLD, an AP can change location via roaming.

[0224] For example, a UHR AP MLD (or a group that can roam) belongs to at least one (Extremely High Throughput (EHT)) AP MLD, and each AP MLD is non-co-located, while the APs belonging to each AP MLD are co-located.

[0225] Typically, a non-AP MLD (or STA) performs a roaming from one AP MLD to another (it is said that even within a specific AP MLD, an AP can be changed through roaming).

[0226] Since the AP is modified within the AP MLD, roaming can be viewed as a method of changing links while maintaining multi-link setup without completely dismantling the regular multi-link setup.

[0227] Based on the fact that the AP is modified within the AP MLD, roaming can be seen as a method of changing links while maintaining multi-link establishment without completely dismantling the regular multi-link establishment.

[0228] These processes can be configured using a) announcing the process and b) frame switching.

[0229] a) Notification process: Each AP in the AP MLD notifies the STA of information related to the roaming APs within the AP MLD (whether the MLD roaming described in this specification can be performed).

[0230] b) Frame swapping process: This is the process of swapping frames that can trigger MLD roaming. Based on the completed frame swapping, MLD roaming is completed based on the negotiated information, and operations are no longer performed using O_AP but rather N_AP.

[0231] Specifically, this specification proposes the following methods for MLD roaming.

[0232] One or more STAs belonging to a non-AP MLD can each have a radio and establish multiple links. Therefore, a method is proposed to add and remove links using one of the STAs. Thus, two or more links can be connected to a single STA.

[0233] However, since frame switching is performed only on one link and cannot be performed on the remaining links, a hibernation or disabled state will occur.

[0234] - Essentially, for this purpose, non-AP MLDs notify the feasibility of the aforementioned capabilities by sending a management frame (e.g., an association request frame) that includes the basic multi-link ML IE during ML establishment. If all STAs are capable, this can be included in the MLD Capabilities and Operations subfields of the Common Information field, or if only some STAs are capable, it can be included in the Link Information field. The information to be included is as follows.

[0235] => Single Radio ML Establishment Enabled: STAs in a non-AP MLD can each have one radio and establish information for multiple links. Therefore, this means that two or more links can be connected to a single STA.

[0236] 2.2 Notification process for MLD roaming

[0237] Each AP in each AP MLD may announce whether roaming as outlined in this specification is feasible (e.g., whether frame switching is feasible, as described in b above). Relevant information is as follows and may include at least one or more items.

[0238] - MLD Roaming Enable: An indicator of whether roaming is feasible (e.g., it can be indicated by 1 bit).

[0239] - UHR AP MLD ID: An ID used to distinguish AP groups that are capable of MLD roaming. The configuration for this group ID is as follows.

[0240] A. ID configuration for roaming in AP MLD

[0241] Essentially, an ID can be assigned to a UHR AP MLD belonging to a shared AP MLD. In this specification, this is referred to as the UHR AP MLD ID. Such a UHR AP MLD ID can be unique within the UHR AP MLD, or it can be assigned a unique ID to UHR AP MLDs across the entire network. By defining UHR AP MLD IDs and differentiating UHR AP MLDs, scalability issues caused by a limited number of links can be addressed, and it can help identify more APs.

[0242] A-1) Unique ID configuration within the UHR AP MLD in the network

[0243] This section proposes a method for making UHR AP MLD IDs unique within a network. Essentially, UHR AP MLD IDs can be assigned values ​​such as 0, 1, 2, etc. For example, a UHR AP MLD ID with 4 bits can have values ​​from 0 to 15, and one with 8 bits can have values ​​from 0 to 127, and this size can be varied. The meaning of each UHR AP MLD ID is described below.

[0244] 1) Based on UHR AP MLD ID being 0: In this case, it can be known that the AP with this UHR AP MLD ID corresponds to an AP belonging to the same AP MLD (belonging to the same UHR AP MLD). For example, if this is identified based on a non-AP MLD (or STA), it can be identified that the corresponding AP currently belongs to the same UHR AP MLD. Therefore, roaming is feasible solely based on the UHR AP MLD ID being 0. Furthermore, since other APs (transmitting BSSID (TxBSSID) or non-transmitting BSSID (NonTxBSSID)) belonging to multiple basic service set IDs (multiple BSSIDs) sets to which each AP belongs to this UHR AP MLD also uses the same physical resources, this UHR AP MLD ID is assigned. However, the AP MLD IDs (TxBSSID or NonTxBSSID) of the AP MLDs to which these APs belong can be different.

[0245] Other UHR AP MLD IDs are mapped to be uniquely identified for each UHR AP MLD.

[0246] A-2) Unique ID Configuration within AP MLD

[0247] This section proposes a method for assigning unique IDs to APs that can roam within the entire UHR AP MLD.

[0248] - Temporary Link Addition / Removal: Indicates whether a link can be temporarily added to a STA or a link can be temporarily removed from a STA. For example, it means supporting a STA to have two or more links for a certain period of time (e.g., indicated by 1 bit).

[0249] - Co-location enabled: Indicates whether AP MLDs are co-located with each other (e.g., indicated by 1 bit).

[0250] => Based on co-configuration enabled=1, it means that the corresponding AP and the reporting AP are physically close. Therefore, based on the ability to communicate with APs with regular connections without moving to the AP set to 1, roaming can be avoided if co-configuration enabled is set to 1 among neighboring APs. For example, MLD roaming requests / responses will not be sent to or received from APs with co-configuration enabled=1.

[0251] - Common ID: An ID used to distinguish common AP MLDs. The configuration of this common ID is as follows.

[0252] B. Common ID configuration for roaming in UHR AP MLD

[0253] Basically, an ID can be assigned to a co-located AP MLD. In this specification, this is referred to as a co-located ID. Such a co-located ID can be unique within a set of co-located AP MLDs, or a unique ID can be assigned to a co-located AP MLD within a UHR AP MLD.

[0254] B-1. Unique Shared ID Configuration within the UHR AP MLD Co-location Set

[0255] This section proposes a method for making a co-located ID unique within a co-located AP MLD set. Essentially, a co-located ID can be assigned values ​​such as 0, 1, 2, etc. For example, based on a 4-bit co-located ID, it can have values ​​from 0 to 15, and based on an 8-bit co-located ID, it can have values ​​from 0 to 127, and this size can be varied. The meaning of each co-located ID is described below.

[0256] => Based on a co-location ID of 0: In this case, an AP with that co-location ID can be considered an AP belonging to the same co-location AP MLD set. For example, this can be identified based on the MLD (or STA), indicating that the corresponding AP is currently co-located. Furthermore, since other APs (TxBSSID or NonTxBSSID) in the multi-BSSID set to which each AP belongs to this set also use the same physical resources, this co-location ID is assigned. However, the AP MLD IDs of the AP MLDs (TxBSSID or NonTxBSSID) to which these APs belong can be different.

[0257] Multiple AP MLDs can be included in a set of APs with the same common ID.

[0258] Other co-located IDs are mapped to be uniquely identified for each co-located AP MLD set.

[0259] B-2) Unique Common ID Configuration within UHR AP MLD

[0260] This section proposes a method for assigning unique common IDs within a set of common AP MLDs in a UHR AP MLD. Essentially, common IDs can be assigned values ​​such as 0, 1, 2, etc. For example, based on a common ID having 4 bits, it can have values ​​from 0 to 15, and based on it having 8 bits, it can have values ​​from 0 to 127, and this size can be varied.

[0261] The above information can be included in management (MGMT) frames such as beacon or probe responses, and can also be included in the MLD roaming IE or regular simplified neighbor report (RNR) information element (IE) containing new MLD roaming information. Below is an example based on inclusion in the RNR IE. Basically, for each AP, the corresponding information can be included in the TBTT information field. In the MLD roaming parameters, including... Figure 20 and Figure 21 Add at least one or more fields, and can be as follows: Figure 20 and Figure 21 As shown in the diagram, it is included. Except... Figure 20 and Figure 21 In addition, it includes at least one or more of all fields defined in this specification.

[0262] Figure 20 An example of an RNR IE is shown.

[0263] Non-AP STAs only send and receive MLD roaming requests / responses to APs with common-enabled=0 via RNR IE.

[0264] Figure 21 Another example of an RNR IE is shown.

[0265] Non-AP STAs send and receive MLD roaming requests / responses only to APs with a common ID ≠ 0 via RNR IE.

[0266] like Figure 20 and Figure 21 As shown, due to the insufficient size of the regular MLD roaming parameter subfield, information can be included by creating a new MLD roaming parameter subfield in the RNR IE. The regular size can be changed, but this may cause decoding issues for 802.11beSTA. In this case, since including the MLD roaming parameter itself implies the ability to perform MLD roaming, MLD roaming enablement may not be included in the MLD roaming parameter subfield.

[0267] In RNR IE, such as Figure 20 As shown, overhead can be reduced by sending the co-configuration enable field only when sending whether another AP is co-configured or not with the AP currently sending beacon or probe responses. Furthermore, as... Figure 21 As shown, the AP's co-location ID can be used to indicate which AP is included in which co-location set. The RNR IE can include only one of the co-location enable field or the co-location ID, or it can include both.

[0268] Figure 22 This shows yet another example of an RNR IE.

[0269] like Figure 22 As shown, based solely on whether MLD roaming is possible, a standard MLD parameter subfield can be used to indicate that MLD roaming is enabled. Other information can be found as follows: Figure 20 The parameters shown are included as separate parameters.

[0270] 2.3 Recommendations for Roaming APs

[0271] Based on RNR IE, MLD roaming is enabled. For non-AP MLDs, information about the APs they want to roam to is requested via multi-link probe requests. In response, the MLD can notify the AP whether it is suitable for roaming via a multi-link probe response. MLD roaming enable can be set to 1 by sending ML probe request frames to roam to the corresponding AP.

[0272] 2.3.1 AP Recommended ML Probe Request Frame Format

[0273] An AP roaming recommendation enable field can be added to reduce the overhead that may occur when APs unnecessarily perform AP recommendations based on probe requests that are not intended for roaming.

[0274] 1) Based on being included in public information fields

[0275] Figure 23 This example demonstrates the AP roaming recommendation to enable field in the public information field.

[0276] Whether AP roaming recommendation enable is included can be indicated by the presence bitmap. Based on the case where it is only included in the public information field, this applies to all APs sending probe requests for roaming information. For example, if at least one or more APs are included in the ML probe request frame to perform another operation besides roaming, such as association, the AP roaming recommendation enable field is not added to the public information field.

[0277] 2) Based on what is included in the link information field

[0278] Figure 24 This example illustrates the AP roaming recommendation field in the Link Information field.

[0279] Based on the inclusion in the Link Information field, this is the case where information is requested individually for an AP used for roaming. Based on the inclusion of at least one or more APs in the ML Probe Request Frame to perform another operation besides roaming, such as association, the AP Roaming Recommendation Enable field can be added to the Link Information field.

[0280] 2.3.2 AP Recommended ML Probe Response Frame Format

[0281] Based on MLD roaming activation, non-AP MLD requests information about the AP it wants to roam to through a multi-link probe request for the activated AP, and in response, it can be notified whether the AP is suitable for roaming.

[0282] Add a recommended AP list to the probe response frame, which includes a list of link IDs of APs suitable for roaming.

[0283] 2.4 Frame Switching Process for MLD Roaming

[0284] Basically, to trigger MLD roaming, a frame exchange between a non-AP MLD (or STA) and an AP MLD is required. Here, an MGMT frame can be used as the frame, and specifically, an action frame of type MGMT can be used. This frame is referred to as follows.

[0285] - A frame in which a STA requests MLD roaming from an AP can be called an MLD roaming request frame.

[0286] - A frame in which the AP requests MLD roaming from the STA can be called an MLD roaming response frame.

[0287] 2.4.1 MLD Roaming Request Frame Format

[0288] The MLD roaming request frame format can be configured in the following order.

[0289] [Table 1]

[0290] Order 1: Basically, categories can be included in new UHR actions or protected UHR actions, and are not limited to this.

[0291] Order 4: Based on MLD roaming requests, the required information can be obtained by utilizing the reconfigured multi-link IE defined in the standard 802.11be.

[0292] - The modified reconfigured multi-link IE is as follows.

[0293] 1) Public Information Fields

[0294] Figure 25 An example of the common information field for reconfiguring multi-link IEs as proposed in this embodiment is shown.

[0295] From the perspective of STAs, especially non-AP MLDs, based on moving to a new AP and one or more STAs simultaneously performing MLD roaming, MLD capabilities and operational or EML capabilities may change. Therefore, such information can be additionally included in the common information field. As in the normal case, the existence of subfields of the common information field is determined by the existence bitmap.

[0296] 2) Link Information Field

[0297] As described in 1), performing MLD roaming based on one or more STAs simultaneously may require one or more per-STA profile elements.

[0298] Figure 26 An example of the link information field for reconfiguring multi-link IEs as proposed in this embodiment is shown.

[0299] Basically, based on the transition to another AP, from the perspective of the non-AP MLD, since the information about whether each link is transmitting and receiving simultaneously (STR) or not (NSTR) may change, an NSTR indicator bitmap can be included in the STA information field. Similarly, as in the normal case, the presence of subfields in the STA information can be determined by the presence subfield controlled by the STA.

[0300] Here, the link ID is indicated by the link ID corresponding to N_AP.

[0301] - A complete profile refers to all the information included in the association request frame, such as the complete information of the STA as in a normal case. However, since this is a case of a regular STA moving rather than a new STA, the capabilities or operating parameters for that STA may remain unchanged. Based on the AP MLD's knowledge of this, it can be used as an indication that only the changed information is included, rather than the complete profile.

[0302] => For example, as usual, based on a full profile = 0 (which is a partial profile), only information that will change upon moving to N_AP (e.g., fields / IE) is included in the STA profile. Alternatively, by referring to the full profile as the change profile, based on a value of 1, only information that will change upon moving to N_AP (e.g., fields / IE) is included in the STA profile.

[0303] - The MLD roaming timer refers to the time when MLD roaming is complete and operations are no longer performed using O_AP but instead using N_AP. For example, it can refer to the remaining time until the expected time before switching to the AP to be roamed. This relates to the TIM field, which is described later in 2.5.

[0304] => Based on applying the MLD roaming timer to all APs, it can be included in the common information field, which is consistent with... Figure 25 The difference is that the presence of the MLD roaming timer within the public information field can be indicated by the presence bitmap.

[0305] Since this information was sent by the STA, it can be interpreted as a reference to the AP MLD.

[0306] - UHR AP MLD ID, AP MLD ID, and common ID can be based on the following: Figure 25 and Figure 26 Included additionally in the above information. The AP MLD ID is the ID of the AP MLD to which the non-AP MLD (or STA) wants to roam, and the UHR AP MLD ID is the ID of the UHR AP MLD to which the AP MLD to which the non-AP MLD (or STA) wants to roam. The UHR AP MLD ID field may not exist in the reconfiguration multi-link element if the APMLD pre-checks the UHR AP MLD ID via beacon or probe request / response procedures and only sends roaming requests to the same UHR AP MLD. Such cases are described in Case 2 (included in 1-2) Common Information field, Case 2 (included in 2-2) Link Information field – always present), and Case 2 (included in 3-2) Link Information field – not always present.

[0307] For example, the description specifies the format for always including the UHR AP MLD ID, AP MLD ID, and common ID in a reconfigured multi-link IE, depending on whether it is used.

[0308] 1-1) Cases included in public information fields

[0309] Figure 27 An example is provided in this embodiment where the common information fields for reconfiguring multi-link IEs include UHR APMLD ID and AP MLD ID.

[0310] This can be indicated by the presence of a bitmap to determine whether the UHR AP MLD ID, AP MLD ID, and common ID are included. By including only these in the common information field, roaming requests can be made only to APs with the same UHR AP MLD ID, AP MLD ID, and common ID. For example, even within the same UHR AP MLD, requests cannot be made for multiple AP MLD IDs and multiple common IDs. For instance, one or more STAs cannot request reconfiguration to an AP belonging to a different AP MLD than the AP with the same common ID. However, since roaming to the same AP MLD is the general case, this reduces overhead compared to including them in each link information field as described below.

[0311] 1-2) Case 2 included in the public information field

[0312] Figure 28An example is shown where the common information field of the reconfigured multi-link IE proposed in this embodiment includes the AP MLD ID.

[0313] If the STA and AP have already checked and identified that N_AP and O_AP belong to the same UHR AP MLD through the previous association process, then there is no need to send the UHR AP MLD ID. This reduces overhead by eliminating the need to add a separate UHR AP MLD ID field. Figure 28 As shown. Except for whether or not the UHR AP MLD ID is included, the field inclusion method is the same as in case 1, which is included in the public information field (1-1).

[0314] 2-1) Case 1 included in the link information field – always exists

[0315] Figure 29 An example is shown where the link information field of the reconfigured multi-link IE proposed in this embodiment includes UHR AP MLDID and AP MLD ID.

[0316] The link information field may include multiple per-STA profile sub-elements, each of which can indicate a roaming request for an AP via a link ID. APs that a STA intends to roam can be distinguished by the AP MLD ID and UHR AP MLD ID in the STA control field of the per-STA profile element. This method allows roaming requests for multiple APs corresponding to multiple AP MLD IDs, but the overhead is greater than indicating this in the public information field if the requests are based on the same AP MLD ID.

[0317] 2-2) Case 2 included in the link information field – always exists

[0318] Figure 30 An example is shown where the link information field of the reconfigured multi-link IE proposed in this embodiment includes the AP MLD ID.

[0319] Since the STA and AP have already checked and recognized through the previous association process that N_AP and O_AP belong to the same UHR AP MLD, there is no need to send the UHR AP MLD ID. Therefore, it can proceed as follows: Figure 30 The UHR AP MLD ID field is added without additional overhead, as shown.

[0320] 3-1) Case 1 included in the link information field – not always present

[0321] Figure 31Another example is shown where the link information field of the reconfigured multi-link IE proposed in this embodiment includes UHR AP MLDID and AP MLD ID.

[0322] The presence of the UHR AP MLD ID and AP MLD ID in the STA control field of each STA profile sub-element indicates whether the UHR AP MLD ID and AP MLD ID corresponding to the AP with the link ID are included. The UHR AP MLD ID and AP MLD ID can be included in the STA information field or the STA profile field. Similarly, this method can request information for multiple APs corresponding to multiple AP MLD IDs. In particular, based on the common information field indication method of method 1), and based on roaming requests for APs corresponding to the same AP MLD ID, compared to method 2), overhead can be reduced by excluding the UHR AP MLD ID and AP MLD ID.

[0323] Alternatively, based on indicating the UHR AP MLD ID and AP MLD ID in the public information fields, it can be implicitly identified as a roaming request for an AP corresponding to the same UHR AP MLD ID and AP MLD ID, thus eliminating the need to include the UHR AP MLD ID and AP MLD ID. For example, the UHR AP MLD ID presence field and the AP MLD ID presence field can be omitted.

[0324] 3-2) Case 2 included in the link information field – not always present

[0325] Figure 32 Another example is shown where the link information field of the reconfigured multi-link IE proposed in this embodiment includes the AP MLD ID.

[0326] Since the STA and AP have already checked and recognized through the previous association process that N_AP and O_AP belong to the same UHR AP MLD, there is no need to send the UHR AP MLD ID. Therefore, it can proceed as follows: Figure 32 The UHR AP MLD ID field is not added separately to reduce overhead.

[0327] Additionally, since this manual includes the functionality to temporarily add and remove links for MLD roaming, it is necessary to indicate the method for this functionality, which can be done using the following method.

[0328] The basic usage uses 2 or more bits, and the types can be: Type 0: Add / Type 1: Delete / Type 2: Temporary Add / Type 3: Temporary Delete. Temporary Delete can be replaced with Type 1. Add indicates a request for an additional link connection between a STA of a non-AP MLD and an AP of an AP MLD. Delete indicates disconnecting (removing) the currently connected link. Temporary Add indicates a request for an additional connection with another AP besides the currently connected AP, allowing a STA of a non-AP MLD to be configured with multiple links.

[0329] => The temporary field in the above type field can be configured as a separate field. For example, use a 1-bit temporary field and a type field that does not include temporary addition / removal, and temporary addition can be configured by using the values ​​of two fields (e.g., temporary = 1, type = add).

[0330] Based on the simultaneous requests for deletion and addition during MLD roaming, the type of public information can be set to 4 or 5. For example, it can be defined as type 4: add then delete, and type 5: delete then add. With type 4, the link corresponding to the addition is added first, and then the link corresponding to the deletion is deleted. Conversely, with type 5, the link corresponding to the deletion is deleted first, and then the link corresponding to the addition is added.

[0331] Type 8 is based on the execution of a link switch. Unlike adding and deleting, a link switch allows a link to be immediately switched to another link.

[0332] The Add / Delete Link ID List field is optional and can be included based on the Type field being set to 4 or 5. The Link IDs corresponding to this Add / Delete Link ID List include a list of Link IDs for which both addition and deletion requests are being made simultaneously. When the Link information includes Link IDs in this list, based on the Type "Add," it indicates that the Link is being added among links being added and deleted simultaneously, and based on the Type "Delete," it indicates that the Link is being deleted.

[0333] The value of the type field in the link information needs to be separate from the value used for requesting both addition and deletion simultaneously, as only the type field required for adding or deleting links needs to be specified. The type value of the link information field can be configured as follows, but the values ​​and settings of the type field are not limited to those mentioned.

[0334] - Type 0: Add

[0335] Type 1: Delete

[0336] - Type 2: Temporary addition

[0337] Type 3: Temporary deletion

[0338] - Type 4: Add then delete (Add)

[0339] - Type 5: Add then delete (delete)

[0340] - Type 6: Delete then add (Add)

[0341] - Type 7: Delete then add (delete)

[0342] - Type 8: Link Switching

[0343] Type 4 refers to the case of a link being added during an operation where a link is added and then deleted; Type 5 refers to the case of a link being deleted during an operation where a link is added and then deleted.

[0344] Type 6 refers to the case where a link is being added during an operation of adding a link after deletion, and Type 7 refers to the case where a link is being deleted during an operation of adding a link after deletion.

[0345] Type fields and temporary fields may include the following, and include at least one or more of the following items.

[0346] 1) Cases where the information is included in the MLD roaming request frame body or the public information field of IE reconfiguration.

[0347] Figure 33 An example is shown in this embodiment where the public information field for reconfiguring multi-link IE includes a temporary field.

[0348] Based on this situation, only one operation can be performed for all APs. For example, based on adding, a request to add a link can be performed only for the APs indicated in the link information. Figure 33 This is an example that is included in public information.

[0349] 2-1) Cases included in the MLD roaming request frame body or the link information field of the reconfigured IE.

[0350] Figure 34 An example is shown in this embodiment where the link information field of the reconfigured multi-link IE includes a temporary field.

[0351] Based on this situation, different operations can be performed for each AP request. For example, an AP can be temporarily added for one request and deleted for another. Figure 34 This is an example that is included in the link information.

[0352] 2-2) Cases included in the MLD roaming request frame body or the link information field of the reconfigured IE.

[0353] Figure 35Another example is shown in this embodiment where the link information field of the reconfigured multi-link IE includes a temporary field.

[0354] Figure 35 This is an example of link information that includes a type field, based on the case where the UHR AP MLD ID field is omitted.

[0355] 3-1) Implementation method for sending add and delete requests simultaneously – First add new links and delete regular links based on intent.

[0356] - Based on the inclusion of both the type field and the add / delete link ID list field in the public information fields.

[0357] The type of the public information field is set to 4, and the link IDs of newly added links and deleted links are added to the add / delete link ID list. In this case, the link ID of the added link can precede the link ID of the deleted link in the list order. For example, based on the link ID of the added link being 5 and the link ID of the deleted link being 2, the add / delete link ID list can be set to 5, 2. Based on this method of determining the order, it is possible to know which link was added and which was deleted in the public information; however, since this can also be known through the type field of the link information field, setting the order may not be necessary.

[0358] Since it is already known from the public information whether a frame is requesting addition and deletion individually or both simultaneously, only types 0 and 1 can be used for the type in the link information field to indicate whether it is a link being added or deleted. Alternatively, based on sorting the link IDs in the list of added / deleted link IDs in the public information, overhead can be reduced by omitting the type field in the link information.

[0359] - Based on including only the type field in the public information fields

[0360] The type of the public information field is set to 4, and the types 0 and 1 in the link information field can be used to indicate whether it is a link that has been added or deleted.

[0361] - Based on the fact that the type field and the add / delete link ID list field are not included in the public information fields.

[0362] Based on this situation, you can use the type field value 4 or 5 of the link information field to request adding and then deleting links. In this case, the added link is set to type 4, and the deleted link is set to type 5. After adding the link set to type 4, the link set to type 5 is deleted.

[0363] 3-2) Implementation method for sending add and delete requests simultaneously – based on intent, first delete regular links and then add new links.

[0364] - Based on the inclusion of both the type field and the add / delete link ID list field in the public information fields.

[0365] The type of the public information field is set to 5, and other operations are implemented in the same way as in 3-1) when adding and deleting requests are sent simultaneously—based on intent, adding a new link first and deleting a regular link in the public information field include both the type field and the add / delete link ID list field.

[0366] - Based on including only the type field in the public information fields

[0367] The type of the public information field is set to 5, and other operations are implemented in the same way as in 3-1) when adding and deleting requests are sent simultaneously—adding a new link based on intent and deleting a regular link where only the type field is included in the public information field.

[0368] - Based on the fact that the type field and the add / delete link ID list field are not included in the public information fields.

[0369] Based on this situation, you can use the type field value 6 or 7 of the link information field to request adding and then deleting links. In this case, the added link is set to type 6, and the deleted link is set to type 7. After adding the link set to type 6, the link set to type 7 is deleted.

[0370] 4) Perform link switching based on the type field.

[0371] Figure 36 An example is shown in which the common information field of the reconfiguration multi-link IE proposed in this embodiment includes the AP removal timer field.

[0372] Based on link switching using Type 8 common information, instead of adding / removing links, the link sending the MLD roaming request frame is removed, and the switch is performed using the link ID in the link information field. For link switching, overhead can be reduced by omitting the type field in the link information field. Upon performing a link switch, both the AP and STA should know when the link switch should have been performed. This can be determined by the AP and communicated to the STA, or vice versa. Due to the different channels of the new and old APs, the new AP needs information about deletions, and the old AP needs information about additions.

[0373] Based on AP notifications to STA, this can be achieved by adding, as described later. Figure 37 or Figure 38 The channel switching count field in the MLD roaming response is notified. Based on the STA's determination and notification to the AP, the delete timer field in the reconfiguration element (or the AP's remove timer field) can be used in the MLD roaming request notification.

[0374] Based on the use of a reconfigured IE delete timer to notify the link switching completion time, and based on the fact that all links requesting link switching via MLD roaming requests have the same delete timer value, it is possible to... Figure 36 To reduce overhead, the delete timer field can be added to the public information instead of the link information, as is done in the previous example. In this case, the delete timer field can be omitted by using the delete timer existence field in the link information (or the AP remove timer existence field). Since the delete timer values ​​for links requesting link switching are different from each other, the delete timer field can be added to the link information instead of the public information. If there is only one link performing a link switch, the delete timer field can be added to the public information, and the delete timer field can also be added to the user information.

[0375] 2.4.2 MLD Roaming Response Frame Format

[0376] In the MLD roaming response frame, since the links should be changed while maintaining the establishment of multiple links, the link-level parameters that should be provided in essence need to be considered.

[0377] [Table 2]

[0378] Order 1: Basically, categories can be included in new UHR actions or protected UHR actions, and are not limited to this.

[0379] Order 4: Status codes can utilize the regular status code field.

[0380] Based on the response to the MLD roaming request, the basic multilink IE defined in standard 802.11be can be used to obtain the required information about the AP MLD and N_AP.

[0381] Order 5: The modified basic multi-link IE is as follows.

[0382] 1) Public Information Fields

[0383] Figure 37 An example of the common information field of the basic multi-link IE proposed in this embodiment is shown.

[0384] - Existing public information fields can be utilized. The public information here corresponds to the N_AP that performs MLD roaming for one or more STAs.

[0385] - Based on the inclusion of basic multilink elements when sending beacon or multilink probe response frames, the channel handover count existence field can be used instead of the channel handover count field.

[0386] In the reconfiguration IE based on the MLD roaming request frame, if the type field of the public information is set to type 8 or the type field of the user information is set to type 8, the channel handover count field can be included in the public information of the basic ML IE. Based on being included in the public information, and based on the fact that one or more links simultaneously requesting link handover through an MLD roaming request should complete the handover to the new link at the same time, the AP can use the channel handover count field of the public information to notify when the link handover should be performed. The link handover count indicates the number of TBTTs received from the AP connected via the existing link before the link handover to the new link. Through the channel handover count field, the AP can notify the STA when the link handover to the new link should be performed.

[0387] 2) Link Information Field

[0388] As described in 1), based on the simultaneous execution of MLD roaming by one or more STAs, the corresponding AP may require one or more per-STA profile sub-elements.

[0389] The following information pertains to the changes to the STA control field, STA information field, and STA profile field in a standard basic multi-link IE.

[0390] Figure 38 An example of the link information field of the basic multi-link IE proposed in this embodiment is shown.

[0391] Basically, the link ID in the STA information field is indicated by the link ID corresponding to N_AP.

[0392] - A complete profile refers to all the information included in the sent associated response frame, such as the complete information of the AP in a normal situation. However, since the STA performs MLD roaming, the AP's capabilities or operating parameters may not be changed. Therefore, in this case, the complete profile is indicated as 0.

[0393] - Additionally, information regarding the MLD roaming timer is included. For this purpose, the MLD roaming timer presence field is included in the STA control field, and the MLD roaming timer field is included in the STA information field. This signifies the time when MLD roaming is completed and the operation is no longer performed using O_AP but instead using N_AP. This can be achieved using the MLD roaming timer information sent by the STA, and may not be included if the STA has already sent this information and responded with a success status code.

[0394] Based on including basic multi-link IEs when included in associated requests / responses, since roaming-related information is not required, basic ML elements can be configured without adding them using existence fields. Figure 37 This includes the UHR MLD MAC address, UHR AP MLD ID, co-configuration ID, channel handover count, and UHR roaming timer. Figure 38 It includes the MLD roaming timer, UHR AP MLD ID, AP MLD ID, and channel switching count field.

[0395] Since the time required for link handover to be completed varies for each link, a channel handover count field can be added to the link information to individually notify each link of when the handover should be completed. Since an MLD roaming request only requests a handover for one link, the channel handover count field can be included in the public information or in the link information.

[0396] - The UHR AP MLD ID and AP MLD ID can be additionally included in the above information as follows: The AP MLD ID is the ID of the AP MLD to which the non-AP MLD (or STA) will roam, and the UHR AP MLD ID is the ID of the UHR AP MLD to which the AP MLD to which the non-AP MLD (or STA) will roam. Since the UHR AP MLD ID is not included in the MLD roaming request frame, it can be known that they belong to the same UHR AP MLD, and therefore the UHR AP MLD ID field can be omitted. This situation is described in Case 2 (included in 1-2) Common Information field, Case 2 (included in 2-2) Link Information field – always present), and Case 2 (included in 3-2) Link Information field – not always present.

[0397] 1-1) Cases included in public information fields

[0398] This applies based on the method of requesting via the public information field case 1, which is included in the above-mentioned reconfiguration ML IE.

[0399] Similarly, a bitmap is used to indicate whether the UHR AP MLD ID and AP MLD ID are included, and accordingly, the UHR AP MLD ID and AP MLD ID are included in the public information field. This allows information to be provided only for APs with UHR AP MLD ID=0 and common ID≠0.

[0400] 1-2) Case 2 included in the public information field

[0401] This applies based on the method of requesting via the public information field 2, which is included in 1-2) of the above-mentioned reconfiguration ML IE.

[0402] Similarly, the presence of a bitmap indicates whether the AP MLD ID is included, and accordingly, the AP MLD ID is included in the public information field.

[0403] 2-1) Case 1 included in the link information field – always exists

[0404] This applies based on the method of requesting via the link information field (2-1) included in the above-mentioned reconfiguration ML IE – which is always present.

[0405] The UHR AP MLD ID and APMLD ID corresponding to the AP corresponding to the link ID of each per-STA profile sub-element are included in the STA control field. This can provide information about multiple APs corresponding to multiple AP MLD IDs, but providing this information based on the same AP MLD ID is more expensive than indicating it in the common information field.

[0406] 2-2) Case 2 included in the link information field – always exists

[0407] This applies based on the method of requesting via the link information field (2-2) included in the above-mentioned reconfigured ML IE – which is always present.

[0408] The AP MLD ID corresponding to the AP corresponding to the link ID of each per STA profile sub-element is included in the STA control field. This can provide information about multiple APs corresponding to multiple AP MLD IDs, but providing this information based on the same AP MLD ID incurs greater overhead than indicating it in the common information field.

[0409] 3-1) Case 1 included in the link information field – not always present

[0410] This applies based on the method of requesting via the link information field (3-1) included in the above-mentioned reconfiguration ML IE—which is not always present.

[0411] Whether the AP MLD ID corresponding to the AP corresponding to the link ID is included can be indicated by the presence of the UHR AP MLD ID and the AP MLD ID in the STA control field of each STA profile sub-element. The UHR AP MLD ID and AP MLD ID can be included in the STA information field or the STA profile field. Similarly, this can provide information about multiple APs corresponding to multiple AP MLD IDs. In particular, based on the indication method in the common information field of method 1), and by providing only information about APs corresponding to the same AP MLD ID, compared to method 2), overhead can be reduced by excluding the UHR AP MLD ID and AP MLD ID.

[0412] => Meanwhile, in the case of a unique ID configuration within the common set of AP MLDs related to the above AP MLD ID settings, the UHR AP MLD ID, AP MLD ID, and common ID can be omitted based on the common ID being 0. For example, if the common ID does not exist, the AP receiving the request can implicitly identify that it is a request for information from other APs in its AP MLD.

[0413] => Alternatively, based on indicating the common ID in the public information, it is possible to implicitly identify that it is information of an AP corresponding to the same common set, and therefore the UHR AP MLD ID, AP MLD ID, and common ID may not be included. For example, the fields for UHR AP MLD ID presence and AP MLD ID presence may not be included.

[0414] 3-2) Case 2 included in the link information field – not always present

[0415] This applies based on the method of requesting via the link information field (3-2) included in the above-mentioned reconfiguration ML IE—which is not always present.

[0416] Whether the AP MLD ID corresponding to the AP corresponding to the link ID is included can be indicated by the presence of the AP MLD ID in the STA control field of each STA profile sub-element. The AP MLD ID can be included in the STA information field or the STA profile field. Similarly, this can provide information about multiple APs corresponding to multiple AP MLD IDs. In particular, based on the indication method in the common information field of method 1), and based on providing only the information of APs corresponding to the same AP MLD ID, the overhead can be reduced by excluding the AP MLD ID compared to method 2).

[0417] => Meanwhile, in the case of a unique ID configuration within the common set of AP MLDs related to the aforementioned AP MLD ID settings, the AP MLD ID and the common ID can be omitted based on the common ID being 0. For example, if the common ID does not exist, the AP receiving the request can implicitly identify that it is a request for information from other APs within its own AP MLD.

[0418] => Alternatively, based on indicating the common ID in the public information, it is possible to implicitly identify that it is information of an AP corresponding to the same common set, and therefore the AP MLD ID and common ID may not be included. For example, the UHR AP MLD ID presence and AP MLD ID presence fields may not be included.

[0419] Order 6: Group Key Information

[0420] Basically, since the group key is different for each link, group key information needs to be provided for N_AP.

[0421] Figure 39 Example of a group key information field.

[0422] refer to Figure 39 The length indicates the length of the group key information. The group key information for each N_AP includes MLO GTKKDE format, MLO IGTK KDE, and MLO BIGTK KDE. The MLO BIGTK KDE includes the link ID of each N_AP as defined in 802.11be.

[0423] Order 7: Due to the limited total AID (Associated Identifier) ​​space, AIDs can be managed within each AP MLD. For example, an AID can be assigned based on roaming to another AP MLD. However, AIDs may not be included in the following cases.

[0424] - Based on roaming to another AP MLD and assigning the same AID

[0425] - Based on UHR AP MLD, manage the total AID space as usual.

[0426] Orders 8 and 9: Based on being included in this way, it can be assumed that each AP performing roaming has the same channel but a different channel than the previously connected APs. However, the following cases can be included differently for orders 8 and 9.

[0427] - Based on the assumption that all APs with MLD roaming enabled are always on the same channel, excluding these IEs.

[0428] - The channel of an AP to be roamed to can be the same as or different from the channel of a previously connected AP. In this case, the Channel Switching Announcement (IE) or Extended Channel Switching Announcement (ESI) can be included in the link information of the basic multilink IE present in sequence 5. For example, this is used to perform a channel switch for each AP to which the roaming is to take place.

[0429] Order 10: This can be used to pre-map TIDs to links for new connections via TID-to-link mapping. A default mapping can be applied without performing TID-to-link mapping separately.

[0430] In addition, an MLD roaming timer can be added to both the MLD roaming request and response frames.

[0431] Additionally, the AP MLD may include the MLD roaming timer for reconfiguring the ML IE as described above. Similarly, based on the AP MLD's current ability to control roaming, a predetermined MLD roaming timer can be indicated. For example, if the STA does not include an MLD roaming timer or it is unsuitable, the AP MLD may set and notify the timer. Additionally, if the STA does not send an MLD roaming timer, the AP MLD may set and notify the timer. The meaning of the MLD roaming timer is the same. For example, it signifies the time when MLD roaming is complete and operations are no longer performed using O_AP but instead using N_AP.

[0432] => Based on receiving a temporary add request, after the MLD roaming timer expires, the STA completely disconnects from the O_AP (e.g., temporarily deletes or removes) and can connect to the N_AP.

[0433] => Based on the common application of the MLD roaming timer to all APs, it can be included in the common information field. In this case, the presence of the common information field can be indicated by a bitmap.

[0434] - Additionally, information regarding the MLD roaming timer can be included in the MLD roaming response frame. For this purpose, the MLD roaming timer presence field is included in the STA control field, and the MLD roaming timer field is included in the STA information field. This can refer to the remaining time until the STA can receive data from the AP it is about to roam to. This can also utilize the MLD roaming timer information sent by the STA. This is essentially related to the TIM field presented in 2.5.

[0435] => Since the MLD roaming timer is applied commonly to all APs, it can be included in the common information field. In this case, the presence of the common information field can be indicated by a bitmap. Alternatively, it can be included in the MLD roaming probe response frame body.

[0436] 2.5 MLD Roaming Example

[0437] The operation process for AP and STA to perform MLD roaming is as follows.

[0438] Figure 40 This example illustrates a procedure for checking whether N_AP can perform roaming using the common enable field.

[0439] refer to Figure 40 The AP's sending and receiving process is as follows.

[0440] The O_AP includes the RNR IE in the beacon and sends it to the STA. Based on the MLD roaming request frame received from the STA, the O_AP checks the AP to which the STA intends to roam using the link ID, AP MLD ID, and UHR AP MLD ID (optional). The O_AP sends the STA a roaming response frame, indicating whether it accepts the request and providing the information described in the roaming response frame format.

[0441] refer to Figure 40 The STA's sending and receiving process is as follows.

[0442] Based on the received beacon, the STA checks the presence of the MLD roaming parameter field in the TBTT information field. The STA checks the MLD roaming enable, UHR AP MLD ID, and co-configuration enable fields within the MLD roaming parameter field. At this time, MLD roaming enable = 1, UHR AP MLD ID = 0, and co-configuration enable = 0 are set. The STA sends an MLD roaming request frame to O_AP. The STA receives an MLD roaming response frame from O_AP and roams to N_AP based on acceptance.

[0443] Figure 41 This example illustrates a procedure for checking whether N_AP can perform roaming using a common ID.

[0444] refer to Figure 41 The AP's sending and receiving process is as follows.

[0445] The O_AP includes the RNR IE in the beacon and sends it to the STA. Based on the MLD roaming request frame received from the STA, the O_AP checks the AP to which the STA intends to roam using the link ID, AP MLD ID, and UHR AP MLD ID (optional). The O_AP sends the STA a roaming response frame, indicating whether it accepts the request and providing the information described in the roaming response frame format.

[0446] refer to Figure 41 The STA's sending and receiving process is as follows.

[0447] Based on the received beacon, the STA checks the presence of the MLD roaming parameter field in the TBTT information field. The STA checks the MLD roaming enable, UHR AP MLD ID, and common ID within the MLD roaming parameter field. At this time, MLD roaming enable = 1, UHR AP MLD ID = 0, and common ID ≠ 0 are set. The STA sends an MLD roaming request frame to O_AP. The STA receives an MLD roaming response frame from O_AP and roams to N_AP based on acceptance.

[0448] Figure 42 An example of an MLD roaming process where the UHR AP MLD ID is included in a reconfiguration element.

[0449] refer to Figure 42 The AP's sending and receiving process is as follows.

[0450] O_AP sends information about other APs to STA via beacons. Based on the MLD roaming request frame received from STA, STA checks the ID of the AP it intends to roam to using the link ID and AP MLID. Additionally, STA also checks the UHR AP MLD ID, since the UHR AP MLD ID is included in the MLD roaming request frame. O_AP sends whether it accepts the request and the information described in 2.4.2 Roaming Response Frame Format to STA via an MLD roaming response frame.

[0451] refer to Figure 42 The STA's sending and receiving process is as follows.

[0452] The STA receives information about other APs from the beacon via O_AP. Based on the information received from O_AP, the STA determines the AP to roam to. The STA sends a roaming request frame to O_AP. The STA receives an MLD roaming response frame from O_AP and roams to N_AP upon acceptance.

[0453] Figure 43 Example of an MLD roaming process based on UHR AP MLD ID not included in the reconfiguration element.

[0454] refer to Figure 43 The AP's sending and receiving process is as follows.

[0455] O_AP sends information about other APs to STA via beacons. Based on the MLD roaming request frame received from STA, STA checks the ID of the AP it intends to roam to using the link ID and AP MLID. O_AP sends an MLD roaming response frame to STA indicating whether it accepts the request and the information described in 2.4.2 Roaming Response Frame Format.

[0456] refer to Figure 43 The STA's sending and receiving process is as follows.

[0457] The STA receives information about other APs from the beacon via O_AP. Based on the information received from O_AP, the STA determines which AP to roam to. The STA sends a roaming request frame to O_AP. The STA receives an MLD roaming response frame from O_AP and, based on acceptance, roams to N_AP.

[0458] Figure 44 An example of a co-located AP set is shown.

[0459] Figure 44 This example illustrates how roaming is determined based on colocation information when a non-AP MLD moves while normally connected to AP 2. Colocation information can be obtained through the colocation enable field or colocation ID field of the RNR IE. Although AP 4 and AP 5, belonging to AP MLD 2, are also present around the non-AP MLD, the non-AP MLD does not initiate roaming requests for AP 4 and AP 5 because these APs are included in the same colocation AP set as the currently connected AP 2. On the other hand, for the non-AP MLD, roaming requests are possible for AP 6, AP 7, and AP 8, which are included in a different colocation AP set than AP 2. By defining the colocation AP set in this way and informing physically nearby APs that do not require roaming, unnecessary roaming can be prevented.

[0460] 1) Example #1 - Based on only some STAs roaming to the AP first

[0461] Figure 45 Example 1 illustrates the MLD roaming process.

[0462] Figure 45This refers to the situation where only some STAs roam to the AP first, rather than all STAs immediately moving to another AP MLD. For example, STA 1 roams from AP 1 to AP 3 first, and then STA 2 roams from AP 3 to AP 5. In this implementation, there are two STAs in a non-AP MLD, but even if there are three STAs, only two STAs can roam first and the remaining STAs can roam subsequently.

[0463] In this implementation, STA 1 and AP 1, as described above, can first exchange MLD roaming requests / responses. STA 1 will indicate the (optional) UHR AP MLD ID, AP MLD ID, and link ID for AP 4 in the MLD roaming request, and AP 1 will provide this information by including information about AP 4 along with whether or not the request is accepted in the Basic Multilink IE. Next, STA 2 and AP 3 will also perform the same process for AP 5. At this point, STA 1 can perform the corresponding process with the connected AP 4 instead of STA 2.

[0464] Based on this example, it can be effective in receiving data. While AP 1 and STA 1 are performing roaming, AP 2 and STA 3 can exchange data, and while AP 3 and STA 2 are performing roaming, AP 4 and STA 1 can exchange data. At this time, all TIDs need to be mapped to each link exchanging data. However, this implementation is difficult to apply based on the presence of STAs that are not MLDs or the presence of one STA within an MLD, and frame switching overhead can relatively occur.

[0465] Figure 46 Example 1 illustrates the operation process of the MLD roaming process.

[0466] refer to Figure 46 The AP's sending and receiving process is as follows.

[0467] AP 1 receives a roaming request frame from STA 1. STA checks the ID of the AP to which STA intends to roam using the link ID, AP MLD ID, and UHR AP MLD ID (optional). AP 1 sends an MLD roaming response frame to STA 1 indicating whether it accepts the request and the information described in 2.4.2 Roaming Response Frame Format for AP 4 and AP 5.

[0468] refer to Figure 46 The STA's sending and receiving process is as follows.

[0469] STA 1 sends MLD roaming request frames to AP 1 for AP 4 and AP 5. Based on receiving roaming acceptance via an MLD roaming response frame from AP 1, STA 1 roams to AP 4 based on the received information about AP 4. Based on STA 1's roaming completion, STA 2 also roams to AP 4 based on whether AP 5 is accepted via STA 1 and the information about AP 4 and AP 5.

[0470] 2) Example #2 - Based on all STAs immediately moving to another group of APs

[0471] Figure 47 Example 2 illustrates the MLD roaming process.

[0472] Figure 47 This refers to the case where all STAs immediately move to another group of APs. For example, STA 1 immediately roams from AP 1 to AP 3 and STA 2 immediately roams from AP 3 to AP 5.

[0473] In this implementation, STA 1 and AP 1 or STA 2 and AP 3, as described above, can exchange MLD roaming requests / responses. In this case, the MLD roaming request will indicate the UHR AP MLD ID (optional), APMLD ID, and link ID for AP 4 and AP 5, and AP 1 or AP 3 will provide this information by including information about AP 4 and AP 5 along with whether or not the request is accepted in the Basic Multilink IE.

[0474] Based on this example, frame overhead can be reduced compared to Example 1, and data latency can be reduced according to the AP MLD roaming domain structure. For example, based on the anchored AP managing data reception from the DS and MLD roaming existing in the AP MLD, and based on the anchored AP accepting MLD roaming requests, data paths can be pre-defined for roaming.

[0475] Figure 48 Example 2 illustrates the operation process of the MLD roaming process.

[0476] refer to Figure 48 The AP's sending and receiving process is as follows.

[0477] AP 1 receives a roaming request frame from STA 1. STA checks the ID of the AP to which STA intends to roam using the link ID, AP MLD ID, and UHR AP MLD ID (optional). AP 1 sends an MLD roaming response frame to STA 1 indicating whether it accepts the request and the information described in 2.4.2 Roaming Response Frame Format for AP 4 and AP 5.

[0478] refer to Figure 48 The STA's sending and receiving process is as follows.

[0479] STA 1 sends MLD roaming request frames to AP 1 for AP 4 and AP 5. Based on receiving roaming acceptance via an MLD roaming response frame from AP 1, STA 1 roams to AP 4 based on the received information about AP 4. Based on STA 1's roaming completion, STA 2 also roams to AP 4 based on whether AP 5 is accepted via STA 1 and the information about AP 4 and AP 5.

[0480] 3) Example #3 – This is used to perform temporary addition and deletion procedures separately (these procedures can be executed simultaneously using a timer).

[0481] Figure 49 Example 3 illustrates the MLD roaming process.

[0482] Figure 49 This is an example where STA 1 first performs a temporary addition for AP 4 and STA 2 performs a temporary addition for AP 5, and then AP 1 and AP 3 are deleted respectively.

[0483] In this implementation, for the temporary addition described above, STA 1 and AP 1, or STA 2 and AP 3, can first exchange MLD roaming requests / responses. At this time, the UHR AP MLD ID (optional), AP MLD ID, and link ID for AP 4 and AP 5 will be indicated in the MLD roaming request, and AP 1 or AP 3 will provide this information by including information about AP 4 and AP 5 along with whether or not the request is accepted in the Basic Multilink IE. Based on this process, STA 1 will temporarily connect with AP 1 and AP 4, and STA 2 will temporarily connect with AP 3 and AP 5. STA 1 can send or receive data from AP 1 and AP 4. For example, frame exchange with AP 4 may not be performed based on frame exchange with AP 1. Next, STA 1 performs a temporary deletion (or removal) operation for AP 1, and STA 2 performs a temporary deletion (or removal) operation for AP 3. Through this process, roaming from STA 1 to AP 4 and from STA 2 to AP 5 is completed.

[0484] The example above illustrates the process of performing temporary additions and deletions separately. Here, based on the use of a timer, this process can be performed simultaneously. For example, STA 1 and AP 1, or STA 2 and AP 3, can exchange MLD roaming requests / responses. In this case, deletions (or temporary deletions) for AP 1 and AP 3, and temporary additions for AP 4 and AP 5, are simultaneously requested in the MLD roaming request. At this point, the MLD roaming timer presented above is set. As mentioned above, this can be set by a non-AP MLD or an AP MLD via the MLD roaming response. After the MLD roaming response is successfully sent, the timer runs, and based on the timer expiration, the AP 1 link is removed from STA 1 and fully connected to AP 4, and AP 3 is removed from STA 2 and fully connected to AP 5.

[0485] Figure 50 Example 3 illustrates the operation process of the MLD roaming process.

[0486] refer to Figure 50 The AP's sending and receiving process is as follows.

[0487] AP 1 receives a roaming request frame from STA 1. STA checks the ID of the AP it intends to roam to using the link ID, AP MLD ID, and UHR AP MLD ID (optional). AP 1 sends an MLD roaming response frame to STA 1 indicating whether it accepts the request, along with information described in section 2.4.2 (Roaming Response Frame Format) for AP 4 and AP 5. AP 1 sets an MLD roaming timer. At this point, based on the MLD roaming timer timeout, the regular connection is completely deleted and a new connection is established in the roaming AP.

[0488] refer to Figure 50 The STA's sending and receiving process is as follows.

[0489] STA 1 sends MLD roaming request frames to AP 1 for both AP 4 and AP 5. Based on receiving roaming acceptance via an MLD roaming response frame from AP 1, STA 1 roams to AP 4 based on the received information about AP 4. Based on STA 1's roaming completion, STA 2 also roams to AP 4 based on the acceptance / disapproval received from STA 1 for AP 5, as well as information about AP 4 and AP 5. STA 1 sets an MLD roaming timer. At this point, based on the MLD roaming timer expiring, the regular connection is completely deleted and a new connection is established in the roaming AP.

[0490] 4) Examples #4 to #6 – The process of deleting and then adding or adding and then deleting.

[0491] Figure 51 Example 4 illustrates the MLD roaming process.

[0492] Figure 51 This is an example where STA 1 first deletes (or temporarily deletes) AP 1 and STA 2 deletes (or temporarily deletes) AP 3, and then AP 4 and AP 5 are added (or temporarily added) respectively.

[0493] In this implementation, for the deletion described above, STA 1 and AP 1, or STA 2 and AP 3, can first exchange MLD roaming requests / responses. At this time, the MLD roaming request will indicate the (optional) UHRAP MLD, AP MLD ID, and link ID for AP 4 and AP 5, and AP 1 or AP 3 will provide this information by including information about AP 4 and AP 5 along with whether or not the request is accepted in the Basic Multilink IE. Based on this process being completed, STA 1 or STA 2 can disconnect from AP 1 and AP 3. Even in the case of a link deletion, if data comes from an AP that has already performed link deletion, the STA that has not yet deleted the link can instead receive the data, or the UHR AP MLD can send it to the AP to which it will roam and have that AP send the data after roaming. Next, STA 1 performs an add operation for AP 4, and STA 2 performs an add operation for AP 5. Through this process, roaming from STA 1 to AP 4 and from STA 2 to AP 5 is completed.

[0494] The example above illustrates the process of performing temporary additions and deletions separately. Here, based on the use of a timer, this process can be performed simultaneously. For example, STA 1 and AP 1, or STA 2 and AP 3, can exchange MLD roaming requests / responses. In this case, deletions (or temporary deletions) for AP 1 and AP 3, and additions (or temporary additions) for AP 4 and AP 5, can be requested simultaneously in the MLD roaming request or can be sent separately. The MLD roaming timer presented above is then set. As mentioned above, this can be set by a non-AP MLD or an AP MLD via the MLD roaming response. After the MLD roaming response is successfully sent, the timer runs, and based on the timer expiration, the AP 1 link is removed from STA 1 and fully connected to AP 4, and AP 3 is removed from STA 2 and fully connected to AP 5.

[0495] Figure 52 Examples 3 and 4 illustrate the operation process of MLD roaming.

[0496] refer to Figure 52The AP's sending and receiving process is as follows.

[0497] AP 1 receives a roaming request frame from STA 1. STA 1 and STA 2 check the IDs of the APs (AP 4 and AP 5) they intend to roam to using the link ID, AP MLD ID, and UHR APMLD ID (optional). AP 1 sends an MLD roaming response frame to STA 1 indicating whether it accepts the request and providing the information for AP 4 and AP 5 described in the roaming response frame format section 2.4.2. AP 1 sets an MLD roaming timer. At this point, based on the MLD roaming timer timeout, the regular connection is completely deleted and a new connection is established in the roaming AP.

[0498] refer to Figure 52 The STA's sending and receiving process is as follows.

[0499] STA 1 sends MLD roaming request frames to AP 1 for AP 4 and AP 5. At this time, STA 1 requests the removal (or temporary removal) of AP 1 and AP 2 and the temporary addition of AP 4 and AP 5. STA 1 receives the acceptance of the roaming requests for AP 4 and AP 5, as well as information about the APs, by receiving an MLD roaming response frame from AP 1 (see 2.4.1). STA 1 sets an MLD roaming timer. At this time, based on the MLD roaming timer timeout, the regular connection is completely removed and a new connection is established in the roaming AP.

[0500] Figure 53 Example 5 illustrates the MLD roaming process.

[0501] Figure 54 Example 6 illustrates the MLD roaming process.

[0502] Figure 53 and Figure 54 This is an implementation method for setting the type field of an MLD request frame based on simultaneously sending link add and delete requests. Figure 53The process begins with a non-AP MLD requesting a link addition to roam to the new AP MLD (AP MLD 2). Based on the established connection between STA 1 and AP 4, a request is made to remove the connection to AP 1, which is normally connected to STA 1. Based on the addition and removal requests, the request can be sent to the AP using the link ID and the AP MLD ID. After a removal request is sent and the connection between STA 1 and AP 1 is completely removed, STA 1 cannot send or receive data with AP MLD 1. However, because STA 2 (non-AP MLD) is connected to AP 3 (AP MLD 1), both the non-AP MLD and AP MLD 1 can send and receive data. Therefore, data discontinuity during roaming can be reduced. Once the link change for STA 1 is complete, STA 2 can similarly request a link addition for AP 5 and then disconnect from AP 3 to fully roam to the new AP MLD 2. At this point, since AP MLD 1 and AP MLD 2 belong to the same AP MLD for seamless roaming, the data accumulated in the queue of AP MLD 1 can be transferred to AP MLD 2. Figure 54 With Figure 53 The overall roaming process is the same, but the link is first deleted and then a link with AP MLD 2 is added.

[0503] Based on adding and deleting links, two requests can be initiated one by one in the MLD roaming request frame, or two operations can be requested simultaneously in one frame. This is based on simultaneous requests. Figure 53 In this case, the implementation method for simultaneously sending add and delete requests can be followed as described in section 3-1 of 2.4.1 MLD roaming request frame format—configuring the MLD roaming request frame based on the intention to first add a new link and delete a regular link, and based on... Figure 54In cases where both add and delete requests are sent simultaneously, the MLD roaming request frame can be configured according to the implementation method in 2.4.1 MLD roaming request frame format 3-2) – which involves first deleting a regular link and then adding a new link based on the intent. For example, the link information field can be configured with two per-STA profiles (one per-STA profile for adding and another per-STA profile for deleting). The configuration of the MLD roaming request frame that first sends the add / delete request based on separate add and delete requests can be configured as follows: 1) as included in the MLD roaming request frame body or the common information field of the reconfiguration IE in 2.4.1 MLD roaming request frame format; 2-1) as included in the link information field of the MLD roaming request frame body or the reconfiguration IE; or 2-2) as included in the link information field of the MLD roaming request frame body or the reconfiguration IE. Subsequently, the response to this request is received as an MLD roaming response frame, and the status code indicates whether the MLD roaming request frame is accepted or rejected.

[0504] Additionally, in order for STA 1 to be fully converted from AP 1 to AP 4, it is necessary to have, for example Figure 55 as well as Figure 56 The process.

[0505] Figure 55 An example of MLD roaming using TIM is shown.

[0506] AP 1 notifies STA 1 via TIM whether there is DL data to be sent to STA 1 via beacon. At this time, in order for STA 1 to add AP 4 for roaming, STA 1 sends an MLD roaming request. For reference, although this example only includes STA 1, link addition for AP 5 to STA 2 can also be done as follows. Figure 44 The request is made together as described above. AP 1 checks the request and responds with an acceptance for AP 4. However, STA 1 may have already received information from AP 1's most recent beacon that the DL data was not cached, or even if it was cached, it may not have received the information yet. Therefore, AP 1 can notify STA 1 that AP 4 or the UHRAP MLD has the corresponding DL data. For example, based on a switch to AP 4, STA 1 can receive the DL data by immediately sending a PS-polling message to AP 4 without waiting until a beacon is received. For this purpose, additional information needs to be indicated in the MLD roaming response frame, and the corresponding information is as follows.

[0507] -> Service Indication Mapping (TIM) field (e.g., 1 bit): This indicates that the corresponding AP or AP MLD is currently caching DL data for the requested STA.

[0508] From an MLD-level perspective, based on the UHR AP MLD notification, the DL data for the requested STA is being cached, and the TIM field can be included in the MLD roaming response frame body or the common information field.

[0509] From the perspective of the corresponding AP, for example, based on the notification that AP 4 had DL data before switching to AP 4, the TIM field can be included in the link information field.

[0510] Additionally, the STA (e.g., STA 1) can determine the handover time by utilizing the MLD roaming timer of the MLD roaming response frame. For example, based on the fact that there is a significant amount of time remaining before receiving data from the AP to which it will roam (e.g., AP 4) prior to the handover, STA 1 can first receive DL data by sending a PS-polling (if necessary) to the currently connected AP (e.g., AP 1) and then handover. Alternatively, based on the fact that this is the time it can receive data from AP 4 even if it handovers immediately, STA 1 can handover immediately.

[0511] Figure 56 This demonstrates the operation process of using TIM for MLD roaming.

[0512] refer to Figure 56 The AP's sending and receiving process is as follows.

[0513] AP 1 notifies STA 1 via TIM whether there is DL data to be sent via beacon. Based on the received roaming request, AP 1 responds with an acceptance for AP 4 (+AP 5). AP 1 notifies who has the DL data. The AP with the DL data or UHR AP MLD sends the DL data to STA 1 (+STA 2). Based on the received disconnect request from the STA, AP 1 (+AP 3) deletes the regular connection.

[0514] refer to Figure 56 The STA's sending and receiving process is as follows.

[0515] STA 1 sends an MLD roaming request to perform roaming and add AP 4. At this time, a link addition request for AP 5 for STA 2 can also be requested simultaneously. STA 1 receives information about DL data. STA 1 (+STA 2) performs roaming to AP 4 (+AP 5). STA 1 (+STA 2) sends a PS-polling message to AP 4 (+AP 5) and receives DL data accordingly. STA 1 (+STA 2) requests link deletion from AP 1 (+AP 3).

[0516] Figure 57 This is a flowchart illustrating the operation of the transmitting device according to this embodiment.

[0517] Figure 57 Examples can be performed by the transmitting device (AP and / or non-AP STA).

[0518] Figure 57 Some steps in each of the examples (or detailed sub-steps described later) can be skipped / omitted.

[0519] Through step S5710, the transmitting device (transmitting STA) can obtain information about the aforementioned tone plan. As described above, the information about the tone plan includes the size and location of the RU, control information related to the RU, information about the frequency band including the RU, and information about the STA receiving the RU, etc.

[0520] In step S5720, the transmitting device can construct / generate a PPDU based on the acquired control information. Configuring / generating a PPDU may include configuring / generating each field of the PPDU. Specifically, step S5720 includes configuring an EHT-SIG field containing control information regarding tone planning. Specifically, step S5720 includes configuring a field containing control information (e.g., an N-bitmap) indicating the size / location of the RU; and / or configuring a field containing an identifier (e.g., an AID) of the STA receiving the RU.

[0521] Similarly, step S5720 may include generating an STF / LTF sequence to be transmitted via a specific RU. The STF / LTF sequence may be generated based on a preset STF generation sequence / LTF generation sequence.

[0522] Similarly, step S5720 may include generating a data field (i.e., MPDU) sent through a specific RU.

[0523] The transmitting device can send the PPDU constructed in step S5720 to the receiving device based on step S5730.

[0524] During step S5730, the transmitting device may perform at least one of the following operations: CSD, spatial mapping, IDFT / IFFT operation, and GI insertion.

[0525] The signals / fields / sequences constructed according to this specification can be used as follows: Figure 5 Send in the form of.

[0526] Figure 58 This is a flowchart illustrating the operation of the receiving device according to this embodiment.

[0527] The above PPDU can be based on Figure 58 Example reception.

[0528] Figure 58Examples can be performed by the receiving device / equipment (AP and / or non-AP STA).

[0529] Figure 58 Some steps in each of the examples (or detailed sub-steps described later) can be skipped / omitted.

[0530] The receiving device (receiving STA) can receive all or part of the PPDU through step S5810. The received signal can be in the form of... Figure 5 In the form of.

[0531] The sub-steps of step S5810 can be based on Figure 57 Step S5730 is determined. That is, in step S5810, the results of the CSD, spatial mapping, IDFT / IFFT operations, and GI insertion operations applied in step S5730 can be recovered.

[0532] In step S5820, the receiving device may perform decoding on all or part of the PPDU. Similarly, the receiving device may obtain control information related to the tone plan (i.e., RU) from the decoded PPDU.

[0533] More specifically, the receiving device can decode the L-SIG and EHT-SIG of the PPDU based on conventional STF / LTF and obtain the information included in the L-SIG and EHT SIG fields. The information about various tone schemes (i.e., RUs) described in this specification can be included in the EHT-SIG, and the receiving STA can obtain information about tone schemes (i.e., RUs) through the EHT-SIG.

[0534] In step S5830, the receiving device can decode the remaining portion of the PPDU based on the information about the tone plan (i.e., RU) obtained in step S5820. For example, the receiving STA can decode the STF / LTF field of the PPDU based on the information about the tone plan (i.e., RU). Additionally, the receiving STA can decode the data field of the PPDU based on the information about the tone plan (i.e., RU) and obtain the MPDU included in the data field.

[0535] Additionally, the receiving device can perform a processing operation to transmit the data decoded in step S5830 to a higher layer (e.g., the MAC layer). Additionally, subsequent operations can be performed in response to the generation of an indication signal from the higher layer to the PHY layer regarding the data being sent to the higher layer.

[0536] The following text will refer to Figures 1 to 58 The above-described implementation method is described.

[0537] Figure 59This is a flowchart illustrating the process by which an AP sends and receives request frames and response frames for MLD roaming according to this embodiment.

[0538] Figure 59 The example can be implemented in network environments that support next-generation wireless LAN systems (Ultra-High Reliability (UHR) wireless LAN systems or next-generation Wi-Fi). Next-generation wireless LAN systems are improved versions of the 802.11be system and meet backward compatibility requirements with the 802.11be system.

[0539] Figure 59 The example is performed by the sending station (STA), and the sending STA can correspond to an access point (AP). Figure 59 The receiving STA in the STA can correspond to at least one station (STA).

[0540] This embodiment proposes a method for a non-AP MLD to perform roaming from a serving AP MLD to a target AP MLD. Specifically, this embodiment proposes a roaming scheme that immediately switches to another link, rather than a roaming scheme that involves the non-AP MLD disconnecting its link from the serving AP MLD and adding a link connection to the target AP MLD. MLD roaming from the serving AP MLD to the target AP MLD is defined as the operation of seamlessly moving from one AP to another within the MLD without disconnecting between the AP and STA. In particular, this embodiment has the following advantages: by defining the operations and information required to simultaneously perform link connection to the target AP MLD and link deletion with the serving AP MLD based on roaming from a non-AP MLD to the target AP MLD, disconnection states are prevented, enabling seamless roaming without packet loss or latency.

[0541] In step S5910, the first access point (AP) receives a multi-link device (MLD) roaming request frame from the first non-AP station (STA).

[0542] In step S5920, the first AP sends an MLD roaming response frame to the first non-AP STA.

[0543] The first non-AP STA performs roaming from the first AP to the third AP based on the MLD roaming response frame.

[0544] The first AP operating on the first link and the second AP operating on the second link belong to the first AP MLD. The first non-AP STA operating on the first link and the second non-AP STA operating on the second link belong to the first non-AP MLD.

[0545] The third AP belongs to the second AP MLD. The first AP MLD and the second AP MLD are included in the roaming group.

[0546] Additionally, the second non-AP STA can perform roaming from the second AP to the fourth AP based on the MLD roaming response frame. The fourth AP can further belong to the second AP MLD.

[0547] The first and second APs can be referred to as the old AP (O_AP), the serving AP, or the current AP. The third and fourth APs can be referred to as the new AP (N_AP) or the target AP. The first AP MLD, which includes the first and second APs, can be referred to as the serving AP MLD. The second AP MLD, which includes the third and fourth APs, can be referred to as the target AP MLD.

[0548] A roaming group can be referred to as a UHR AP MLD. Although the first AP MLD and the second AP MLD are not co-located, they are included in the same roaming group, and therefore roaming (or moving) from an AP in the first AP MLD to an AP in the second AP MLD is possible. The first AP and the second AP in the first AP MLD are co-located. The third AP and the fourth AP in the second AP MLD are also co-located.

[0549] The MLD roaming request frame includes a type field. At this time, based on the type field, for the first link, the deletion of a connection to the first AP and the addition of a connection to the third AP are performed simultaneously. Additionally, based on the type field, for the second link, the deletion of a connection to the second AP and the addition of a connection to the fourth AP can be performed simultaneously.

[0550] For example, this embodiment proposes a method that performs seamless MLD roaming by defining a type field with added link switching functionality for simultaneously performing link addition and deletion operations for MLD roaming. Based on this type field (using a single signaling), it enables seamless MLD roaming by switching links from one AP to another. Therefore, it achieves the following effect: it solves the problems of disconnection between AP and STA, resulting in packet loss and latency, present in conventional Fast BSS Switching (FT) schemes, while allowing uninterrupted movement to another AP.

[0551] MLD roaming request frames can be defined based on the reconfigured multilink information element (IE). An MLD roaming request frame may include a first common information field and a first link information field.

[0552] The first public information field may include the identifier of the second AP MLD and the identifier of the group that can roam. The first link information field may include the link identifiers of the first AP to the fourth AP, the identifier of the second AP MLD, and the identifier of the group that can roam.

[0553] Type fields can be defined as follows.

[0554] Based on the type field being set to 0, it can be configured to add a link. Based on the type field being set to 1, it can be configured to delete a link. Based on the type field being set to 2, it can be configured to temporarily add a link. Based on the type field being set to 3, it can be configured to temporarily delete a link. Based on the type field being set to 4, it can be configured to add a link and then delete it (however, in this case, information about the link to be added is indicated). Based on the type field being set to 5, it can be configured to add a link and then delete it (however, in this case, information about the link to be deleted is indicated). Based on the type field being set to 6, it can be configured to delete a link and then add it (however, in this case, information about the link to be added is indicated). Based on the type field being set to 7, it can be configured to delete a link and then add it (however, in this case, information about the link to be deleted is indicated). Based on the type field being set to 8, it can be configured to perform both link deletion and link switching operations simultaneously.

[0555] Additionally, the type field can be set differently depending on whether it is included in the first public information field or the first link information field.

[0556] For example, the first public information field may further include a type field and an AP removal timer field.

[0557] Based on the type field being set to the first value, for the first link, the deletion of the connection to the first AP and the addition of the connection to the third AP can be performed simultaneously, and for the second link, the deletion of the connection to the second AP and the addition of the connection to the fourth AP can be performed simultaneously.

[0558] The AP removal timer field may include information about the number of Target Beacon Transmission Time (TBTT) received from the first AP before roaming to the third AP and information about the number of TBTT received from the second AP before roaming to the fourth AP.

[0559] Based on the AP removal timer field, the roaming timing from the first AP to the third AP and from the second AP to the fourth AP can be obtained. APs participating in MLD roaming and non-AP STAs should know when to perform link switching, and APs or non-AP STAs can check the number of TBTTs of the corresponding AP until the connection of a specific AP is deleted through the AP removal timer field to obtain the timing of the link switching.

[0560] MLD roaming response frames can be defined based on the Basic Multilink IE. MLD roaming response frames may include a second common information field and a second link information field.

[0561] The identifier of the second AP MLD and the identifier of the roaming group can be included in the second common information field. The link identifiers of the third and fourth APs, the identifier of the second AP MLD, and the identifier of the roaming group can be included in the second link information field.

[0562] Since the type field is set to the first value, the second common information field of the MLD roaming response frame may further include a channel handover count field.

[0563] The channel handover count field may include information about the number of TBTTs received from the first AP before roaming to the third AP and information about the number of TBTTs received from the second AP before roaming to the fourth AP.

[0564] Based on the channel handover count field, the timing of roaming from the first AP to the third AP and from the second AP to the fourth AP can be obtained. Similarly, APs participating in MLD roaming and non-AP STAs should know when to perform link handover, and APs or non-AP STAs can check the number of TBTTs of the corresponding AP until the connection of a specific AP is deleted through the channel handover count field to obtain the timing of the link handover.

[0565] For example, when an AP participating in MLD roaming notifies a non-AP STA, the timing of the link handover can be indicated by adding a channel handover count field to the MLD roaming response frame. Additionally, when a non-AP STA participating in MLD roaming notifies an AP, the timing of the link handover can be indicated by adding an AP removal timer field to the MLD roaming request frame.

[0566] The first public information field may further include an AP removal timer existence field. The second public information field may further include a channel handover count existence field.

[0567] The AP removal timer presence field can include information about whether the AP removal timer field exists. The channel handover count presence field can include information about whether the channel handover count field exists.

[0568] Additionally, an AP removal timer field is included in the first link information field. This AP removal timer field can indicate the timing of roaming from a first AP to a third AP for a first link, and the timing of roaming from a second AP to a fourth AP for a second link. For example, including the AP removal timer field in the first link information field can indicate the timing of performing channel handover individually for each link.

[0569] The channel handover count field is included in the second link information field. This channel handover count field can indicate the timing of roaming from a first AP to a third AP for a first link, and the timing of roaming from a second AP to a fourth AP for a second link. For example, including the channel handover count field in the second link information field can indicate the timing of performing channel handovers individually for each link.

[0570] The first public information field may further include MLD capabilities and operations subfields for performing MLD roaming, as well as EML capabilities subfields.

[0571] The MLD roaming request frame further includes a first existence bitmap subfield, which may include a subfield indicating whether the identifier for the second AP MLD exists or does not exist, a subfield indicating whether the identifier for the roaming group exists or does not exist, a subfield indicating whether the MLD capability and operation subfield exists or does not exist, and a subfield indicating whether the EML capability subfield exists or does not exist.

[0572] Based on the values ​​of the subfields in the first existence bitmap subfield, the identifier of the second AP MLD, the identifier of the roaming group, the MLD capability and operation subfield, and the EML capability subfield may or may not be included in the first public information field.

[0573] The first link information may further include the link ID subfield in the STA control field. The link identifiers of the third and fourth APs may be included in the link ID subfield.

[0574] The MLD roaming response frame further includes a second presence bitmap subfield, which may include a subfield indicating the presence or absence of an identifier for the second AP MLD and a subfield indicating the presence or absence of an identifier for the roaming group.

[0575] Based on the values ​​of the subfields in the second existence bitmap subfield, the identifier of the second AP MLD and the identifier of the roaming group may or may not be included in the first public information field.

[0576] The second link information may further include the link ID subfield from the STA control field. The link identifiers of the third and fourth APs may be included in the link ID subfield.

[0577] The first non-AP STA and the second non-AP STA can set the MLD roaming timer.

[0578] Based on the expiration of the MLD roaming timer, the first non-AP STA can completely delete its connection to the first AP on the first link and completely connect to the third AP. The second non-AP STA can completely delete its connection to the second AP on the second link and completely connect to the fourth AP.

[0579] Information regarding the MLD roaming timer can be further included in the first public information field or the first link information field. Information regarding the MLD roaming timer can also be further included in the second public information field or the second link information field.

[0580] Additionally, the first non-AP STA can receive beacon frames from the first AP. Beacon frames can be broadcast.

[0581] Beacon frames can include information about the third and fourth APs.

[0582] Information about the third and fourth APs may include a first indicator bit, a second indicator bit, and an identifier of the group that can roam.

[0583] The first indicator bit may include information about whether the third and fourth APs are capable of roaming. The second indicator bit may include information about whether the third and fourth APs can temporarily add or remove links.

[0584] Based on the fact that the identifier of the group that can roam has a value of 0, the third AP and the fourth AP can be identified as APs belonging to the same group as the group that can roam.

[0585] Additionally, the first non-AP STA can identify the third and fourth APs as the APs to roam to based on beacon frames.

[0586] Beacon frames can be defined based on the Simplified Neighbor Report (RNR) IE.

[0587] The RNR IE may include the MLD roaming parameter subfield. The MLD roaming parameter subfield may include a first indicator bit, a second indicator bit, and an identifier of the group that can be roamed.

[0588] The beacon frame may further include a Traffic Indication Map (TIM) field. The TIM field may include information about whether downlink (DL) data is to be sent to the first non-AP STA.

[0589] For example, setting the TIM field to 1 allows DL data to be cached before being sent to the first non-AP STA. Setting the TIM field to 0 allows DL data to be uncached before being sent to the first non-AP STA. The TIM field can be included in the MLD roaming response frame.

[0590] After roaming from the first AP to the third AP is complete, the first non-AP STA can receive DL data from the third AP. The first non-AP STA can also delete the first link connection with the first AP.

[0591] Figure 60 This is a flowchart illustrating the process by which a STA sends and receives request frames and response frames for MLD roaming according to this embodiment.

[0592] Figure 60 The example can be implemented in network environments that support next-generation wireless LAN systems (Ultra-High Reliability (UHR) wireless LAN systems or next-generation Wi-Fi). Next-generation wireless LAN systems are improved versions of the 802.11be system and meet backward compatibility requirements with the 802.11be system.

[0593] Figure 60 The example is performed by the receiving station (STA), and the receiving STA can correspond to at least one STA. Figure 60 The sending STA in the diagram can correspond to an access point (AP).

[0594] This embodiment proposes a method for a non-AP MLD to roam from a serving AP MLD to a target AP MLD. Specifically, this embodiment proposes a roaming scheme that immediately switches to another link, rather than a roaming scheme that involves the non-AP MLD disconnecting its link from the serving AP MLD and adding a link connection to the target AP MLD. MLD roaming from the serving AP MLD to the target AP MLD is defined as an operation in the MLD that seamlessly moves from one AP to another without disconnecting between the AP and STA. In particular, this embodiment has the following advantages: by defining the operations and information required to simultaneously perform link connection to the target AP MLD and link deletion with the serving AP MLD based on roaming from a non-AP MLD to the target AP MLD, disconnection states are prevented, enabling seamless roaming without packet loss or latency.

[0595] In step S6010, the first non-access point station (non-AP STA) sends a multi-link device (MLD) roaming request frame to the first AP.

[0596] In step S6020, the first non-AP STA receives an MLD roaming response frame from the first AP.

[0597] In step S6030, the first non-AP STA performs roaming from the first AP to the third AP based on the MLD roaming response frame.

[0598] The first AP operating on the first link and the second AP operating on the second link belong to the first AP MLD. The first non-AP STA operating on the first link and the second non-AP STA operating on the second link belong to the first non-AP MLD.

[0599] The third AP belongs to the second AP MLD. The first AP MLD and the second AP MLD are included in the roaming group.

[0600] Additionally, the second non-AP STA can perform roaming from the second AP to the fourth AP based on the MLD roaming response frame. The fourth AP can further belong to the second AP MLD.

[0601] The first and second APs can be referred to as the old AP (O_AP), the serving AP, or the current AP. The third and fourth APs can be referred to as the new AP (N_AP) or the target AP. The first AP MLD, which includes the first and second APs, can be referred to as the serving AP MLD. The second AP MLD, which includes the third and fourth APs, can be referred to as the target AP MLD.

[0602] A roaming group can be referred to as a UHR AP MLD. Although the first AP MLD and the second AP MLD are not co-located, they are included in the same roaming group, and therefore roaming (or moving) from an AP in the first AP MLD to an AP in the second AP MLD is possible. The first AP and the second AP in the first AP MLD are co-located. The third AP and the fourth AP in the second AP MLD are also co-located.

[0603] The MLD roaming request frame includes a type field. At this time, based on the type field, for the first link, the deletion of a connection to the first AP and the addition of a connection to the third AP are performed simultaneously. Additionally, based on the type field, for the second link, the deletion of a connection to the second AP and the addition of a connection to the fourth AP can be performed simultaneously.

[0604] For example, this embodiment proposes a method that performs seamless MLD roaming by defining a type field with added link switching functionality for simultaneously performing link addition and deletion operations for MLD roaming. Based on this type field (using a single signaling), it enables seamless MLD roaming by switching links from one AP to another. Therefore, it achieves the following effect: it solves the problems of disconnection between AP and STA, resulting in packet loss and latency, present in conventional Fast BSS Switching (FT) schemes, while allowing uninterrupted movement to another AP.

[0605] MLD roaming request frames can be defined based on the reconfigured multilink information element (IE). An MLD roaming request frame may include a first common information field and a first link information field.

[0606] The first public information field may include the identifier of the second AP MLD and the identifier of the roaming group. The first link information field may include the link IDs of the first AP to the fourth AP, the identifier of the second AP MLD, and the identifier of the roaming group.

[0607] Type fields can be defined as follows.

[0608] Based on the type field being set to 0, it can be configured to add a link. Based on the type field being set to 1, it can be configured to delete a link. Based on the type field being set to 2, it can be configured to temporarily add a link. Based on the type field being set to 3, it can be configured to temporarily delete a link. Based on the type field being set to 4, it can be configured to add a link and then delete it (however, in this case, information about the link to be added is indicated). Based on the type field being set to 5, it can be configured to add a link and then delete it (however, in this case, information about the link to be deleted is indicated). Based on the type field being set to 6, it can be configured to delete a link and then add it (however, in this case, information about the link to be added is indicated). Based on the type field being set to 7, it can be configured to delete a link and then add it (however, in this case, information about the link to be deleted is indicated). Based on the type field being set to 8, it can be configured to perform both link deletion and link switching operations simultaneously.

[0609] Additionally, the type field can be set differently depending on whether it is included in the first public information field or the first link information field.

[0610] For example, the first public information field may further include a type field and an AP removal timer field.

[0611] Based on the type field being set to the first value, for the first link, the deletion of the connection to the first AP and the addition of the connection to the third AP can be performed simultaneously, and for the second link, the deletion of the connection to the second AP and the addition of the connection to the fourth AP can be performed simultaneously.

[0612] The AP removal timer field may include information about the number of Target Beacon Transmission Time (TBTT) received from the first AP before roaming to the third AP and information about the number of TBTT received from the second AP before roaming to the fourth AP.

[0613] Based on the AP removal timer field, the roaming timing from the first AP to the third AP and from the second AP to the fourth AP can be obtained. APs participating in MLD roaming and non-AP STAs should know when to perform link switching, and APs or non-AP STAs can check the number of TBTTs of the corresponding AP until the connection of a specific AP is deleted through the AP removal timer field to obtain the timing of the link switching.

[0614] MLD roaming response frames can be defined based on the Basic Multilink IE. MLD roaming response frames may include a second common information field and a second link information field.

[0615] The identifier of the second AP MLD and the identifier of the roaming group can be included in the second common information field. The link identifiers of the third and fourth APs, the identifier of the second AP MLD, and the identifier of the roaming group can be included in the second link information field.

[0616] Since the type field is set to the first value, the second common information field of the MLD roaming response frame may further include a channel handover count field.

[0617] The channel handover count field may include information about the number of TBTTs received from the first AP before roaming to the third AP and information about the number of TBTTs received from the second AP before roaming to the fourth AP.

[0618] Based on the channel handover count field, the timing of roaming from the first AP to the third AP and from the second AP to the fourth AP can be obtained. Similarly, APs participating in MLD roaming and non-AP STAs should know when to perform link handover, and APs or non-AP STAs can check the number of TBTTs of the corresponding AP until the connection of a specific AP is deleted through the channel handover count field to obtain the timing of the link handover.

[0619] For example, when an AP participating in MLD roaming notifies a non-AP STA, the timing of the link handover can be indicated by adding a channel handover count field to the MLD roaming response frame. Additionally, when a non-AP STA participating in MLD roaming notifies an AP, the timing of the link handover can be indicated by adding an AP removal timer field to the MLD roaming request frame.

[0620] The first public information field may further include an AP removal timer existence field. The second public information field may further include a channel handover count existence field.

[0621] The AP removal timer presence field can include information about whether the AP removal timer field exists. The channel handover count presence field can include information about whether the channel handover count field exists.

[0622] Additionally, an AP removal timer field is included in the first link information field. This AP removal timer field can indicate the timing of roaming from a first AP to a third AP for a first link, and the timing of roaming from a second AP to a fourth AP for a second link. For example, including the AP removal timer field in the first link information field can indicate the timing of performing channel handover individually for each link.

[0623] The channel handover count field is included in the second link information field. This channel handover count field can indicate the timing of roaming from a first AP to a third AP for a first link, and the timing of roaming from a second AP to a fourth AP for a second link. For example, including the channel handover count field in the second link information field can indicate the timing of performing channel handovers individually for each link.

[0624] The first public information field may further include MLD capabilities and operations subfields for performing MLD roaming, as well as EML capabilities subfields.

[0625] The MLD roaming request frame further includes a first existence bitmap subfield, which may include a subfield indicating whether the identifier for the second AP MLD exists or does not exist, a subfield indicating whether the identifier for the roaming group exists or does not exist, a subfield indicating whether the MLD capability and operation subfield exists or does not exist, and a subfield indicating whether the EML capability subfield exists or does not exist.

[0626] Based on the values ​​of the subfields in the first existence bitmap subfield, the identifier of the second AP MLD, the identifier of the roaming group, the MLD capability and operation subfield, and the EML capability subfield may or may not be included in the first public information field.

[0627] The first link information may further include the link ID subfield in the STA control field. The link identifiers of the third and fourth APs may be included in the link ID subfield.

[0628] The MLD roaming response frame further includes a second presence bitmap subfield, which may include a subfield indicating the presence or absence of an identifier for the second AP MLD and a subfield indicating the presence or absence of an identifier for the roaming group.

[0629] Based on the values ​​of the subfields in the second existence bitmap subfield, the identifier of the second AP MLD and the identifier of the roaming group may or may not be included in the first public information field.

[0630] The second link information may further include the link ID subfield from the STA control field. The link identifiers of the third and fourth APs may be included in the link ID subfield.

[0631] The first non-AP STA and the second non-AP STA can set the MLD roaming timer.

[0632] Based on the expiration of the MLD roaming timer, the first non-AP STA can completely delete its connection to the first AP on the first link and completely connect to the third AP. The second non-AP STA can completely delete its connection to the second AP on the second link and completely connect to the fourth AP.

[0633] Information regarding the MLD roaming timer can be further included in the first public information field or the first link information field. Information regarding the MLD roaming timer can also be further included in the second public information field or the second link information field.

[0634] Additionally, the first non-AP STA can receive beacon frames from the first AP. Beacon frames can be broadcast.

[0635] Beacon frames can include information about the third and fourth APs.

[0636] Information about the third and fourth APs may include a first indicator bit, a second indicator bit, and an identifier of the group that can roam.

[0637] The first indicator bit may include information about whether the third and fourth APs are capable of roaming. The second indicator bit may include information about whether the third and fourth APs can temporarily add or remove links.

[0638] Based on the fact that the identifier of the group that can roam has a value of 0, the third AP and the fourth AP can be identified as APs belonging to the same group as the group that can roam.

[0639] Additionally, the first non-AP STA can identify the third and fourth APs as the APs to roam to based on beacon frames.

[0640] Beacon frames can be defined based on the Simplified Neighbor Report (RNR) IE.

[0641] The RNR IE may include the MLD roaming parameter subfield. The MLD roaming parameter subfield may include a first indicator bit, a second indicator bit, and an identifier of the group that can be roamed.

[0642] The beacon frame may further include a Traffic Indication Map (TIM) field. The TIM field may include information about whether downlink (DL) data is to be sent to the first non-AP STA.

[0643] For example, setting the TIM field to 1 allows DL data to be cached before being sent to the first non-AP STA. Setting the TIM field to 0 allows DL data to be excluded from caching before being sent to the first non-AP STA. The TIM field can be included in the MLD roaming response frame.

[0644] After roaming from the first AP to the third AP is complete, the first non-AP STA can receive DL data from the third AP. The first non-AP STA can also delete the first link connection with the first AP.

[0645] <Device Configuration>

[0646] The technical features described above in this disclosure can be applied to various apparatuses and methods. For example, the technical features described above in this disclosure can be used by... Figure 1 and / or Figure 14 The device is used to perform / support this. For example, the technical features described above in this disclosure can be applied only to... Figure 1 and / or Figure 14 Part of it. For example, the technical features described above in this disclosure can be based on Figure 1 The processing chips 114 and 124 are implemented based on Figure 1 Implemented by processors 111 and 121 and memories 112 and 122, or based on Figure 14 The processor 610 and memory 620 are implemented. For example, one apparatus of this disclosure sends a multi-link device (MLD) roaming request frame to a first access point (AP); receives an MLD roaming response frame from the first AP; and performs roaming from the first AP to a third AP based on the MLD roaming response frame.

[0647] The technical features of this disclosure can be implemented based on a computer-readable medium (CRM). For example, one CRM proposed in this disclosure is at least one computer-readable medium including instructions that are executed by at least one processor.

[0648] The CRM can store instructions for performing operations including: sending an MLD roaming request frame to a first access point (AP); receiving an MLD roaming response frame from the first AP; and performing roaming from the first AP to a third AP based on the MLD roaming response frame. The instructions stored in the CRM of this disclosure can be executed by at least one processor. The at least one processor associated with the CRM of this disclosure may be... Figure 1 Processors 111 and 121 or processing chips 114 and 124, or Figure 14 The processor 610. Meanwhile, the CRM disclosed herein can be... Figure 1 Memory 112 and 122, Figure 14 The memory 620, or a separate external memory / storage medium / disk, etc.

[0649] The technical features described above are applicable to various applications or business models. For example, these technical features can be applied to wireless communication in devices that support artificial intelligence (AI).

[0650] Artificial intelligence (AI) refers to the field of researching or creating methodologies for artificial intelligence, while machine learning refers to the field of researching methodologies for defining and solving various problems within the field of AI. Machine learning is also defined as algorithms that improve the performance of operations through continuous experience.

[0651] Artificial neural networks (ANNs) are models used in machine learning. They can refer to an overall problem-solving model comprising artificial neurons (nodes) that form a network through synaptic connections. An ANN can be defined by the connection patterns between neurons in different layers, the learning process that updates model parameters, and the activation functions that generate output values.

[0652] An artificial neural network may include an input layer, an output layer, and optionally one or more hidden layers. Each layer includes one or more neurons, and the artificial neural network may include synapses connecting the neurons. In an artificial neural network, each neuron may output a function value of an activation function in response to an input signal, weights, and biases received through the synapse.

[0653] Model parameters are parameters determined through learning, including synaptic connection weights and neuron biases. Hyperparameters are parameters that need to be set before learning in a machine learning algorithm, including the learning rate, number of iterations, mini-batch size, and initialization function.

[0654] Learning artificial neural networks can aim to determine model parameters used to minimize a loss function. The loss function can be used as a metric for determining optimal model parameters during the learning process of an artificial neural network.

[0655] Machine learning can be divided into supervised learning, unsupervised learning, and reinforcement learning.

[0656] Supervised learning refers to the method of training an artificial neural network using labels provided for the training data. These labels indicate the correct answer (or result value) the artificial neural network should infer when the training data is input. Unsupervised learning refers to the method of training an artificial neural network without providing labels for the training data. Reinforcement learning can be a training method used to train an agent defined in an environment to select actions or sequences of actions that maximize cumulative reward in each state.

[0657] Machine learning implemented using deep neural networks (DNNs) with multiple hidden layers in artificial neural networks is called deep learning, and deep learning is a part of machine learning. In the following text, machine learning will be interpreted as including deep learning.

[0658] The aforementioned technical features can be applied to wireless communication for robots.

[0659] A robot can be defined as a machine that automatically processes or operates a given task using its own capabilities. In particular, a robot that has the ability to recognize its environment and make autonomous judgments to perform operations can be called an intelligent robot.

[0660] Depending on their application or field, robots can be categorized into industrial, medical, household, and military robots, among others. Robots can include actuators or drives that include motors to perform various physical operations, such as moving robot joints. Additionally, mobile robots can include wheels, brakes, propellers, etc., in their drives to move on the ground or fly in the air.

[0661] The aforementioned technical features can be applied to devices that support extended reality.

[0662] Extended reality is collectively referred to as virtual reality (VR), augmented reality (AR), and mixed reality (MR). VR technology is a computer graphics technology that provides real-world objects and backgrounds only in CG images; AR technology is a computer graphics technology that provides virtual CG images on top of real object images; and MR technology is a computer graphics technology that provides virtual objects that are mixed and combined with the real world.

[0663] MR technology is similar to AR technology in that it can display real and virtual objects together. However, in AR technology, virtual objects are used as a supplement to real objects, while in MR technology, virtual and real objects are used as equals.

[0664] XR technology can be applied to head-mounted displays (HMDs), head-up displays (HUDs), mobile phones, tablets, laptops, desktop computers, televisions, digital signage, and more. Devices that utilize XR technology can be referred to as XR devices.

[0665] The claims disclosed in this specification can be combined in various ways. For example, the technical features in the method claims of this specification can be combined to implement as an apparatus, and the technical features in the apparatus claims of this specification can be combined to implement by a method. Furthermore, the technical features in the method claims and apparatus claims of this specification can be combined to implement as an apparatus, and the technical features in the method claims and apparatus claims of this specification can be combined to implement by a method.

Claims

1. A method in a wireless local area network (WLAN) system, the method comprising: A multi-link device (MLD) roaming request frame is sent from the first non-access point station (non-AP STA) to the first AP. The first non-AP STA receives an MLD roaming response frame from the first AP; as well as The first non-AP STA performs roaming from the first AP to the third AP based on the MLD roaming response frame. Among them, the first AP operating on the first link and the second AP operating on the second link belong to the first APMLD. Among them, the first non-AP STA operating on the first link and the second non-AP STA operating on the second link belong to the first non-AP MLD. The third AP is subordinate to the second AP MLD. The first AP MLD and the second AP MLD are included in the group that can roam. The MLD roaming request frame includes a type field, and Specifically, based on the type field, for the first link, the deletion of the connection to the first AP and the addition of the connection to the third AP are performed simultaneously.

2. The method according to claim 1, further comprising: The second non-AP STA performs roaming from the second AP to the fourth AP based on the MLD roaming response frame. The fourth AP also belongs to the second AP MLD, and Specifically, based on the type field, for the second link, the deletion of the connection to the second AP and the addition of the connection to the fourth AP are performed simultaneously.

3. The method according to claim 2, wherein, The MLD roaming request frame is defined based on the reconfigured multi-link information element (IE). The MLD roaming request frame includes a first public information field and a first link information field. The first public information field includes the identifier of the second AP MLD and the identifier of the roaming group, and The first link information field includes the link identifier from the first AP to the fourth AP, the identifier of the second AP MLD, and the identifier of the roaming group.

4. The method according to claim 3, wherein, The first public information field also includes the type field and the AP removal timer field. Specifically, based on the type field being set to a first value, the deletion of the connection for the first AP and the addition of the connection for the third AP are performed simultaneously for the first link, and the deletion of the connection for the second AP and the addition of the connection for the fourth AP are performed simultaneously for the second link. The AP removal timer field includes information about the number of Target Beacon Transmission Time (TBTT) received from the first AP before roaming to the third AP and information about the number of TBTT received from the second AP before roaming to the fourth AP. Specifically, the roaming timing from the first AP to the third AP and the roaming timing from the second AP to the fourth AP are obtained based on the AP removal timer field.

5. The method according to claim 4, wherein, The MLD roaming response frame is defined based on the Basic Multilink IE. The MLD roaming response frame includes a second common information field and a second link information field. The identifier of the second AP MLD and the identifier of the roaming group are included in the second public information field, and The link identifiers of the third AP and the fourth AP, the identifier of the second AP MLD, and the identifier of the roaming group are included in the second link information field.

6. The method according to claim 5, wherein, Since the type field is set to a first value, the second common information field of the MLD roaming response frame also includes a channel handover count field. The channel handover count field includes information about the number of TBTTs received from the first AP before roaming to the third AP and information about the number of TBTTs received from the second AP before roaming to the fourth AP. The timing of the roaming from the first AP to the third AP and the timing of the roaming from the second AP to the fourth AP are obtained based on the channel switching count field.

7. The method according to claim 6, wherein, The first public information field also includes an AP removal timer existence field. The second public information field also includes a channel handover count existence field. The AP removal timer existence field includes information about whether the AP removal timer field exists, and The channel handover count existence field includes information about whether the channel handover count field exists.

8. The method according to claim 7, wherein, The AP removal timer field is included in the first link information field, the AP removal timer field indicating the timing of roaming from the first AP to the third AP for the first link, and indicating the timing of roaming from the second AP to the fourth AP for the second link. The channel handover count field is included in the second link information field, and the channel handover count field indicates the timing of the roaming from the first AP to the third AP for the first link, and indicates the timing of the roaming from the second AP to the fourth AP for the second link.

9. A first non-access point station (non-AP STA) in a wireless local area network (WLAN) system, the first non-AP STA comprising: Memory; transceiver; as well as A processor, operatively connected to the memory and the transceiver, The processor is configured as follows: Send a Multilink Device (MLD) roaming request frame to the first AP; Receive an MLD roaming response frame from the first AP; and Roaming from the first AP to the third AP is performed based on the MLD roaming response frame. Among them, the first AP operating on the first link and the second AP operating on the second link belong to the first APMLD. Among them, the first non-AP STA operating on the first link and the second non-AP STA operating on the second link belong to the first non-AP MLD. The third AP is subordinate to the second AP MLD. The first AP MLD and the second AP MLD are included in the group that can roam. The MLD roaming request frame includes a type field, and Specifically, based on the type field, for the first link, the deletion of the connection to the first AP and the addition of the connection to the third AP are performed simultaneously.

10. A method in a wireless local area network (WLAN) system, the method comprising: The first access point (AP) receives a multi-link device (MLD) roaming request frame from the first non-AP station (STA); as well as The first AP sends an MLD roaming response frame to the first non-AP STA. Specifically, the first non-AP STA performs roaming from the first AP to the third AP based on the MLD roaming response frame. Among them, the first AP operating on the first link and the second AP operating on the second link belong to the first APMLD. Among them, the first non-AP STA operating on the first link and the second non-AP STA operating on the second link belong to the first non-AP MLD. The third AP is subordinate to the second AP MLD. The first AP MLD and the second AP MLD are included in the group that can roam. The MLD roaming request frame includes a type field, and Specifically, based on the type field, for the first link, the deletion of the connection to the first AP and the addition of the connection to the third AP are performed simultaneously.

11. The method according to claim 10, wherein, Roaming from the second AP to the fourth AP is performed based on the MLD roaming response frame. The fourth AP also belongs to the second AP MLD, and Specifically, based on the type field, for the second link, the deletion of the connection to the second AP and the addition of the connection to the fourth AP are performed simultaneously.

12. The method according to claim 11, wherein, The MLD roaming request frame is defined based on the reconfigured multi-link information element (IE). The MLD roaming request frame includes a first public information field and a first link information field. The first public information field includes the identifier of the second AP MLD and the identifier of the roaming group, and The first link information field includes the link identifier from the first AP to the fourth AP, the identifier of the second AP MLD, and the identifier of the roaming group.

13. The method according to claim 12, wherein, The first public information field also includes the type field and the AP removal timer field. Specifically, based on the type field being set to a first value, the deletion of the connection for the first AP and the addition of the connection for the third AP are performed simultaneously for the first link, and the deletion of the connection for the second AP and the addition of the connection for the fourth AP are performed simultaneously for the second link. The AP removal timer field includes information about the number of Target Beacon Transmission Time (TBTT) received from the first AP before roaming to the third AP and information about the number of TBTT received from the second AP before roaming to the fourth AP. Specifically, the roaming timing from the first AP to the third AP and the roaming timing from the second AP to the fourth AP are obtained based on the AP removal timer field.

14. The method according to claim 13, wherein, The MLD roaming response frame is defined based on the Basic Multilink IE. The MLD roaming response frame includes a second common information field and a second link information field. The identifier of the second AP MLD and the identifier of the roaming group are included in the second public information field, and The link identifiers of the third AP and the fourth AP, the identifier of the second AP MLD, and the identifier of the roaming group are included in the second link information field.

15. The method according to claim 14, wherein, Since the type field is set to a first value, the second common information field of the MLD roaming response frame also includes a channel handover count field. The channel handover count field includes information about the number of TBTTs received from the first AP before roaming to the third AP and information about the number of TBTTs received from the second AP before roaming to the fourth AP. The timing of the roaming from the first AP to the third AP and the timing of the roaming from the second AP to the fourth AP are obtained based on the channel switching count field.

16. The method according to claim 15, wherein, The first public information field also includes an AP removal timer existence field. The second public information field also includes a channel handover count existence field. The AP removal timer existence field includes information about whether the AP removal timer field exists, and The channel handover count existence field includes information about whether the channel handover count field exists.

17. The method according to claim 16, wherein, The AP removal timer field is included in the first link information field, the AP removal timer field indicating the timing of roaming from the first AP to the third AP for the first link, and indicating the timing of roaming from the second AP to the fourth AP for the second link. The channel handover count field is included in the second link information field, and the channel handover count field indicates the timing of the roaming from the first AP to the third AP for the first link, and indicates the timing of the roaming from the second AP to the fourth AP for the second link.

18. A first access point (AP) in a wireless local area network (WLAN) system, the first AP comprising: Memory; transceiver; as well as A processor, operatively connected to the memory and the transceiver, The processor is configured as follows: Receives a multi-link device (MLD) roaming request frame from the first non-AP station (STA); and Send an MLD roaming response frame to the first non-AP STA. Specifically, the first non-AP STA performs roaming from the first AP to the third AP based on the MLD roaming response frame. Among them, the first AP operating on the first link and the second AP operating on the second link belong to the first APMLD. Among them, the first non-AP STA operating on the first link and the second non-AP STA operating on the second link belong to the first non-AP MLD. The third AP is subordinate to the second AP MLD. The first AP MLD and the second AP MLD are included in the group that can roam. The MLD roaming request frame includes a type field, and Specifically, based on the type field, for the first link, the deletion of the connection to the first AP and the addition of the connection to the third AP are performed simultaneously.

19. A computer-readable medium comprising instructions that are executed by at least one processor to perform a method comprising the following steps: Send a Multi-Link Device (MLD) roaming request frame to the first access point (AP); Receive an MLD roaming response frame from the first AP; and Roaming from the first AP to the third AP is performed based on the MLD roaming response frame. in, The first AP operating on the first link and the second AP operating on the second link belong to the first APMLD. Among them, the first non-AP station STA operating on the first link and the second non-AP STA operating on the second link belong to the first non-AP MLD. The third AP is subordinate to the second AP MLD. The first AP MLD and the second AP MLD are included in the group that can roam. The MLD roaming request frame includes a type field, and Specifically, based on the type field, for the first link, the deletion of the connection to the first AP and the addition of the connection to the third AP are performed simultaneously.

20. An apparatus in a wireless local area network (WLAN) system, the apparatus comprising: Memory; as well as A processor, operatively connected to the memory, The processor is configured as follows: Send a Multi-Link Device (MLD) roaming request frame to the first access point (AP); Receive an MLD roaming response frame from the first AP; and Roaming from the first AP to the third AP is performed based on the MLD roaming response frame. Among them, the first AP operating on the first link and the second AP operating on the second link belong to the first APMLD. Among them, the first non-AP station STA operating on the first link and the second non-AP STA operating on the second link belong to the first non-AP MLD. The third AP is subordinate to the second AP MLD. The first AP MLD and the second AP MLD are included in the group that can roam. The MLD roaming request frame includes a type field, and Specifically, based on the type field, for the first link, the deletion of the connection to the first AP and the addition of the connection to the third AP are performed simultaneously.

Images