Method and apparatus for performing mld roaming by transmitting context in wireless lan system

Abstract

A method and apparatus for performing MLD roaming by transferring a context in a wireless LAN system are proposed. 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 performs roaming from the first AP to a second AP based on the MLD roaming request frame and the MLD roaming response frame. The MLD roaming request frame includes information on a context transfer level. A context to be transferred from the first AP MLD to the second AP MLD is selected based on the information on the context transfer level.

Description

Technical Field

[0001] This specification relates to a scheme for performing MLD roaming in a wireless LAN system by transmitting context, and more specifically, to a method and apparatus for selecting the context to be transmitted from a serving AP MLD to a target AP MLD based on information about the context transmission level. Background Technology

[0002] Wireless local area networks (WLANs) have been improved in various ways. For example, the IEEE 802.11ax standard proposes improved communication environments using orthogonal frequency division multiple access (OFDMA) and downlink multiple user multiple input multiple output (DLMU MIMO) schemes.

[0003] This specification proposes technical features available in new communication standards. For example, the new communication standard could be the recently discussed Extremely High Throughput (EHT) specification. This EHT specification could utilize newly proposed increased bandwidth, improved PHY layer Protocol Data Unit (PPDU) structures, improved sequencing, Hybrid Automatic Repeat Request (HARQ) schemes, etc. 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, to properly utilize the increased number of spatial streams, it may be necessary to improve the signaling scheme within the WLAN system. Summary of the Invention

[0005] Technical issues

[0006] This specification provides a method and apparatus for performing MLD roaming in a wireless LAN system by transmitting context.

[0007] Technical solution

[0008] The examples in this specification present a method for performing MLD roaming by transmitting context.

[0009] This embodiment can be implemented in a network environment that supports next-generation wireless LAN systems (Ultra-High Reliability (UHR) wireless LAN systems or next-generation Wi-Fi). Next-generation wireless LAN systems are wireless LAN systems that improve upon the 802.11be system and meet backward compatibility requirements with the 802.11be system.

[0010] This embodiment proposes a method for selecting the context to be transmitted from the serving AP MLD to the target AP MLD based on information about the context transmission level during the exchange of roaming request frames and roaming response frames for MLD roaming. Specifically, this embodiment has the effect of preventing delays due to unnecessary context transmission by selectively transmitting context based on whether to perform renegotiation between the non-AP STA and the target AP MLD.

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

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

[0013] The first non-AP STA performs roaming from the first AP to the second AP based on the MLD roaming request frame and the MLD roaming response frame.

[0014] The first AP is attached to a first AP multi-link device (MLD), and the second AP is attached to a second AP MLD. The first AP MLD and the second AP MLD are included in a group that is capable of roaming.

[0015] The first AP can be referred to as the old AP (O_AP), the serving AP, or the current AP. The second AP can be referred to as the new AP (N_AP) or the target AP. The first AP MLD, which includes the first AP, can be referred to as the serving AP MLD. The second AP MLD, which includes the second AP, can be referred to as 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 without disconnection between the AP and the STA within the MLD.

[0016] A group that can roam 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 group that can roam, so roaming (or moving) from an AP in the first AP MLD to an AP in the second AP MLD is possible. APs in the first AP MLD are co-located. APs in the second AP MLD are also co-located.

[0017] MLD roaming request frames include information about the context delivery level.

[0018] The context for transmission from the first AP MLD to the second AP MLD is selected based on information about the context transmission level.

[0019] This embodiment proposes a method for selecting a context for proactively transmitting necessary information before a non-AP STA performs roaming to a target AP MLD. Specifically, this embodiment defines a context transmission level for the context and proposes a method for selecting the context required for roaming based on the context transmission level.

[0020] Beneficial effects

[0021] According to the embodiments presented in this specification, delays caused by unnecessary context transmission can be avoided, and only necessary information can be transmitted, resulting in the ability to implement more improved seamless roaming. Attached Figure Description

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

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

[0024] Figure 3 The diagram illustrates the general link establishment process.

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

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

[0027] Figure 6 This is a diagram illustrating the layout of resource units (RUs) used in a 20MHz PPDU.

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

[0029] Figure 8 This is a diagram illustrating the layout of resource units (RUs) used in an 80MHz PPDU.

[0030] Figure 9 This demonstrates the operations related to UL-MU.

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

[0032] Figure 11 The illustration shows an example of a channel used / supported / defined within the 5GHz band.

[0033] Figure 12The illustration shows an example of a channel used / supported / defined within the 6GHz band.

[0034] Figure 13 This shows an example of a MAC frame header.

[0035] Figure 14 The illustration shows an example of a modified transmitting and / or receiving device according to this specification.

[0036] Figure 15 The diagram illustrates the Over-The-Air (OTA) FT protocol in a robust and secure network (RSN).

[0037] Figure 16 The diagram illustrates the high-level architecture used for AP MLD.

[0038] Figure 17 The diagram illustrates an example of a high-level architecture used in UHR AP MLD.

[0039] Figure 18 The diagram illustrates another example of a high-level architecture used in UHR AP MLD.

[0040] Figure 19 The diagram illustrates another example of a high-level architecture used in UHR AP MLD.

[0041] Figure 20 The illustration is an example of a high-level architecture based on the case where only entities that are not based on MLD exist.

[0042] Figure 21 The illustration shows another example of a high-level architecture based on the case where only entities that are not based on MLD exist.

[0043] Figure 22 This diagram illustrates an example of a roaming architecture within an AP MLD region.

[0044] Figure 23 An example of an RNR IE is shown.

[0045] Figure 24 Another example of an RNR IE is shown.

[0046] Figure 25 This shows yet another example of an RNR IE.

[0047] Figure 26 The illustration shows an example of the AP roaming recommendation enable field and the roaming reason code field in the public information field.

[0048] Figure 27 The image shows an example of the AP roaming recommendation field in the link information field.

[0049] Figure 28The illustration shows an example of reconfiguring the common information field of a multi-link IE as proposed in this embodiment.

[0050] Figure 29 The illustration shows an example of reconfiguring the link information field of a multi-link IE as proposed in this embodiment.

[0051] Figure 30 The illustration shows an example of UHR AP MLD ID and AP MLD ID being included in the common information field of the reconfigured multi-link IE proposed in this embodiment.

[0052] Figure 31 The illustration shows an example of the AP MLD ID being included in the common information field of the reconfigured multi-link IE proposed in this embodiment.

[0053] Figure 32 The illustration shows an example of UHR AP MLD ID and AP MLD ID being included in the link information field of the reconfigured multi-link IE proposed in this embodiment.

[0054] Figure 33 The illustration shows an example of the AP MLD ID being included in the link information field of the reconfigured multi-link IE proposed in this embodiment.

[0055] Figure 34 The illustration shows another example where the UHR AP MLD ID and AP MLD ID are included in the link information field of the reconfigured multi-link IE proposed in this embodiment.

[0056] Figure 35 The illustration shows another example where the AP MLD ID is included in the link information field of the reconfigured multi-link IE presented in this embodiment.

[0057] Figure 36 The illustration shows an example of a temporary field included in the public information field of the reconfigured multi-link IE proposed in this embodiment.

[0058] Figure 37 The illustration shows an example of a temporary field included in the link information field of a reconfigured multi-link IE as presented in this embodiment.

[0059] Figure 38 The illustration shows another example of a temporary field being included in the link information field of a reconfigured multi-link IE as presented in this embodiment.

[0060] Figure 39 The illustration shows an example where the AP removal timer field is included in the common information field for reconfiguring multi-link IEs as presented in this embodiment.

[0061] Figure 40The illustration shows an example of the common information field of the basic multi-link IE proposed in this embodiment.

[0062] Figure 41 The illustration shows an example of the link information field of the basic multi-link IE proposed in this embodiment.

[0063] Figure 42 The diagram illustrates an example of a group key information field.

[0064] Figure 43 The diagram is used to check whether N_AP can perform the roaming process using the concurrency enable field.

[0065] Figure 44 The diagram is used to check whether N_AP can perform the roaming process using the concatenated ID.

[0066] Figure 45 The illustration shows the MLD roaming process based on the UHR AP MLD ID being included in the reconfiguration element.

[0067] Figure 46 The illustration shows the MLD roaming process based on the UHR AP MLD ID not being included in the reconfiguration element.

[0068] Figure 47 The illustration shows an example of a set of APs juxtaposed.

[0069] Figure 48 The illustration shows Example 1 used in the MLD roaming process.

[0070] Figure 49 The operation procedure for Example 1 of the MLD roaming process is shown.

[0071] Figure 50 The illustration shows Example 2 for the MLD roaming process.

[0072] Figure 51 Example 2 illustrates the operation process used for the MLD roaming process.

[0073] Figure 52 The illustration shows Example 3 for the MLD roaming process.

[0074] Figure 53 Example 3 illustrates the operation process used for the MLD roaming process.

[0075] Figure 54 The illustration shows Example 4 used in the MLD roaming process.

[0076] Figure 55 Examples 3 and 4 illustrate the operational procedures used for the MLD roaming process.

[0077] Figure 56The illustration shows Example 5 used in the MLD roaming process.

[0078] Figure 57 The illustration shows Example 6 used in the MLD roaming process.

[0079] Figure 58 An example of MLD roaming using TIM is shown.

[0080] Figure 59 The procedure for using TIM to perform MLD roaming is shown.

[0081] Figure 60 The diagram illustrates the basic process of the roaming process.

[0082] Figure 61 An example of the baseline for the roaming process is shown.

[0083] Figure 62 Another example of the baseline for the roaming process is shown.

[0084] Figure 63 Another example of the baseline for the roaming process is shown.

[0085] Figure 64 Another example of the baseline for the roaming process is shown.

[0086] Figure 65 The illustration shows an example of the baseline of the roaming process, including the roaming preparation and execution phases, during the MLD roaming request / response process.

[0087] Figure 66 The illustration shows an example of the baseline of the roaming process, including the roaming preparation and execution phases.

[0088] Figure 67 The illustration shows another example of the baseline of the roaming process, including the roaming preparation and execution phases.

[0089] Figure 68 The illustration shows another example of the baseline of the roaming process, including the roaming preparation and execution phases.

[0090] Figure 69 The illustration shows another example of the baseline of the roaming process, including the roaming preparation and execution phases.

[0091] Figure 70 The illustration shows an example of a roaming process using context delivery (only the entity exists).

[0092] Figure 71 This diagram illustrates an example of a roaming process using context-based delivery.

[0093] Figure 72 This illustration shows another example of a roaming process using context delivery.

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

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

[0096] Figure 75 This is a flowchart illustrating the process of an AP performing an MLD roaming using context transmission according to this embodiment.

[0097] Figure 76 This is a flowchart illustrating the process of STA performing MLD roaming using context transfer according to this embodiment. Detailed Implementation

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

[0099] As used in this disclosure, a forward slash ( / ) or a comma can mean "and / or". For example, "A / B" can mean "A and / or B". Thus, "A / B" can mean "A only", "B only", or "both A and B". For example, "A, B, C" can mean "A, B, or C".

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

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

[0102] Furthermore, as used in this disclosure, “a (a)” or “an (an)” can mean “at least one” or “one or more”. Additionally, terms ending with “(s)” can mean “at least one” or “one or more”.

[0103] Furthermore, as used in this disclosure, the terms “based on”, “on the basis of”, or “according to” may mean “at least partially based on” and not “based on only”.

[0104] A technical feature described individually in one of the accompanying drawings of this disclosure may be implemented individually or simultaneously.

[0105] 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.11a / g / n / ac / ax / be / bn standards. Additionally, the examples of this disclosure can also be applied to enhanced Ultra-High Reliability (UHR) standards or next-generation wireless LAN standards such as IEEE 802.11bn. Furthermore, the examples of this disclosure can also be applied to new WLAN standards enhanced from EHT standards or IEEE 802.11be standards. Additionally, the examples of this disclosure can be applied to mobile communication systems. For example, depending on the 3GPP standards and the evolution of LTE, it can be applied to mobile communication systems based on Long Term Evolution (LTE). Additionally, the examples of this disclosure can be applied to communication systems based on the 5G NR standard of 3GPP standards.

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

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

[0108] exist Figure 1 In the examples, the various technical features described below can be performed. Figure 1 At least one station (STA) is involved. For example, STA 110 and 120 of this disclosure may also be referred to in 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 in 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 equipment, transmitting equipment, etc.

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

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

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

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

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

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

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

[0116] For example, the second STA 120 can perform operations expected by a non-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.).

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

[0118] For example, the operation of a device designated as an AP in this 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.

[0119] 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 example, 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 the TX / RX signal of a non-AP can be stored in the memory 122 of the second STA 120. For example, 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 the TX / RX signal of a non-AP can be stored in the memory 112 of the first STA 110.

[0120] 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 without specific reference numerals 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 STA 110 and 120. For example, in the following example, it is possible to... Figure 1 The transceivers 113 and 123 perform the operation of various STA transmit / receive signals (e.g., PPDUs). Additionally, in the following example, [the following text is incomplete and requires further context]. Figure 1 Processors 111 and 121 perform operations in which various STAs generate TX / RX signals or perform data processing and calculations in advance for TX / RX signals. For example, examples of operations for generating TX / RX signals or performing data processing and calculations in advance may include: 1) operations for determining / obtaining / configuring / calculating / decoding / encoding bit information of subfields (SIG, STF, LTF, data) included in the PPDU; 2) operations for determining / configuring / obtaining time resources or frequency resources (e.g., subcarrier resources) used for the subfields (SIG, STF, LTF, data) included in the PPDU; 3) operations for determining / configuring / obtaining specific sequences (e.g., pilot sequences, STF / LTF sequences, additional sequences applied to SIG) used 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 determining / obtaining / configuring / decoding / encoding ACK signals. Additionally, in the following examples, various information used by various STAs to determine / obtain / configure / calculate / decode / decode TX / RX signals (e.g., information related to fields / subfields / control fields / parameters / power, etc.) can be stored. Figure 1 In memory 112 and 122.

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

[0122] For example, Figure 1The transceivers 113 and 123 illustrated in subgraph (b) can perform operations with... Figure 1 The transceiver illustrated in sub-diagram (a) has the same function as the aforementioned transceiver. For example, Figure 1 The processing chips 114 and 124 illustrated 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 illustrated in subgraph (b) can perform operations related to... Figure 1 The processors 111 and 121 and the memories 112 and 122 illustrated in sub-diagram (a) have the same functions as those described above.

[0123] 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 apparatus and / or transmitting apparatus described below may refer to... Figure 1 The STA 110 and 120 shown in subgraphs (a) / (b) may be an allusion to... Figure 1 The processing chips 114 and 124 are illustrated in sub-figure (b). That is to say, the technical features of this disclosure can... Figure 1 It is executed in STA110 and 120 illustrated in subgraphs (a) / (b), or it can be performed only in subgraphs (a) / (b). Figure 1 The processing is executed in the processing chips 114 and 124 illustrated in sub-figure (b). For example, the technical feature of transmitting control signals via STA can be understood as being performed through... Figure 1 The transceivers 113 and 123 illustrated in sub-diagrams (a) and (b) transmit 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 control signals transmitted by the transmitting STA 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 illustrated in sub-figure (b).

[0124] For example, the technical feature of receiving STA control signals can be understood as involving the use of Figure 1 The technical features of transceivers 113 and 123 receiving control signals are illustrated in sub-figure (a). Alternatively, the technical features of receiving control signals by a STA can be understood as follows: Figure 1 The control signals received by transceivers 113 and 123 illustrated in sub-diagram (a) are... Figure 1The technical features obtained by processors 111 and 121 illustrated in sub-figure (a). Alternatively, the technical features of receiving control signals from the STA can be understood as wherein... Figure 1 The control signals received by transceivers 113 and 123, as shown in sub-diagram (b), are... Figure 1 The technical features obtained by the processing chips 114 and 124 are illustrated in sub-figure (b).

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

[0126] 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 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 of processors manufactured by Apple®, HELIO™ series processors manufactured by MediaTek®, ATOM™ series processors manufactured by Intel®, or processors enhanced from these processors.

[0127] In this disclosure, uplink may refer implicitly to 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, downlink may refer implicitly to 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.

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

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

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

[0131] 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 such as access point (AP) 225 and station (STA1) 200-1 that are 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 be joined to an AP 230.

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

[0133] Distribution system 210 can implement an Extended Service Set (ESS) 240 that can be 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 through distribution system 210. APs included in an ESS 240 can have the same Service Set Identifier (SSID).

[0134] Portal 220 can act as a bridge connecting a wireless LAN network (IEEE 802.11) and another network (e.g., 802.X).

[0135] exist Figure 2 In the BSS illustrated in the upper part of the diagram, networking between APs 225 and 230, as well as between APs 225 and 230 and STAs 200-1, 205-1, and 205-2, can be implemented. However, networking can also be configured between STAs without APs 225 and 230 to perform communication. Networks that perform communication even between STAs without APs 225 and 230 are defined as Ad-Hoc networks or Independent Basic Service Sets (IBSS).

[0136] Figure 2 The lower part of the diagram illustrates the concept of IBSS.

[0137] refer to Figure 2The lower part of the IBSS is a BSS that operates in a self-organizing mode. Because 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 allowed.

[0138] Figure 3 The diagram illustrates the general link establishment process.

[0139] 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 networks to participate in. The process of identifying compatible networks and identifying networks present in a specific area before participating in a wireless network is called scanning. Scanning methods include active scanning and passive scanning.

[0140] Figure 3 The diagram illustrates the network discovery process during an active scan. In an active scan, 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 as a response to the probe request frame to the STA that sent the probe request frame. Here, the responder could be the STA that sent the last beacon frame in the BSS of the channel being scanned. 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 send beacon frames sequentially. 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).

[0141] although Figure 3Although 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 participate in the wireless network. In a BSS, the AP uses beacon frames to periodically send them. In an IBSS, STAs in the IBSS send beacon frames sequentially. 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. STAs that have received beacon frames can store the BSS-related information included in the received beacon frames, can move to the next channel, and can perform scanning on the next channel using the same method.

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

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

[0144] 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 result to the STA via an authentication response frame.

[0145] When a STA is successfully authenticated, it can perform an association process in S330. The association process includes the STA sending an association request frame to the AP, and the AP responding by sending an association response frame to the STA. The association request frame may include information such as various capabilities, beacon listening interval, service set identifier (SSID), supported rates, supported channels, RSN, mobility domain, supported operation categories, service indication mapping (TIM) broadcast request, and interoperability service capabilities. The association response frame may include information such as 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), mobility domain, timeout interval (association recovery time), overlapping BSS scan parameters, TIM broadcast response, and QoS mapping.

[0146] In the S340, the STA can perform a security setup process. The security setup process in the S340 may include the process of setting up a private key through a four-way handshake (e.g., via an Extensible Authentication Protocol (EAPOL) frame over a LAN).

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

[0148] like Figure 4 The diagram illustrates that 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 affiliated APs (i.e., AP STAs), and a non-AP MLD may include affiliated STAs (i.e., non-AP STAs or user STAs).

[0149] The multi-link configuration can include a first link and a second link, and different channel / subchannel / frequency resources can be allocated to the first and second links. The first and second multi-links 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 band. Alternatively, the first and second links can be configured in different bands.

[0150] Figure 4 The AP MLD includes three affiliated 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 4 In the example, the first link for both AP1 and non-AP1 operations can be defined as a channel / subchannel / frequency resource within the 2.4GHz band. Additionally, in Figure 4 In the example, the second link operating with both AP2 and non-AP2 can be defined as a channel / subchannel / frequency resource within the 5GHz band. Additionally, in Figure 4 In the example, the third link for both AP3 and non-AP3 operation can be defined as a channel / subchannel / frequency resource within the 6GHz band.

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

[0152] The specific features of this disclosure are not limited to Figure 4 Its specific characteristics include the ability to define the number of links in various ways, and the ability to define multiple links in various ways within at least one band.

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

[0154] The STA (e.g., AP STA, non-AP STA, AP MLD, non-AP MLD) disclosed herein is capable of sending and / or receiving. Figure 5 The PPDU described in this disclosure can have, for example, Figure 5 The structure is as follows. Furthermore, the PPDUs described in this disclosure can be invoked by various names such as transmit PPDU, receive PPDU, first type, or Nth type PPDU. The PPDUs described in this disclosure can be used in WLAN systems defined according to IEEE 802.11bn and / or next-generation WLAN systems that improve upon IEEE 802.11bn.

[0155] Figure 5 The PPDU can be associated with various PPDU types used in the UHR system. 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 is related to NDP, the data fields shown in the diagram can be omitted. Figure 5 If the PPDU is used in trigger-based (TB) mode, then it 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.

[0156] exist Figure 5In 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 in the physical layer (included in the transmit / receive STA).

[0157] Figure 5 Each block in the diagram can be referred to as a field / subfield / signal, etc. These field / subfield / signal names can be Legacy Short Training Field (L-STF), Legacy Long Training Field (L-LTF), Legacy Signal (L-SIG), Repeating L-SIG (RL-SIG), Universal Signal (U-SIG), UHR Signal (UHR-SIG), etc., such as... Figure 5 As shown in the diagram.

[0158] 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. In other words, the tone index (or subcarrier index) of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields can be expressed in units of 312.5 kHz, and the tone index (or subcarrier index) of the UHR-STF, UHR-LTF, and data fields can be expressed in units of 78.125 kHz.

[0159] exist Figure 5 In the PPDU, L-LTF and L-STF can be the same as those in the traditional fields (e.g., non-HT LTF and non-HT STF defined in the traditional WLAN standard).

[0160] 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 6 bits of tail bits. For instance, the 12-bit length field could include information related to the length or duration of the PPDU. For instance, the 12-bit length field could be determined based on the type of PPDU. For instance, 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 could be determined to be a multiple of 3. For instance, when the PPDU is an HE PPDU, the value of the length field could be determined to be a multiple of 3 + 1 or a multiple of 3 + 2. In other words, for non-HT, HT, VHT PPDI, EHT PPDU, or UHR PPDU, the value of the length field can be determined as a multiple of 3, and for high-efficiency (HE) PPDU, the value of the length field can be determined as 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 zero.

[0161] For example, a (non-AP and AP) STA can apply BCC encoding based on a 1 / 2 coding rate to the 24 bits of information in the L-SIG field. The transmitting STA then obtains 48 bits of BCC encoded bits. BPSK modulation can be applied to these 48 encoded bits, generating 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}. Therefore, 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}.

[0162] 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 determine whether 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 determine that the received PPDU is one of the HE PPDU, EHT PPDU, and UHR PPDU. In other words, if the RL-SIG is not present, the receiving (non-AP and AP) STA can determine that the received PPDU is one of the non-HT PPDU, HT PPDU, and 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.

[0163] It is possible Figure 6 A generic SIG (U-SIG) is inserted after the RL-SIG. U-SIG can be referred to in 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 Signal, etc.

[0164] U-SIG can include N bits of information and may include information identifying 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.

[0165] For example, via U-SIG, A bits of information (e.g., 52 uncoded bits) can be transmitted. The first symbol of U-SIG can transmit the first X bits of the A-bit information (e.g., 26 uncoded bits), and the second symbol of U-SIG can transmit the remaining Y bits of the A-bit information (e.g., 26 uncoded bits). For example, the transmitting STA can obtain the 26 uncoded 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 coded bits, and can perform interleaving on the 52 coded bits. The transmitting STA can perform BPSK modulation on the interleaved 52 coded 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 (i.e., tones -21, -7, +7, +21).

[0166] For example, the A-bit information generated by U-SIG (e.g., 52 uncoded bits) may include a CRC field (e.g., a field of 4 bits) and a tail field (e.g., a field of 6 bits). The CRC field and tail field can be sent via the 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 excluding the CRC / tail field in the second symbol, and can be generated based on a conventional CRC calculation algorithm. Additionally, the tail field can be used to terminate the grid of the convolutional decoder and can be set to, for example, "000000".

[0167] The information in A bits sent by U-SIG (or the U-SIG field) (e.g., 52 uncoded bits) 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 in various terms such as first control bit, second control bit, etc.

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

[0169] In other words, when an (AP / non-AP) STA sends an EHT PPDU, it can set the 3-bit PHY version identifier to a first value, and when an (AP / non-AP) STA sends a UHR PPDU, it can set the 3-bit PHY version identifier 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.

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

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

[0172] For example, if the UHR PPDU is classified into various types (e.g., types related to SU transmission (performed 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 (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 the UHR PPDU (e.g., 2 bits or 3 bits of information) can be included in the version-related bits of the U-SIG.

[0173] 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 coding scheme (MCS) applied to UHR-SIG; 3) an indication field including information about 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 about whether UHR-SIG is generated across the full 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.

[0174] Lead punching can be applied to Figure 5 A PPDU. A preamble puncture means applying a puncture to a portion of the full band (e.g., the secondary 20MHz band). For example, when transmitting an 80MHz PPDU, the STA can apply a puncture to the secondary 20MHz band outside the 80MHz band and can transmit the PPDU only through the primary 20MHz band and the secondary 40MHz band.

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

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

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

[0178] Alternatively, U-SIG and UHR-SIG may include information related to the leader punch, based on the following method: U-SIG may include information related to the leader punch for all bands (i.e., information related to the leader punch pattern). That is, UHR-SIG may not include information related to the leader punch, and only U-SIG may include information related to the leader punch (i.e., information related to the leader punch pattern).

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

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

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

[0182] Figure 5 The frequency resources of the UHR-LTF, UHR-STF, and data fields illustrated in the diagram can be determined based on RUs (Resource Units) defined by multiple subcarriers / tones. That is, the UHR-LTF, UHR-STF, and data fields of this disclosure can be transmitted / received through RUs (Resource Units) defined by multiple subcarriers / tones.

[0183] Figure 6 This diagram illustrates the layout of resource units (RUs) used in a 20MHz PPDU. In other words, it can be... Figure 6 At least one of the various RUs defined in the 20MHz PPDU is used to transmit / receive the UHR-LTF, UHR-STF and / or data fields included in the 20MHz PPDU.

[0184] As in Figure 6 As illustrated in the top section, 26 units (i.e., units corresponding to 26 tones) can be arranged. Six tones can be used for the guard band in the leftmost band of the 20MHz band, and five tones can be used for the guard band in the rightmost band of the 20MHz 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 26, 52, and 106 can be assigned to other bands. Each unit can be assigned to a receiving STA (i.e., a user).

[0185] at the same time, Figure 6 The RU layout in the diagram can be used not only for multiple users (MU) but also for a single user (SU). In this 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.

[0186] although Figure 6Various sizes of RUs are proposed, namely 26-RU, 52-RU, 106-RU, and 242-RU, but the specific size of the RU can be extended or increased. Therefore, this embodiment is not limited to the specific size of each RU (i.e., the number of corresponding tones). In this specification, N-RU can be represented as N-tone RU, etc. For example, 26-RU can be represented as 26-tone RU.

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

[0188] Similar to the use of RUs of various sizes Figure 6 , can Figure 7 Examples use 26-RU, 52-RU, 106-RU, 242-RU, 484-RU, etc. Additionally, five DC tones can be inserted into the center frequency, 12 tones can be used for the guard band in the leftmost band of the 40MHz band, and 11 tones can be used for the guard band in the rightmost band of the 40MHz band.

[0189] like Figure 7 As illustrated in the diagram, a 484-RU can be used when the RU layout is intended for a single user. It can be similar to... Figure 6 Change a specific number of RUs.

[0190] Figure 8 This diagram illustrates the layout of resource units (RUs) used in an 80MHz PPDU. The layout of resource units (RUs) used in this specification can vary. For example, the layout of resource units (RUs) used in the 80MHz band can be varied.

[0191] Figure 9 The operation related to the UL-MU is illustrated. As shown, a transmitting STA (e.g., AP) can perform channel access through contention (i.e., backoff operation) and transmit a trigger frame (930). That is, the transmitting STA (e.g., 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.

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

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

[0194] 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 in which channels with a center frequency adjacent to 2.4 GHz are used / supported / defined (e.g., channels with a center frequency between 2.4 and 2.5 GHz).

[0195] 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 could be 2.412 GHz, the center frequency of channel index 2 for a 20 MHz channel could be 2.417 GHz, and the center frequency of channel index N for a 20 MHz channel could be (2.407 + 0.005). (N) GHz. The channel index can be specified using various names such as channel number. The specific values ​​of the channel index and center frequency can be changed.

[0196] Figure 10 The illustration exemplarily depicts four channels within a 2.4 GHz band. Each of the illustrated first frequency region (1010) to the fourth frequency region (1040) may include one channel. For example, the first frequency region (1010) may include channel 1 (a 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.

[0197] Figure 11 The illustration shows an example of a channel used / supported / defined within the 5GHz band.

[0198] The 5GHz band can be referred to by other names such as second band / band. A 5GHz band can refer to a frequency range in which channels with a center frequency greater than or equal to 5GHz and less than 6GHz (or less than 5.9GHz) are used / supported / defined. Alternatively, a 5GHz band can include multiple channels between 4.5GHz and 5.5GHz. Figure 11 The specific graph shown undergoes changes.

[0199] Multiple channels within the 5 GHz band include the unlicensed National Information Infrastructure (UNII)-1, UNII-2, UNII-3, and ISM. UNII-1 can be referred to as UNII Low. UNII-2 can include frequency ranges referred to as UNII Mid and UNII-2 Extended. UNII-3 can be referred to as UNII-Upper.

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

[0201] Figure 12 The illustration shows an example of a channel used / supported / defined within the 6GHz band.

[0202] The 6GHz band can be referred to by other names such as the third band / band. The 6GHz band can refer to the frequency range used, supported, and defined by channels with a center frequency higher than 5.9GHz. Figure 12 The specific values ​​shown undergo changes.

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

[0204] therefore, Figure 12The index (or channel number) of the 20MHz 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-mentioned (5.940+0.005) N)GHz rules, Figure 12 The index of the 40MHz 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.

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

[0206] Figure 13 This shows an example of a MAC frame header. As shown, a MAC frame can 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 transmitter 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 can insert new fields between the four fields shown, or can omit at least one of the fields shown.

[0207] 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 MAC header and the MAC body fields / information that follow the MAC header. (Includes...) Figure 13 The MAC frame header is inserted / included in the MAC frame. Figure 5 The data fields of the PPDU (e.g., UHR PPDU) shown in the diagram.

[0208] The MAC frames included in the data fields of the PPDU disclosed herein can be classified into various types. For example, the MAC frames disclosed herein can be classified into control frames, management frames, and data frames.

[0209] For example, management frames include association requests, association responses, reassociation requests, reassociation responses, probe requests, probe responses, beacons, disassociation, authentication, and deauthentication frames / signals as defined in traditional WLANs. For management frames, Figure 8 The values ​​of the type fields (B3 and B2) are set to 00. Furthermore, Figure 8 The values ​​of the subtype fields (B7, B6, B5, 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), Disauthentication (1100).

[0210] For example, control frames include triggered beamforming report polling, NDP announcement (NDPA), control frame extension, control wrapper, block acknowledgment request (BlockAckReq), block acknowledgment (BlockAck), PS-polling (PS-Poll), RTS, CTS, Ack, and CF-End frames / signals defined in traditional WLANs. For control frames, Figure 8 The values ​​of the type fields (B3 and B2) are set to 01. Furthermore, Figure 8 The values ​​of the subtype fields (B7, B6, B5, 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-Poll (1001), RTS (1011), CTS (1101), Ack (1101), CF-End (1110).

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

[0212] The MAC frames / signals used in this disclosure can be identified by the aforementioned type field / information and subtype field / information. For example, "trigger frame" in this disclosure can 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 / UHRPPDU).

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

[0214] like Figure 14 As shown, it can be modified. Figures 1 to 4 The devices shown are (e.g., AP STA, non-AP STA). Figure 14 The transceiver 630 is capable of communicating with Figure 1 The transceivers 113 and 123 are the same. Figure 14 The transceiver 630 can include a receiver and a transmitter.

[0215] Figure 14 The processor 610 is capable of working with Figure 1 The processors 111 and 121 are the same. Alternatively, Figure 14 The processor 610 is capable of working with Figure 1 The processing chips 114 and 124 are the same.

[0216] Figure 14 The memory 150 can be with Figure 1 The memories 112 and 122 are the same. Alternatively, Figure 14 The memory 150 can be with Figure 1 The memory 112 and 122 are different separate external memories.

[0217] refer to Figure 14 The power management module 611 manages the power used by 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 keypad 614 receives input to be used by the processor 610. The keypad 614 can be displayed on the display 613. The SIM card 615 can be an integrated circuit used to securely store the International Mobile Subscriber Identity (IMSI) and its associated keys, which are used to identify and authenticate subscribers in mobile devices such as mobile phones and computers.

[0218] refer to 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.

[0219] 1. Problems with traditional technologies (rapid BSS transformation (FT))

[0220] Figure 15 The diagram illustrates the Over-the-Air (OTA) FT protocol in a Robust and Secure Network (RSN).

[0221] Currently, in 802.11, for non-AP STA mobility (roaming), for example, performing a Basic Service Set (BSS) transition from an Access Point (AP) (old AP) to another AP (new AP), a reassociation process must be performed 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 FT initiators (FTOs) and target FT responders (FTRs) (e.g., new APs).

[0222] Following this process, many operational parameters related to Block Acknowledgment (BA) and Flow Classification Service (SCS), such as protocol, sequence number (SN), and Enhanced Distributed Channel Access Function (EDCAF) parameters, are reset. Therefore, there is overhead incurred in having to re-execute the protocol / configuration along with several frame exchanges, and data loss may also occur during the FT process. Furthermore, seamless roaming, for example, roaming from the perspective of a non-AP STA without disconnection, is not easy. Therefore, this specification proposes a seamless roaming method utilizing an Access Point Multilink Device (AP MLD) to address this problem. Unlike FT, the authentication / association process is no longer performed during roaming.

[0223] In this specification, the STA performing a BSS transition (e.g., roaming) is referred to as an RSTA, the AP to which the STA is currently associated 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). Additionally, the roaming method described in this specification is referred to as MLD roaming. The designations (names) in this specification may be changed, and the STA may include an AP STA or a non-AP STA.

[0224] 2. UHR AP MLD structure for roaming

[0225] 2.1 General process of roaming in AP MLD

[0226] Figure 16 The diagram illustrates the high-level architecture used for AP MLD.

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

[0228] Therefore, based on the functionality of AP MLD, MLD-level parameters can be maintained without being reset by moving between APs attached to the AP MLD (attached AP). This specification proposes an MLD roaming method utilizing the functionality of AP MLD.

[0229] Figure 17 The diagram illustrates an example of a high-level architecture used in UHR AP MLD.

[0230] Figure 17 The architecture of an AP supporting seamless roaming is shown. To support seamless roaming, compatibility with previous standard versions of equipment should be achieved, and seamless roaming across many devices should be possible. First, to ensure legacy compatibility with previous equipment, non-UHR, non-AP STAs should be able to see non-UHR APs. Doing so should not change the existing architecture without violating the definition of MLD itself. Therefore, as... Figure 17 As shown, the new definition attaches a UHR AP MLD that enables seamless, hierarchical roaming of MLDs while maintaining the existing MLD architecture. In this case, each LMAC of the AP MLD interfaces with the UHR UMAC, and the UMAC manages the functionality of the UMAC for performing seamless roaming of the AP MLD. A separate entity can manage various functionalities used for roaming between AP MLDs (e.g., multi-link authentication (e.g., PTK), multi-link discovery / establishment, multi-link reconfiguration). For example, this specification does not limit support for roaming to a UMAC. An example of this is in... Figure 18 The entity is shown in the diagram. It can manage the control plane context and can also manage other things as needed. Each of the AP MLD and UHR AP MLD is individually connected to the distribution system (DS). This architecture also addresses the scalability problem caused by the bit size limitation of the link ID. Essentially, the link ID is 4 bits, so only up to 16 link IDs can be supported. This link ID is needed to move from one link to another during roaming, and in existing schemes, the number of APs that can roam is limited to 16. To solve this problem, the link ID is bound to the AP MLD ID, thus addressing the scalability issue. This is described in more detail in section 2.2, which will be described later.

[0231] Figure 18 The diagram illustrates another example of a high-level architecture used in UHR AP MLD.

[0232] Figure 19 The diagram illustrates another example of a high-level architecture used in UHR AP MLD.

[0233] Figure 19 Showing the use of similar Figure 17However, there are examples of architectures with different interfaces. Figure 18 Instead of directly connecting to the AP MLD's LMAC and UHR UMAC, the TID-to-link mapping functionality is interfaced with the UMAC. This architecture allows TID-to-link mapping to be performed separately in the AP MLD's UMAC, or it can be performed in the UHR UMAC. Each of the AP MLD and UHR APMLD is connected to the DS separately. There are no restrictions on the exploitation methods in this architecture, nor on the type and number of functions interfaced with the UHR UMAC.

[0234] Figure 20 The illustration is an example of a high-level architecture based on the case where only entities that are not based on MLD exist.

[0235] Figure 21 The illustration shows another example of a high-level architecture based on the case where only entities that are not based on MLD exist.

[0236] Figure 18 , Figure 20 and Figure 21 The entity within the framework has functionality for roaming. Roaming AP MCDs are connected to the same entity and can perform association, authentication, link establishment, etc., with this entity. The entity also manages the control plane context. Groups can be formed with roaming AP MLDs within the concept of a domain, and at this time, one or more entities can exist in a domain. It manages the context that should be shared between APs for non-AP STAs to perform seamless roaming.

[0237] Figure 22 This diagram illustrates an example of a roaming architecture within an AP MLD region.

[0238] Figure 22 The structure and process used for basic roaming are shown.

[0239] Each AP MLD is located in a different location (e.g., it is not co-located), and the APs belonging to each AP MLD are located in the same or similar locations (e.g., they are 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 a physical device. Basically, because an AP MLD is a logical entity, it can be any physical device, but it includes affiliated APs regardless of location and can operate as an MLD that can apply multi-link operation (MLO). Ultimately, all APs belonging to each AP MLD become affiliated APs of a single AP MLD. For example, Figure 22 AP MLD 1 includes auxiliary APs 1, 2 and 3.

[0240] based on Figure 22Based on non-AP MLD mobility, it typically involves roaming from one AP MLD to another. For example, based on a non-AP MLD with multiple links established with AP MLDs, and each STA 1 and STA 2 connected to AP 2 and AP 3 of AP MLD 1, based on roaming to AP MLD 2, STA 1 could be connected to AP 4, and STA 2 could be connected to AP 5. In this case, each STA can temporarily establish associations with AP 4 and AP 5, allowing AP 4 and AP 5 to send frames to each STA during the roaming process.

[0241] For reference, Figure 22 In this context, this 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.

[0242] However, roaming is not only considered to move between different AP MLDs. For example, even within an AP MLD, roaming can change APs.

[0243] For example, a UHR AP MLD (or a group capable of roaming) is associated with 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.

[0244] Typically, a non-AP MLD (or STA) performs roaming from one AP MLD to another (it is said that even within a specific AP MLD, roaming can change the AP).

[0245] Based on the fact that the AP is changed within the AP MLD, roaming can be considered a method of changing the link while maintaining the multi-link setup without completely dismantling the traditional multi-link setup.

[0246] Based on the fact that the AP is changed within the AP MLD, roaming can be considered a method of changing the link while maintaining the multi-link setup without completely dismantling the traditional multi-link setup.

[0247] These processes can be configured with a) an announcement process and b) frame exchange.

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

[0249] b) Frame switching process: This is the process of switching frames that may trigger MLD roaming. Based on the completion of frame switching, MLD roaming is completed based on the negotiated information, and operations are no longer performed using O_AP, but instead using N_AP.

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

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

[0252] However, due to the fact that frame switching is only performed on one link and cannot be performed on the remaining links, a doze or disabled state occurs.

[0253] - Essentially, for this purpose, the non-AP MLD informs whether the aforementioned capabilities are possible by sending a management frame during ML setup, including, for example, a basic multi-link ML IE in an association request frame. If all STAs are capable, this can be included in the MLD Capabilities and Operations subfield of the Common Information field, or if only some STAs are capable, this can be included in the Link Information field. The information to be included is as follows.

[0254] => Single Radio ML Setup 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.

[0255] 2.2 Notification process for MLD roaming

[0256] Each AP within each AP MLD can announce whether roaming as described in this specification is possible (e.g., whether frame switching is possible, as mentioned in b above). Information that can be sent jointly by all APs can indicate whether an AP belongs to a UHR AP MLD or entity, and in detail, can announce which UHR AP MLD / entity it belongs to, as well as co-location information, etc. Based on the architecture type attached to the UHR AP MLD, it can use whether it is attached to the UHR AP MLD and UHR AP MLD ID information, and based on the architecture type of the entity, it can include whether it is connected to the entity and information identifying the entity, such as the entity ID. The relevant information is as follows, and may include at least one or more.

[0257] MLD Roaming Enable: An indicator used to indicate whether roaming is possible (e.g., it can be indicated by 1 bit). Roaming is possible if the AP is attached to the same UHR AP MLD or connected to the same entity. Roaming is not possible if the AP is attached to another UHR AP MLD or belongs to another entity (e.g., another mobile domain), and this can be indicated by the MLD Roaming Enable bit.

[0258] UHR AP MLD ID / Entity ID: The ID that distinguishes the UHR AP MLD or the entities shown above. The configuration for this UHR AP MLD ID / Entity ID is as follows.

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

[0260] Essentially, an ID can be assigned to a UHR AP MLD that is an associated, co-located 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 a unique ID can be assigned to UHR AP MLDs throughout the network. Defining UHR AP MLD IDs to distinguish UHR AP MLDs can address scalability issues arising from a limited number of links and help identify more APs.

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

[0262] This chapter proposes a method where the UHR AP MLD ID is unique within a network. Essentially, the UHR AP MLD ID 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.

[0263] 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 UHR AP MLD. For example, based on this identification from 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 possible solely based on UHR AP MLD ID being 0. Additionally, because other APs (transmitted BSSID (TxBSSID) or non-transmitted BSSID (NonTx BSSID)) belonging to the multiple basic service set ID (multiple BSSID) set 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 of the APs to which these APs (TxBSSID or non-TxBSSID) belong may be different.

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

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

[0266] This chapter proposes a method for assigning unique IDs to APs that can roam throughout the entire UHR AP MLD.

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

[0268] - Concatenation Enabled: Indicates whether AP MLDs are concatenated with each other (e.g., indicated by 1 bit).

[0269] Based on Co-Enabled = 1, it means that the corresponding AP and the reporting AP are physically close. Therefore, based on the ability to communicate with regularly connected APs without moving to the AP with Co-Enabled = 1, roaming can be avoided if Co-Enabled is set to 1 among neighboring APs. For example, no roaming request / response is sent to or received from an AP with Co-Enabled = 1.

[0270] - Co-location ID: An ID used to distinguish co-located AP MLDs. The configuration for this ID is as follows.

[0271] B. Co-location ID configuration for roaming in UHR AP MLD

[0272] 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 the set of co-located AP MLDs, as described below, or a unique ID can be assigned to a co-located AP MLD within a UHR AP MLD.

[0273] B-1. Configuration of Unique Conjoint ID within Conjoint Sets in UHRAP MLD

[0274] This section proposes a method where the co-occurrence ID is unique within a co-occurrence AP MLD set. Essentially, the co-occurrence ID can be assigned values ​​such as 0, 1, 2, ..., etc. For example, a co-occurrence 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 co-occurrence ID is described below.

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

[0276] Multiple AP MLDs can be included in a set of APs with the same co-location ID.

[0277] Other co-located IDs are mapped so that each co-located AP MLD set is uniquely identified.

[0278] B-2) Unique co-located ID configuration within UHRAP MLD

[0279] This section proposes a method for assigning unique concatenated IDs within a concatenated AP MLD set in a UHR AP MLD. Essentially, the concatenated ID can be assigned values ​​such as 0, 1, 2, ..., etc. For example, a concatenated 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.

[0280] The above information can be included in management (MGMT) frames such as beacon or probe responses, and can also be included in MLD roaming IEs that include new MLD roaming information or traditional Simplified Neighbor Report (RNR) information elements (IEs). Below is an example based on inclusion in the RNR IE. Essentially, for each AP, the corresponding information can be included in the TBTT information field. In the MLD roaming parameters, including... Figure 23 and Figure 24 Add at least one or more fields, and can be as follows: Figure 23 and Figure 24 The image includes, except for. Figure 23 and Figure 24 In addition, it includes at least one or more of all fields defined in this specification.

[0281] Figure 23 An example of an RNR IE is shown.

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

[0283] Figure 24 Another example of an RNR IE is shown.

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

[0285] like Figure 23 and Figure 24 As shown, the size of the traditional MLD roaming parameter subfield is insufficient, and information can be included by creating a new MLD roaming parameter subfield in the RNR IE. The regular size can be changed, but the problem is that this may cause decoding issues for 802.11be STA. In this case, since including the MLD roaming parameter itself implies that MLD roaming is possible, MLD roaming enablement may not be included in the MLD roaming parameter subfield.

[0286] In RNR IE, such as Figure 23 As shown, overhead can be reduced by sending a message to only another AP, specifying whether it is co-located or not co-located with the AP currently sending a beacon or probe response via the co-location enable field. Additionally, as... Figure 24 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 may include only one of the co-location enable field or the co-location ID, or it may include both.

[0287] Figure 25 This shows yet another example of an RNR IE.

[0288] Based on such Figure 25 The diagram only shows whether MLD roaming is possible; traditional MLD parameter subfields can be used to indicate whether MLD roaming is enabled. Other information, such as..., can be included as separate parameters. Figure 23 As shown in the image.

[0289] 2.3 Recommendations for Roaming APs

[0290] With MLD roaming enabled based on RNR IE, non-AP MLDs request information about the APs they want to roam to by sending multi-link probe requests to enabled APs, and can notify the APs whether they are suitable for roaming by sending multi-link probe response frames. MLD roaming enable can be set to 1 based on sending ML probe request frames to roam to the corresponding AP.

[0291] 2.3.1 AP Recommended ML Probe Request Frame Format

[0292] An AP roaming recommendation enable field can be added to reduce the overhead that may occur from unnecessarily performing AP recommendations based on APs when the probe request is not for roaming.

[0293] 1) Cases included in public information fields

[0294] Figure 26 The illustration shows an example of the AP roaming recommendation enable field and the roaming reason code field in the public information field.

[0295] The presence of a bitmap can indicate whether AP roaming recommendation enable is included. This is based on the assumption that it is only included in the public information field, which is information about all APs sending probe requests to facilitate roaming. For example, the AP roaming recommendation enable field is not added to the public information if at least one or more APs are included in the ML probe request frame to perform an operation such as association rather than roaming.

[0296] Based on the STA request for recommendations for one or more AP MLDs, excluding the AP MLD ID field, it is possible to request recommendations for APs that are associated with one or more AP MLDs belonging to the same SMD or UHR AP MLD.

[0297] Based on the list of APs that can roam, sent by non-AP STAs before roaming is executed, a roaming reason code is set so that the APs can be notified why the non-AP STAs are roaming. At this point, a probe request multi-link element is added to the link reconfiguration notification request frame, allowing the APs to refer to this roaming reason code when determining which APs to recommend to non-AP STAs.

[0298] Since the roaming reason code exists in the link reconfiguration notification request frame, it is not included in the multi-link element of the probe request. If the reason for roaming is the same for all links, overhead can be reduced by including it in the common information field. Table 2 describes the settings for the roaming reason code.

[0299] Additionally, to reduce overhead, the AP roaming recommendation enable field is omitted from the existence field, and only the AP roaming recommendation enable field can be added to the public information field.

[0300] 2) Cases included in the link information field

[0301] Figure 27 The image shows an example of the AP roaming recommendation field in the link information field.

[0302] The link information field includes cases where information about an AP is requested individually to facilitate roaming. When at least one or more APs are included in an ML probe request frame to facilitate another operation, such as association rather than roaming, an AP roaming recommendation enable field can be added to the link information. Based on individual recommendations rather than recommendations for all AP MLDs belonging to a single UHR AP MLD or entity, instead of using the AP MLD ID from the common information field, the AP MLD ID from the UHR AP MLD and STA control fields is used, enabling notification of AP MLD recommendations for one or more AP MLDs.

[0303] Based on recommendations for one or more AP MLDs, recommendations can be performed by repeatedly including the link information field. There are two methods to read the last field of the per-STA profile and know that another per-STA profile for another AP MLD appears afterward. The first method can determine the total number of per-STA profiles by the number in the "Number of Per-STA Profiles" field stored in the common information field, e.g., how many recommended AP MLDs are there, and thus know that number of per-STA profiles exists. Therefore, this number of per-STA profiles is decoded. The second method can use the More STA Control field of the per-STA profile. If More STA Control is set to 1, it indicates that another per-STA profile exists after the currently decoded per-STA profile. If the More STA Control field is 0, it indicates that it per-STA profile is related to the last AP MLD among the recommended AP MLDs.

[0304] Based on the absence of the link information field, it is possible to determine the recommended requests for all STAs attached to the corresponding non-AP MLD.

[0305] 2.3.2 AP Recommended ML Probe Response Frame Format

[0306] Based on MLD roaming activation, non-AP MLD requests information about the AP it wants to roam to by making a multi-link probe request to the enabled AP, and can notify it whether the AP is suitable for roaming in response.

[0307] The recommended AP list for the probe response frame is added, along with a list of link IDs for APs suitable for roaming.

[0308] 2.3.3. AP Recommended Link Reconfiguration Notification Request Frame

[0309] Based on the link reconfiguration notification frame received from the UHR AP MLD for AP recommendation, the non-AP MLD can send a link reconfiguration notification request frame independently to the UHR AP MLD without waiting. At this time, the reason for requesting roaming can be notified via a roaming reason code. Table 2 describes the settings for the roaming reason code. Based on the non-AP STA notifying the AP of the reason for roaming in this way, the AP can recommend a more suitable AP. Since the roaming reason code is included in the probe request multi-link element, it is not included in the link reconfiguration notification request frame. Additionally, since the reason for performing roaming is different for each link, it is not included in the link reconfiguration notification request frame.

[0310] [Table 1]

[0311] [Table 2]

[0312] 2.3.4. AP Recommendation Link Reconfiguration Notification Frame

[0313] By using link reconfiguration notification frames instead of ML probe request / response frames, the UHR AP MLD can notify non-AP MLDs of links that are beneficial for roaming. Table 3 below illustrates an example of the format of the action field in the link reconfiguration notification frame.

[0314] [Table 3]

[0315] Sequence 4: For the information required for link recommendation, the existing reconfiguration multi-link IE defined in 802.11 can be utilized. The reconfiguration ML element can recommend deletion or addition as a STA profile for a single link; however, given that recommendations may not be made for multiple links, to increase efficiency, recommendations can be made for multiple links based on one or more STA profile sub-elements. In this case, the UHR AP MLD can inform the AP of its preference for moving to an AP for roaming. This can be indicated by the STA profile order or by the add / delete link ID list field. Based on the order of the STA profiles, the links to be deleted or added first can be located first, and then in the order of the next highest preference. Similarly, based on the add / delete link ID list field, the links to be deleted or added first can be located first in the list of links, and then in the order of the next highest preference.

[0316] Sequence 5: Based on the non-AP STA first sending a reconfiguration notification request frame without including the roaming reason code, or based on sending a reconfiguration notification frame without receiving a reconfiguration notification request frame, a reconfiguration notification frame can be sent based on including the roaming reason code.

[0317] 2.4 Frame Switching Process for MLD Roaming

[0318] Basically, in order to trigger MLD roaming, frame swapping is required between a non-AP MLD (or STA) and an AP MLD. Here, MGMT frames can be used as frames, and specifically, action frames, which are of the MGMT frame type, can be utilized. Here, this frame is referred to as follows.

[0319] - The frame in which the STA requests MLD roaming from the AP can be called an MLD roaming request frame.

[0320] - The frame in which the AP requests MLD roaming from the STA can be called the MLD roaming response frame.

[0321] 2.4.1 MLD Roaming Request Frame Format

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

[0323] [Table 4]

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

[0325] Sequence 4: Based on MLD roaming requests, the reconfigured multilink IE defined in the traditional 802.11 can be used for the required information.

[0326] - The modified reconfiguration of the multi-link IE is as follows.

[0327] Sequence 5: Based on request MLD roaming, the degree to which a context transfer is needed or possible can be indicated by setting the bit value of the context transfer level.

[0328] 1) Public Information Fields

[0329] Figure 28 The illustration shows an example of reconfiguring the common information field of a multi-link IE as proposed in this embodiment.

[0330] Based on the move to a new AP, from the perspective of the STA (especially the non-AP MLD), based on the simultaneous MLD roaming of one or more STAs, the MLD capabilities and operations or EML capabilities may change, and therefore such information can be additionally included in the common information field. As in the existing configuration, the existence of subfields of the common information field is determined in the existence bitmap.

[0331] The roaming reason code can be included in the reconfiguration multi-link IE based on whether the reconfiguration multi-link IE is included in the reconfiguration notification request frame, or based on whether the roaming reason code is delivered via the reconfiguration notification frame. In this case, since the reason for requesting roaming for all links is the same, the roaming reason code is included in the common information field, and the roaming reason code has the value from Table 2.

[0332] 2) Link Information Field

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

[0334] Figure 29 The illustration shows an example of reconfiguring the link information field of a multi-link IE as proposed in this embodiment.

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

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

[0337] A complete profile refers to all the information included based on the transmission of an association request frame, such as the complete information of the STA as in a conventional case. However, since this is a case of a conventional STA moving rather than a new STA moving, the capabilities or operating parameters for the STA may remain unchanged. Based on the fact that the AP MLD already knows this, it can be used as an indication to include only the changed information instead of the complete profile.

[0338] => For example, as in the conventional case, based on a complete profile = 0, which is a partial profile, only the information to be changed when moving to N_AP (e.g., fields / IE) is included in the STA profile. Alternatively, by calling the complete profile a change profile, based on this value of 1, only the information to be changed when moving to N_AP (e.g., fields / IE) is included in the STA profile.

[0339] - The MLD roaming timer refers to the time after which MLD roaming is complete and operations with O_AP cease and operations with N_AP are performed. For example, this might mean the remaining time until the expected time before switching to an AP for roaming. This relates to the TIM field, which will be described later in 2.5.

[0340] => Based on applying the MLD roaming timer to all APs, it can be combined with... Figure 23 They are included differently in the public information field. In this case, the presence of the MLD roaming timer within the public information field can be indicated by the presence of a bitmap.

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

[0342] - UHR AP MLD ID, AP MLD ID, and co-location ID can be based on Figure 25 and Figure 26 The following are additionally included in the information above: AP MLD ID is the ID of the AP MLD to which the non-AP MLD (or STA) wants to roam, and UHR AP MLD ID is the ID of the UHR AP MLD to which the non-AP MLD (or STA) wants to roam. The UHR AP MLD ID field may not exist in the reconfigured multi-link element if the APMLD checks the UHR AP MLD ID beforehand via a beacon or probe request / response process and only sends roaming requests to the same UHR AP MLD. Such cases are described below: 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.

[0343] For example, describe the format based on whether the UHR AP MLD ID, AP MLD ID, and co-location ID are always included in the reconfiguration of the multi-link IE.

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

[0345] Figure 30 The illustration shows an example of UHR AP MLD ID and AP MLD ID being included in the common information field of the reconfigured multi-link IE proposed in this embodiment.

[0346] This can be indicated by the presence of a bitmap to determine whether the UHR AP MLD ID, AP MLD ID, and co-location ID are included. Based on 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 configuration ID. For example, even within the same UHR AP MLD, requests cannot be made for multiple AP MLD IDs and multiple co-location IDs. For instance, one or more STAs cannot request reconfiguration for APs belonging to a different AP MLD than the AP with that AP MLD. However, since roaming to the same AP MLD is the general case, overhead can be reduced compared to including them in each of the link information fields below.

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

[0348] Figure 31 The illustration shows an example of the AP MLD ID being included in the common information field of the reconfigured multi-link IE proposed in this embodiment.

[0349] Based on the fact that STA and AP have been checked and identified through the previous association process, and that N_AP and O_AP are attached to the same UHR APMLD, it is not necessary to send the UHR AP MLD ID, and therefore no separate addition is required. Figure 28 In the case of the UHRAP MLD ID field shown, overhead can be reduced. Except for whether or not the UHRAP MLD ID field is included, the method of including the field is the same as in case 1 where it is included in the public information field (1-1).

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

[0351] Figure 32 The illustration shows an example of UHR AP MLD ID and AP MLD ID being included in the link information field of the reconfigured multi-link IE proposed in this embodiment.

[0352] The link information field can include multiple per-STA profile sub-elements, and each can indicate a roaming request for an AP via the link ID. The AP to which a STA intends to roam can be distinguished by the APMLD ID and UHR AP MLD ID in the STA control field of the per-STA profile element. This allows roaming requests for multiple APs corresponding to multiple AP MLD IDs, but the overhead of requesting the same AP MLD ID is greater than the method indicated in the common information field.

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

[0354] Figure 33 The illustration shows an example of the AP MLD ID being included in the link information field of the reconfigured multi-link IE proposed in this embodiment.

[0355] Based on the fact that STA and AP have been checked and identified through the previous association process, and that N_AP and O_AP are attached to the same UHR APMLD, it is not necessary to send the UHR AP MLD ID, and therefore no separate addition is required. Figure 30 The overhead can be reduced in the case of the UHRAP MLD ID field shown.

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

[0357] Figure 34 This illustrates another example where the UHR AP MLD ID and AP MLD ID are included in the link information field of the reconfigured multi-link IE presented in this embodiment.

[0358] The presence of the UHR AP MLD ID and AP MLD ID in the STA control field of each STA profile sub-element can indicate whether the UHR AP MLD ID and AP MLD ID corresponding to the AP with the corresponding 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 can request information for 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 requesting roaming for APs corresponding to the same AP MLD ID, overhead can be reduced compared to method 2) by excluding the UHR AP MLD ID and AP MLD ID.

[0359] Alternatively, by indicating the UHR AP MLD ID and AP MLD ID in public information, it can be implicitly identified that it is a roaming request for an AP corresponding to the same UHR AP MLD ID and AP MLD ID, and therefore the UHR AP MLD ID and AP MLD ID can be omitted. For example, the UHR AP MLD ID presence field and the APMLD ID presence field can be omitted.

[0360] 3-2) Case 2 included in the link information field – Case that always exists

[0361] Figure 35 The illustration shows another example where the AP MLD ID is included in the link information field of the reconfigured multi-link IE presented in this embodiment.

[0362] Based on the fact that STA and AP have been checked and identified through the previous association process, and that N_AP and O_AP are attached to the same UHR APMLD, it is not necessary to send the UHR AP MLD ID, and therefore no separate addition is required. Figure 32 The UHRAP MLD ID field shown can reduce overhead.

[0363] Additionally, because this specification includes the ability to temporarily add and remove links for MLD roaming, a method is needed to indicate this, and the following method can be used.

[0364] Basically, using 2 or more bits, the type can be Type 0: Add / Type 1: Delete / Type 2: Temporary Add / Type 3: Temporary Delete. Temporary Delete can be replaced by Type 1. Add means requesting an additional link connection between a non-AP MLD STA and an AP of the APMLD. Delete means disconnecting (removing) the currently connected link. Temporary Add means requesting an additional connection to another AP besides the currently connected AP, allowing a non-AP MLD STA to be configured with multiple links.

[0365] => The temporary field of the type field above can be configured as a separate field. For example, it can be configured with a 1-bit temporary field and a type field that excludes temporary additions / removals, and temporary additions can be configured using the values ​​of these two fields (e.g., temporary = 1, type = add).

[0366] Based on the simultaneous request 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.

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

[0368] 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. If a Link ID is included in this list, its addition (based on its Type) indicates that it is an added link among those being added and deleted simultaneously, and its deletion (based on its Type) indicates that it is a deleted link.

[0369] The value of the type field in the link information needs to be separate from the value of the type field required for simultaneous addition and deletion requests, which is only necessary for adding or deleting only. 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.

[0370] - Type 0: Add

[0371] Type 1: Delete

[0372] - Type 2: Temporary addition

[0373] Type 3: Temporary deletion

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

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

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

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

[0378] - Type 8: Link Switching

[0379] Type 4 is the case where a link is added during the operation of adding and then deleting a link, and Type 5 is the case where a link is deleted during the operation of adding and then deleting a link.

[0380] Type 6 is the case where a link is added after deletion, and Type 7 is the case where a link is deleted after deletion.

[0381] It can include type fields and temporary fields, and includes at least one or more fields.

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

[0383] Figure 36 The illustration shows an example of a temporary field included in the public information field of the reconfigured multi-link IE proposed in this embodiment.

[0384] In this scenario, only one operation can be performed on all APs. For example, based on the addition scenario, only requests to add links to the APs indicated in the link information can be executed. Figure 36 This is an example included in public information.

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

[0386] Figure 37 The illustration shows an example of a temporary field included in the link information field of a reconfigured multi-link IE as presented in this embodiment.

[0387] Given this situation, different operations can be requested for each AP. For example, one AP can be temporarily added, and another AP can be deleted. Figure 37 This is an example included in the link information.

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

[0389] Figure 38 The illustration shows another example of a temporary field being included in the link information field of a reconfigured multi-link IE as presented in this embodiment.

[0390] Figure 38 This is an example of a case where the UHR AP MLD ID field is omitted from the link information, but the type field is included in the link information.

[0391] 3-1) Example of simultaneously sending add and delete requests – adding a new link and deleting a legacy link based on intent.

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

[0393] 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. At this point, the link IDs of added links can precede those of deleted links in 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 could be set to 5, 2. While this ordering method allows us to determine which link is added and which is deleted in the public information, since this information can also be obtained from the link information field's type, setting the order might not be necessary.

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

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

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

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

[0398] In this scenario, you can request to add and then delete links using a type field value of 4 or 5 in the link information field. 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 then deleted.

[0399] 3-2) Example of sending add and delete requests simultaneously – based on the intent, first delete the legacy link and then add the new link.

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

[0401] Set the type of the public information field to 5, and perform other operations as in 3-1) “Example of sending add and delete requests simultaneously - adding a new link first and deleting a legacy link based on intent” where the public information field includes both the type field and the add / delete link ID column field.

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

[0403] Set the type of the public information field to 5, and perform other operations as in 3-1) “Example of sending add and delete requests simultaneously - add a new link first and delete a legacy link based on intent” where the public information field only includes the type field.

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

[0405] In this scenario, you can request to add and then delete links using a type field value of 6 or 7 in the link information field. 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 then deleted.

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

[0407] Figure 39 The illustration shows an example where the AP removal timer field is included in the common information field for reconfiguring multi-link IEs as presented in this embodiment.

[0408] 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 switched to the link ID in the link information field. Based on link switching, overhead can be reduced by omitting the type field in the link information field. When performing a link switch, the AP and STA should know when it should be performed. This can be determined by the AP and communicated to the STA, or determined by the STA and communicated to the AP. Based on link switching, the channels of the new and old APs are different; the new AP needs information about deletions, and the old AP needs information about additions.

[0409] Based on the AP notification STA, the MLD roaming response can be added by adding, as described later. Figure 40 or Figure 41 The channel switching count field in the configuration file is used for notification. Based on the STA determining and notifying the AP, it can also use the delete timer field (or AP remove timer field) in the MLD roaming request for notification.

[0410] Based on the use of a reconfigured IE delete timer to notify the link switching completion time, and based on all links requesting link switching through MLD roaming requests with the same delete timer value, it is possible to... Figure 36To reduce overhead, the delete timer field can be added to the public information instead of the link information, as is done in the previous case. In this case, the delete timer field can be used instead of the delete timer existence field (or AP remove timer existence field) in the link information. Since the delete timer values ​​for the links requesting the link switch are different from each other, the delete timer field can be added to the link information instead of the public information. If the link to be switched is a single link, the delete timer field can be added to the public information and the delete timer field can be added to the user information.

[0411] 2.4.2 MLD Roaming Response Frame Format

[0412] In the MLD roaming response frame, since the links should be changed while maintaining the multi-link setup, it is necessary to consider the actual link-level parameters to be provided.

[0413] [Table 5]

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

[0415] Sequence 4: Status codes can utilize traditional status code fields.

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

[0417] Sequence 5: The modified basic multi-link IE is as follows.

[0418] Sequence 6: Based on sending the MLD roaming response, the degree of context transfer required can be indicated by setting the bit value of the context transfer level.

[0419] 1) Public Information Fields

[0420] Figure 40 The illustration shows an example of the common information field of the basic multi-link IE proposed in this embodiment.

[0421] - Existing common information fields can be utilized. The common information here is the common information corresponding to the N_AP that performs MLD roaming for one or more STAs.

[0422] - Based on including basic multilink elements when sending beacon or multilink probe response frames, the channel handover count field can be omitted by using the channel handover count presence field.

[0423] 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 the inclusion in the public information, and based on the fact that the time for one or more links simultaneously requesting a link handover via an MLD roaming request to complete the handover to the new link is the same, the AP can be notified when to perform a link handover by using the channel handover count field of the public information. The link handover count indicates the number of TBTTs to be 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 to perform a link handover to the new link.

[0424] 2) Link Information Field

[0425] As mentioned 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 elements.

[0426] The following information has been changed for the STA control field, STA information field, and STA profile field of the traditional basic multi-link IE.

[0427] Figure 41 The illustration shows an example of the link information field of the basic multi-link IE proposed in this embodiment.

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

[0429] - A complete profile refers to all the information included based on the transmission of the associated response frame, such as the complete information of the AP in the conventional case. However, because 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.

[0430] 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 means the time when MLD roaming is complete and the operation with O_AP is no longer performed, and the operation with N_AP is performed. This can be achieved using the MLD roaming timer information sent by the STA, and it may not be included if the STA has already sent this information and the response status code is success.

[0431] Based on the inclusion of basic multi-link IEs in the associated request / response, since roaming-related information is not required, it can be done without adding an existence field. Figure 37This includes the UHRMAM MAC address, UHR APMLD ID, concurrency ID, channel handover count, and UHR roaming timer, as well as... Figure 38 Configure basic ML elements by including the MLD roaming timer, UHRAP MLD ID, AP MLD ID, and channel switching count fields.

[0432] Since the time when each link handover should be completed differs from one another, a channel handover count field can be added to the link information to indicate when a link handover is completed individually for each link. Based on a link handover request for only one link in an MLD roaming request, the channel handover count field can be included in the public information or in the link information.

[0433] - 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) wants to roam, and the UHR AP MLD ID is the UHR AP MLD ID of the AP MLD to which the non-AP MLD (or STA) wants to 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 MLDID field can be omitted. This situation is described in the following cases: Case 2, included in the 1-2) Common Information field; Case 2, included in the 2-2) Link Information field – always present; and Case 2, included in the 3-2) Link Information field – not always present.

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

[0435] This applies based on the method of requesting via the public information field 1) included in the above reconfiguration of ML IE.

[0436] 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 where the UHR AP MLD ID = 0 and the configuration ID ≠ 0.

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

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

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

[0440] 2-1) Case 1 included in the link information field – a case that always exists.

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

[0442] The UHR AP MLD ID and AP MLD ID corresponding to the link ID of each per-STA profile sub-element are included in the STA control field. This can provide information for multiple APs corresponding to multiple AP MLD IDs, but the overhead of providing information for the same AP MLD ID is greater than indicating it in the common information field.

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

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

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

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

[0447] This applies in the above reconfiguration of ML IE based on the method of requesting through the link information field included in 3-1) – which is not always present (Case 1).

[0448] The presence of the UHR AP MLD ID and the AP MLD ID in the STA control field of each STA profile sub-element can indicate whether the AP MLD ID corresponding to the link ID is 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 can provide information for multiple APs corresponding to multiple AP MLD IDs. Specifically, based on the indication method in the common information field of method 1), and by providing only information 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.

[0449] => Meanwhile, with a unique ID configuration within the set of concurrency settings in the AP MLD associated with the above AP MLD ID settings, the UHR AP MLD ID, AP MLD ID, and concurrency ID can be omitted based on the concurrency ID being 0. For example, based on the absence of a concurrency ID, the AP receiving the request can implicitly identify that it is a request for information from another AP used for its own AP MLD.

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

[0451] 3-2) Case 2 - Not always present when included in the link information field

[0452] This applies in the above reconfiguration of ML IE based on the method of requesting through the link information field included in 3-2) – which is not always present (case 2).

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

[0454] => Meanwhile, with a unique ID configuration within the set of juxtapositions in the AP MLD associated with the above AP MLD ID settings, the AP MLD ID and juxtaposition ID can be omitted based on the juxtaposition ID being 0. For example, based on the absence of a juxtaposition ID, the AP receiving the request can implicitly identify that it is a request for information from another AP used by its own AP MLD.

[0455] => Alternatively, based on the co-location ID indicated in the public information, it can be implicitly identified that it is information of an AP corresponding to the same co-location set, and therefore the AP MLD ID and co-location ID can be omitted. For example, the UHR AP MLD ID presence and AP MLD ID presence fields can be omitted.

[0456] Sequence 6: Group Key Information

[0457] Basically, because the group key is different for each link, it is necessary to provide group key information for N_AP.

[0458] Figure 42 The diagram illustrates an example of a group key information field.

[0459] refer to Figure 42 The length indicates the length of the group key information used. The group key information for each N_AP includes the MLO GTK KDE format, MLO IGTK KDE, and MLO BIGTK KDE defined in 802.11be, each of which contains the link ID of the corresponding N_AP.

[0460] Sequence 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.

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

[0462] - Based on the traditional UHR AP MLD management of total AID space

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

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

[0465] - The channel of an AP to be roamed 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 IE can be included in the link information of the basic multi-link IE present in sequence 5, respectively. For example, this is used to perform a channel switch for each AP for roaming.

[0466] Sequence 10: This can be used to pre-map TIDs for links to be newly connected via TID-to-link mapping. If TID-to-link mapping is not performed separately, a default mapping can be applied.

[0467] Additionally, an MLD roaming timer can be added to both the MLD roaming request and response frames.

[0468] Additionally, the AP MLD can include the MLD roaming timer for reconfiguring the ML IE mentioned above. Similarly, based on the AP MLD's current ability to control roaming, a pre-determined MLD roaming timer can be indicated. For example, if the STA does not include an MLD roaming timer or it is inappropriate, the AP MLD can set and notify it. Conversely, if the STA does not send an MLD roaming timer, the AP MLD can set and notify it. The meaning of the MLD roaming timer is the same. For example, this means the time when MLD roaming is complete and the operation with O_AP is no longer performed, and the operation with N_AP is performed.

[0469] => Based on the receipt of 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.

[0470] => 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.

[0471] Additionally, information about 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 to be roamed. This can also utilize the MLD roaming timer information sent by the STA. This is essentially related to the TIM field shown in 2.5.

[0472] => 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 body of the MLD roaming probe response frame.

[0473] 2.5 MLD Roaming Example

[0474] The process of AP and STA performing MLD roaming is as follows: Figure 43 The diagram is used to check whether N_AP can use the co-enabled field to perform the roaming process.

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

[0476] 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 MLD ID and UHR AP MLD ID (optional) of the AP to which the STA intends to roam via the link ID. The O_AP sends the STA a roaming response frame indicating whether it accepts the request and the information described in the roaming response frame format.

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

[0478] 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-enable fields within the MLD roaming parameter field. At this point, MLD roaming enable = 1, UHR AP MLD ID = 0, and co-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, based on acceptance, roams to N_AP.

[0479] Figure 44 The diagram is used to check whether N_AP can use the concatenated ID to perform the roaming process.

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

[0481] 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 MLD ID and UHR AP MLD ID (optional) of the AP to which the STA intends to roam via the link ID. The O_AP sends the STA a roaming response frame indicating whether it accepts the request and the information described in the roaming response frame format.

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

[0483] 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, UHRAP MLD ID, and concurrency ID within the MLD roaming parameter field. At this point, MLD roaming enable = 1, UHRAP MLD ID = 0, and concurrency 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, based on acceptance, roams to N_AP.

[0484] Figure 45 The illustration shows the MLD roaming process based on the UHR AP MLD ID being included in the reconfiguration element.

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

[0486] 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 checks the UHR AP MLD ID, which is included in the MLD roaming request frame. O_AP sends an MLD roaming response frame to STA indicating whether it accepts the request and the information described in section 2.4.2, the roaming response frame format.

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

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

[0489] Figure 46 The illustration shows the MLD roaming process based on the UHR AP MLD ID not being included in the reconfiguration element.

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

[0491] 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 to which STA intends to roam using the link ID and AP MLID. 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.

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

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

[0494] Figure 47 The illustration shows an example of a set of APs juxtaposed.

[0495] Figure 47 This example illustrates how roaming is determined based on co-location information, which is based on the movement of a non-AP MLD, when the AP is normally connected to AP 2. Co-location information can be found in the Co-location Enable or Co-location ID field of the RNR IE. Although APs 4 and 5, which are attached to AP MLD 2, also exist around the non-AP MLD, the non-AP MLD does not issue roaming requests for APs 4 and 5 because they are included in the same co-located AP set as the currently connected AP 2. On the other hand, for the non-AP MLD, roaming requests are possible for APs 6, 7, and 8, which are different from AP 2 and are included in the co-located AP set. By defining the co-located AP set in this way and informing users about physically nearby APs that do not require roaming, unnecessary roaming can be prevented.

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

[0497] Figure 48 The illustration shows Example 1 used in the MLD roaming process.

[0498] Figure 48 This refers to the situation where only some STAs roam to an 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 embodiment, 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 next.

[0499] In this embodiment, STA 1 and AP 1, as shown 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 information about AP 4 and whether it accepts it by including it in the Basic Multilink IE. Next, STA 2 and AP 3 also go through the same process for AP 5. At this point, STA 1 can perform the corresponding process for the connected AP 4 instead of STA 2.

[0500] Based on this example, it may be effective in receiving data. While AP 1 and STA 1 are roaming, AP 2 and STA 3 can exchange data, and while AP 3 and STA 2 are roaming, AP 4 and STA 1 can exchange data. In this case, all TIDs need to be mapped to each link in the data exchange links. However, this embodiment is difficult to apply based on the presence of STAs that are not MLDs or STAs that exist in MLDs, and frame switching overhead may relatively occur.

[0501] Figure 49 The operation procedure for Example 1 of the MLD roaming process is shown.

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

[0503] AP 1 receives a roaming request frame from STA 1. STA checks the ID of the AP to which STA intends to roam via 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, as well as the information described in 2.4.2. Roaming Response Frame Format for AP 4 and AP 5.

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

[0505] 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 information received on AP 4. Based on STA 1's roaming completion, STA 2 also roams to AP 4 based on whether it accepts AP 5 received via STA 1 and the information about AP 4 and AP 5.

[0506] 2) Example #2 - Based on all STAs moving to another group of APs at once

[0507] Figure 50 The illustration shows Example 2 for the MLD roaming process.

[0508] Figure 50 This refers to the situation where all STAs move to another group of APs at once. For example, STA 1 immediately roams from AP 1 to AP 3, and STA 2 roams from AP 3 to AP 5.

[0509] In this embodiment, STA 1 and AP 1 or STA 2 and AP 3 shown above can exchange MLD roaming requests / responses. In this case, the MLD roaming request will indicate the UHR AP MLD ID (optional), AP MLD ID, and link ID for AP 4 and AP 5, and AP 1 or AP 3 will provide information about AP 4 and AP 5 and whether or not it accepts the request by including it in the basic multi-link IE.

[0510] Based on this example, compared to Example 1, frame overhead can be reduced, and data latency can be decreased based on the AP MLD roaming domain structure. For example, based on the anchor AP existing in the AP MLD, which manages data reception from the DS and MLD roaming, and based on this anchor AP accepting MLD roaming requests, a data path can be pre-set for roaming.

[0511] Figure 51 Example 2 illustrates the operation process used for the MLD roaming process.

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

[0513] AP 1 receives a roaming request frame from STA 1. STA checks the ID of the AP to which STA intends to roam via 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, as well as the information described in 2.4.2. Roaming Response Frame Format for AP 4 and AP 5.

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

[0515] 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 information received on AP 4. Based on STA 1's roaming completion, STA 2 also roams to AP 4 based on whether it accepts the information received from AP 1 regarding AP 5 and AP 4 and AP 5.

[0516] 3) Example #3 - Used to perform temporary addition and deletion procedures separately (this procedure can be executed simultaneously using a timer).

[0517] Figure 52 The illustration shows Example 3 for the MLD roaming process.

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

[0519] In this embodiment, for the temporary addition shown 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 UHR AP MLD ID (optional), AP MLD ID, and link ID for AP 4 and AP 5, and AP 1 or AP 3 will provide information about AP 4 and AP 5 and whether or not it is accepted by including it 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, based on performing frame exchange with AP 1, frame exchange with AP 4 may not be performed. Next, STA 1 performs a temporary deletion (or removal) operation for AP 1, and STA 2 performs the operation for AP 3. Through this process, roaming from STA 1 to AP 4 and from STA 2 to AP 5 is completed.

[0520] The examples above illustrate the processes of temporarily adding and deleting devices. Here, based on the use of timers, 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, the MLD roaming request simultaneously requests deletion (or temporary deletion) for AP 1 and AP 3, and temporary addition for AP 4 and AP 5. At this point, the MLD roaming timer shown above is set. This can be set by a non-AP MLD or AP MLD via the MLD roaming response as mentioned above. 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 AP3 is removed from STA 2 and fully connected to AP 5.

[0521] Figure 53 Example 3 illustrates the operation process used for the MLD roaming process.

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

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

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

[0525] STA 1 sends MLD roaming request frames to AP 4 and AP 5 to AP 1. Based on roaming acceptance received via an MLD roaming response frame from AP 1, STA 1 roams to AP 4 based on the information received on AP 4. Based on STA 1's roaming completion, STA 2 also roams to AP 4 based on whether it accepts the information received from STA 1 regarding AP 5 and 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.

[0526] 4) Examples #4 to #6 - The process of adding after deletion or deleting after addition.

[0527] Figure 54 The illustration shows Example 4 used in the MLD roaming process.

[0528] Figure 54 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 adds (or temporarily adds) AP 4 and AP 5 respectively.

[0529] In this embodiment, for the deletion shown above, STA 1 and AP 1, or STA 2 and AP 3, can first exchange MLD roaming requests / responses. At this time, the (optional) UHR APMLD, 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 information about AP 4 and AP 5 and whether to accept it by including it in the basic multi-link IE. Based on this process, STA 1 or STA 2 can disconnect from AP 1 and AP 3. Even in the case of deleting a link, based on data from the AP that has already performed link deletion, the STA that has not yet deleted it can instead receive it, or the UHR AP MLD can send it to the AP for roaming and send it 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.

[0530] The examples above illustrate the processes of temporarily adding and removing links, respectively. Here, based on the use of timers, 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, removals (or temporary removals) 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 shown above is then set. This can be set by a non-AP MLD or AP MLD via the MLD roaming response as mentioned above. After the MLD roaming response is successfully sent, the timer runs, and based on the timer timeout, 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.

[0531] Figure 55 Examples 3 and 4 illustrate the operational procedures used for the MLD roaming process.

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

[0533] AP1 receives a roaming request frame from STA1. STA1 and STA2 check the IDs of the APs (AP4 and AP5) they intend to roam to using the link ID, AP MLD ID, and UHR APMLD ID (optional). AP1 sends an MLD roaming response frame to STA1 indicating whether it accepts the request, along with information for AP4 and AP5 as described in section 2.4.2. Roaming Response Frame Format. AP1 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.

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

[0535] 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 an MLD roaming response frame from AP 1 to determine whether roaming of AP 4 and AP 5 is accepted, along with information about the APs (see 2.4.1). STA 1 sets an MLD roaming timer. At this point, based on the MLD roaming timer timeout, the regular connection is completely removed and a new connection is established in the roaming AP.

[0536] Figure 56 The illustration shows Example 5 used in the MLD roaming process.

[0537] Figure 57 The illustration shows Example 6 used in the MLD roaming process.

[0538] Figure 56 and Figure 57 This is an example of a method for setting the type field of an MLD request frame based on simultaneously sending link add and delete requests. Figure 56In the case where a non-AP MLD first requests a link addition to roam to a new AP MLD (AP MLD 2), and based on the established connection between STA 1 and AP 4, requests the deletion of the connection with AP 1, which is normally connected to STA 1. Based on the add / delete requests, the link ID and AP MLD ID can be used to request the add / delete of the AP that sent the request. Based on the sending of the delete request and the complete deletion of the connection between STA 1 and AP 1, STA 1 cannot send or receive data using 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 can be reduced during roaming. Based on the completion of the link change for STA 1, STA 2 can similarly request a link addition to 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 are attached 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 57 With Figure 56 The same overall roaming process, but a link with AP MLD 2 is added after the link is first removed.

[0539] Based on adding and deleting links, two requests can be made one at a time in the MLD roaming request frame, or two operations can be requested simultaneously in a single frame. Based on simultaneous requests, the MLD roaming request frame can be... Figure 56 In this case, the configuration is based on the method described in 3-1) of the MLD roaming request frame format 2.4.1, "An embodiment of the case where add and delete requests are sent simultaneously—based on the intention to first add a new link and delete a legacy link," and the MLD roaming request frame can be based on... Figure 57The configuration follows the method described in 3-2) of the MLD roaming request frame format 2.4.1, "Example of simultaneous addition and deletion requests – based on the intention to first delete a legacy link and add a new link." For example, the link information field can be configured with two per-STA profiles (one for addition and another for deletion). The configuration of the MLD roaming request frame that first sends the addition / deletion request based on separate requests can be as follows: 1) included in the MLD roaming request frame body or the common information field of the reconfiguration IE in the 2.4.1 MLD roaming request frame format; 2) included in the MLD roaming request frame body or the link information field of the reconfiguration IE; or 2) included in the MLD roaming request frame body or the link information field of the reconfiguration IE. Subsequently, a response to the request is received as an MLD roaming response frame, and whether the MLD roaming request frame is accepted / rejected can be determined via a status code.

[0540] In addition, in order to fully transition STA 1 from AP 1 to AP 4, it is necessary to have things such as Figure 58 and Figure 59 The process.

[0541] Figure 58 An example of MLD roaming using TIM is shown.

[0542] AP 1 notifies STA 1 via TIM whether there is DL data to be sent to STA 1 via beacon. At this point, to allow STA 1 to add AP 4 for roaming, STA 1 sends an MLD roaming request. For reference, although this example only includes STA 1, it is also possible to request the addition of a link to AP 5 for STA 2, as in... Figure 44 Similarly, AP 1 checks this and responds to AP 4's acceptance. However, STA 1 may have already received DL data from AP 1's nearest beacon without information that it is being buffered, or even if it is being buffered, it may not have received it. Therefore, AP 1 can notify STA 1 that AP 4 or UHR AP MLD has the corresponding DL data. For example, based on a switch to AP 4, STA 1 can receive DL data by immediately sending a PS poll 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, as follows: -> Service Indication Mapping (TIM) field (e.g., 1 bit): This indicates that the corresponding AP or AP MLD is currently buffering DL data for the requested STA.

[0543] From an MLD-level perspective, based on the UHR AP MLD notification, which is buffering DL data for the requested STA, the TIM field can be included in the MLD roaming response frame body or the public information field.

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

[0545] 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 how much time remains before data is received from the AP to be roamed (e.g., AP 4) before handover, STA 1 can first receive DL data by polling the currently connected AP (e.g., AP 1) via PS (if necessary), and then handover. Alternatively, STA 1 can handover immediately if there is time to receive data from AP 4 even if handover is immediate.

[0546] Figure 59 The diagram illustrates the operation process for using TIM's MLD roaming process.

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

[0548] 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 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 a disconnect request received from the STA, AP 1 (+AP 3) deletes the regular connection.

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

[0550] STA 1 sends an MLD roaming request to perform roaming and add AP 4. At the same time, it can also request the addition of a link to AP 5 for STA 2. 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 poll to AP 4 (+AP 5) and receives DL data accordingly. STA 1 (+STA 2) requests link deletion from AP 1 (+AP 3).

[0551] 2.6 Roaming process using context-based teleportation

[0552] <Baseline of the roaming process>

[0553] Figure 60 The diagram illustrates the basic process of the roaming process.

[0554] refer to Figure 60 Roaming requests are sent from either a non-AP MLD or an AP MLD, establishing a link between the target AP MLD and the non-AP MLD. The AP MLD or non-AP MLD can notify the user of the success or failure of the link establishment via the roaming response. Roaming requests and responses can be sent by either a non-AP MLD or an AP MLD, and are connected via backhaul between the serving AP MLD and the target AP MLD. Information regarding the roaming request / response is shared between them.

[0555] Figure 61 An example of the baseline for the roaming process is shown.

[0556] Figure 61 The diagram illustrates the operation process for both non-AP MLD-based roaming requests and non-AP MLD-based roaming responses.

[0557] refer to Figure 61 The AP MLD sending and receiving process is as follows.

[0558] The AP MLD receives roaming request frames from the non-AP MLD. Based on the establishment of a link between the target AP MLD and the non-AP MLD, the AP MLD receives roaming response frames from the non-AP MLD.

[0559] refer to Figure 61 The non-AP MLD sending and receiving process is as follows.

[0560] The non-AP MLD sends a roaming request frame to the AP MLD. Based on the establishment of a link between the target AP MLD and the non-AP MLD, the non-AP MLD sends a roaming response frame to the AP MLD.

[0561] Figure 62 Another example of the baseline for the roaming process is shown.

[0562] Figure 62 The diagram illustrates the operation process for sending a roaming request based on the AP MLD and for sending a roaming response without the AP MLD.

[0563] refer to Figure 62 The AP MLD sending and receiving process is as follows.

[0564] The AP MLD sends a roaming request frame to the non-AP MLD. Based on the link established between the target AP MLD and the non-AP MLD, the AP MLD receives a roaming response frame from the non-AP MLD.

[0565] refer to Figure 62 The non-AP MLD sending and receiving process is as follows.

[0566] The non-AP MLD receives a roaming request frame from the AP MLD. Based on the establishment of a link between the target AP MLD and the non-AP MLD, the non-AP MLD sends a roaming response frame to the AP MLD.

[0567] Figure 63 Another example of the baseline for the roaming process is shown.

[0568] Figure 63 The diagram illustrates the operation process for sending a roaming request based on a non-AP MLD and for sending a roaming response based on an AP MLD.

[0569] refer to Figure 63 The AP MLD sending and receiving process is as follows.

[0570] The AP MLD receives roaming request frames from the non-AP MLD. Based on the established link between the target AP MLD and the non-AP MLD, the AP MLD sends a roaming response frame to the non-AP MLD.

[0571] refer to Figure 63 The non-AP MLD sending and receiving process is as follows.

[0572] The non-AP MLD sends a roaming request frame to the AP MLD. Based on the establishment of a link between the target AP MLD and the non-AP MLD, the non-AP MLD receives a roaming response frame from the AP MLD.

[0573] Figure 64 Another example of the baseline for the roaming process is shown.

[0574] Figure 64 The diagram illustrates the operation process of sending a roaming request based on the AP MLD and sending a roaming response based on the AP MLD.

[0575] refer to Figure 64 The AP MLD sending and receiving process is as follows.

[0576] The AP MLD sends a roaming request frame to the non-AP MLD. Based on the established link between the target AP MLD and the non-AP MLD, the AP MLD sends a roaming response frame to the non-AP MLD.

[0577] refer to Figure 64The non-AP MLD sending and receiving process is as follows.

[0578] The non-AP MLD receives roaming request frames from the AP MLD. Based on the establishment of a link between the target AP MLD and the non-AP MLD, the non-AP MLD receives roaming response frames from the AP MLD.

[0579] 2.6. Context Delivery Level

[0580] To prevent data discontinuity issues caused by factors such as packet loss when roaming from a non-APSTA to a new AP MLD, necessary information from the previously connected AP MLD can be proactively sent to the new AP MLD before the non-AP STA performs roaming using context transfer, as described later. Figure 70 The example shown is the same. In this case, the non-APSTA waits during its roaming period to perform context transfer after requesting roaming and then performs roaming, and the latency caused by context transfer increases as the amount of information used for context transfer increases. Here, the concept of a context transfer level is defined, in which only necessary information can be transferred to avoid latency caused by unnecessary context transfer based on cases where context transfer is not required. For the context transfer level, based on the execution of the roaming request, the non-AP STA can specify the context transfer level, or the serving AP MLD can specify the context transfer level and notify the non-AP STA of the context transfer level. If the non-AP MLD STA does not need to know the context transfer level, the context transfer level may not be notified to the non-AP MLD STA.

[0581] The context delivery level can be set using at least one or more of the following methods.

[0582] 1) Cumulative method

[0583] Context delivery level = 0: Delivery context A

[0584] Context delivery level = 1: Deliver context A+B

[0585] …

[0586] As mentioned above, it is a method that includes the context transmitted at the previous context transmission level and the new context.

[0587] An example of a context, such as A and B, to be transmitted could be as follows.

[0588] A = Serial Number (SN)

[0589] B = Group number (PN)

[0590] C=BA Protocol

[0591] D=BA parameter

[0592] …

[0593] The examples above are merely illustrative and are not limited to those examples. Furthermore, more types of contexts than those mentioned can be defined.

[0594] 2) Independent Method

[0595] Context delivery level = 0: Context A

[0596] Context delivery level = 1: Context B

[0597] …

[0598] In the standalone approach, based on selecting only one context delivery level, only one context can be sent, or based on selecting multiple context delivery levels, multiple contexts can be sent.

[0599] Based on context delivery level 1, only context B is delivered; and based on context delivery levels 0 and 1, both contexts A and B are delivered.

[0600] Examples of contexts A and B can be the same as those given in 1) the accumulation method.

[0601] 3) Bitmap

[0602] As an alternative to methods 1) and 2), the level used for context passing can be set via a bitmap.

[0603] For example, based on the fact that the bitmap has X bits, B0 can be set as context A, and B1 can be set as context B.

[0604] Additionally, as in the independent method in 2), it is possible to configure the transmission of multiple types of context, rather than just one type, by combining multiple bits.

[0605] As another example, contextual information about bit-based values ​​can also be set as follows.

[0606] [Table 6]

[0607] For example, the context delivery level is set to 0 based on the possibility of roaming solely through an entity or UHR MLD without context delivery. The context delivery level is set to 1 based on the requirement to send only SN / PN information via context delivery. Contexts included in the context delivery level value can be included using an accumulation method. Based on a context delivery level set to 3, context delivery items with values ​​of 1 and 2 are included. The accumulation method is one of several methods and is not limited to those described above.

[0608] Figure 65 The illustration shows an example of the baseline of the roaming process, including the roaming preparation and execution phases, during the MLD roaming request / response process.

[0609] The roaming process can be divided into a roaming preparation phase and a roaming execution phase. In the roaming preparation phase, the link between the non-AP MLD and the target AP MLD is established, and a first context transfer occurs. In the roaming execution phase, a second context transfer occurs, and the DS mapping changes from the serving AP MLD to the target AP MLD. In this case, an update to the DS mapping change occurs.

[0610] In the first context transfer, static information (e.g., SCS) can be transferred, and in the second context transfer, dynamic context can be sent.

[0611] Items requiring context transfer can be requested by a non-AP MLD and can be requested via a roaming request frame. They can be requested only during the preparation phase or additionally during the roaming execution phase. A non-AP MLD can also individually indicate items it does not want to have their context transferred.

[0612] Figure 66 The illustration shows an example of the baseline of the roaming process, including the roaming preparation and execution phases.

[0613] Figure 66 This includes cases where roaming requests are sent based on non-AP MLDs and cases where roaming responses are sent based on non-AP MLDs.

[0614] refer to Figure 66 The AP MLD sending and receiving process is as follows.

[0615] The AP MLD receives a roaming request frame from a non-AP MLD. Once a link is established between the target AP MLD and the non-AP MLD, the AP MLD receives a roaming response frame from the non-AP MLD. In this case, the roaming response frame can indicate whether the context received via the roaming request is transmitted.

[0616] refer to Figure 66The non-AP MLD sending and receiving process is as follows.

[0617] The non-AP MLD sends a roaming request frame to the AP MLD. In this case, the roaming request frame can indicate items that are expected to be used for context transfer or items that are not expected to be used for context transfer. Based on the establishment of a link between the target AP MLD and the non-AP MLD, the non-AP MLD sends a roaming response frame to the AP MLD.

[0618] Figure 67 The illustration shows another example of the baseline of the roaming process, including the roaming preparation and execution phases. (Figure)

[0619] Figure 67 This includes cases where roaming requests are sent based on AP MLDs and cases where roaming responses are sent based on non-AP MLDs.

[0620] refer to Figure 67 The AP MLD sending and receiving process is as follows.

[0621] The AP MLD sends a roaming request frame to a non-AP MLD. In this case, the roaming request frame can indicate whether or not the items expected to be used for context transmission are intended for use. Based on the established link between the target AP MLD and the non-AP MLD, the AP MLD receives a roaming response frame from the non-AP MLD. In this case, the roaming response frame can indicate whether the context received via the roaming request should be transmitted.

[0622] refer to Figure 67 The non-AP MLD sending and receiving process is as follows.

[0623] The non-AP MLD sends a roaming request frame to the AP MLD. Once the link between the target AP MLD and the non-AP MLD is established, the non-AP MLD sends a roaming response frame to the AP MLD.

[0624] Figure 68 The illustration shows another example of the baseline of the roaming process, including the roaming preparation and execution phases.

[0625] Figure 68 This includes cases where roaming requests are sent based on AP MLD and cases where roaming responses are sent based on AP MLD.

[0626] refer to Figure 68 The AP MLD sending and receiving process is as follows.

[0627] The AP MLD sends a roaming request frame to the non-AP MLD. In this case, the roaming request frame can indicate items that are expected to be used for context transfer or items that are not expected to be used for context transfer. Based on the establishment of a link between the target AP MLD and the non-AP MLD, the AP MLD sends a roaming response frame to the non-AP MLD.

[0628] refer to Figure 68 The non-AP MLD sending and receiving process is as follows.

[0629] The non-AP MLD receives a roaming request frame from the AP MLD. Based on the established link between the target AP MLD and the non-AP MLD, the non-AP MLD receives a roaming response frame from the AP MLD. In this case, the roaming response frame can indicate whether the context received via the roaming request is transmitted.

[0630] Figure 69 The illustration shows another example of the baseline of the roaming process, including the roaming preparation and execution phases. (Figure)

[0631] Figure 69 This includes cases where roaming requests are sent based on non-AP MLDs and cases where roaming responses are sent based on AP MLDs.

[0632] refer to Figure 69 The AP MLD sending and receiving process is as follows.

[0633] The AP MLD receives a roaming request frame from a non-AP MLD. Once a link is established between the target AP MLD and the non-AP MLD, the AP MLD sends a roaming response frame to the non-AP MLD.

[0634] refer to Figure 69 The non-AP MLD sending and receiving process is as follows.

[0635] The non-AP MLD sends a roaming request frame to the AP MLD. In this case, the roaming request frame can indicate whether or not items are expected to be used for context transmission. Based on the established link between the target AP MLD and the non-AP MLD, the non-AP MLD receives a roaming response frame from the AP MLD. In this case, the roaming response frame can indicate whether the context received via the roaming request should be transmitted.

[0636] <Roaming process using context teleportation>

[0637] Figure 70 The illustration shows an example of a roaming process using context delivery (only the entity exists).

[0638] Figure 70This is an example of a roaming process based on the existence of context-based delivery. A roaming request is sent based on a non-AP MLD, such as... Figure 71 The process illustrated includes the following steps: First, to perform roaming, the non-AP STA sends the ID information of the AP to be roamed to the UHR APMLD or AP MLD via a roaming request frame. Additionally, the context transfer level field of the roaming request frame can be used to determine the context to be transferred. The UHR AP MLD or AP MLD receiving the roaming request frame notifies whether roaming to the requested AP is possible and the context transfer level via a roaming response frame. Based on the roaming request frame received from the non-AP MLD, the UHR AP MLD or AP MLD sends the control context to be transferred, set in the context transfer level, to the AP MLD to be roamed via the DS. If the context transfer level is set to 0, no context transfer is performed. Once the context transfer is complete, the AP MLD requests link addition to the non-AP MLD. Based on the link established between the AP MLD to be roamed and the non-AP MLD, in the case of downlink (DL), the AP MLD sends packets queued in the AP MLD before roaming, based on the sequence number (SN) / packet number (PN) information received via context transfer but not sent due to roaming to the non-AP STA. Subsequently, new packets received from the DS are received by the AP MLD after roaming. In the case of uplink (UL), the non-AP STA sends packets to the AP MLD after roaming. The AP MLD requests link deletion for all links connected to the AP MLD and non-AP STAs before roaming, and the roaming process ends once all link deletions are completed.

[0639] Figure 72 This is a process example of sending a roaming request based on an AP MLD. When sending a roaming request based on an AP MLD, the context transfer level can be used to inform the AP MLD's capability to perform context transfers. In this case, when a roaming response is sent based on a non-AP STA, the context transfer level value is set to a value less than or equal to the context transfer level value of the roaming request.

[0640] Figure 71 This diagram illustrates an example of a roaming process using context-based delivery.

[0641] Figure 71 This is a process example based on sending a roaming request using a non-AP MLD.

[0642] refer to Figure 71 The AP MLD sending and receiving process is as follows.

[0643] The AP MLD receives roaming request frames from a non-AP MLD. The AP MLD transmits information about the existing AP MLD (serving AP MLD) and necessary context to the target AP MLD to which the non-AP MLD intends to roam. Based on the context transfer, the UHRAP MLD (or entity) requests link addition to the non-AP MLD. After the new link is established, in a DL environment, the target AP MLD sends packets queued in the existing AP MLD's queue based on the sequence number (SN) / packet number (PN) information received via the context transfer. In a UL environment, the target AP MLD receives frames only through the new link. The target AP MLD requests link deletion for links connected to the existing AP MLD.

[0644] refer to Figure 71 The non-AP MLD sending and receiving process is as follows.

[0645] The non-AP MLD sends a roaming request frame to the UHR AP MLD (or serving AP MLD). The non-AP MLD receives information about the AP and whether roaming is accepted by receiving roaming response frames. Based on a received link add request, the non-AP MLD sends and receives frames via the link connected to the new AP MLD (target AP MLD). Based on a received link delete request, the non-AP MLD deletes the link connected to the existing AP MLD (serving AP MLD).

[0646] Figure 72 This illustration shows another example of a roaming process using context delivery.

[0647] Figure 72 This is an example of the process of sending a roaming request based on AP MLD.

[0648] refer to Figure 72 The AP MLD sending and receiving process is as follows.

[0649] The AP MLD sends a roaming request frame to a non-AP MLD. The AP MLD transmits information about the existing AP MLD (serving AP MLD) and necessary context to the target AP MLD to which the non-AP MLD intends to roam. Based on the context transfer, the UHR AP MLD (or entity) requests link addition to the non-AP MLD. After the new link is established, in a DL environment, the target AP MLD sends packets queued in the existing AP MLD's queue based on the sequence number (SN) / packet number (PN) information received via the context transfer. In a UL environment, the target AP MLD only receives frames via the new link. The target AP MLD requests link deletion for links connected to existing AP MLDs.

[0650] refer to Figure 72 The non-AP MLD sending and receiving process is as follows.

[0651] The non-AP MLD receives roaming request frames from the UHR AP MLD (or serving AP MLD). The non-AP MLD receives roaming response frames to obtain information about the AP and whether roaming is accepted. Based on a received link add request, the non-AP MLD sends and receives frames via the link connected to the new AP MLD (target AP MLD). Based on a received link delete request, the non-AP MLD deletes the link connected to the existing AP MLD (serving AP MLD).

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

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

[0654] Figure 73 Some steps in each step of the example (or detailed sub-steps described later) can be skipped / omitted.

[0655] Through step S7310, the transmitting device (transmitting STA) can obtain information about the tone plan described above. As mentioned 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.

[0656] In step S7320, 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 S7320 includes configuring the EHT-SIG field, which includes control information regarding the tone plan. That is, step S7320 includes configuring a field that includes control information (e.g., an N-bitmap) indicating the size / location of the RU; and / or configuring a field that includes the identifier (e.g., AID) of the STA receiving the RU.

[0657] Furthermore, step S7320 may include generating an STF / LTF sequence transmitted via a specific RU. The STF / LTF sequence may be generated based on a preset STF generation sequence / LTF generation sequence.

[0658] In addition, step S7320 may include generating a data field (i.e., MPDU) sent through a specific RU.

[0659] The transmitting device can send the PPDU constructed in step S7320 to the receiving device based on step S7330.

[0660] While performing step S7330, the transmitting device may perform at least one of operations such as CSD, spatial mapping, IDFT / IFFT operation, and GI insertion.

[0661] It is possible to Figure 5 The signals / fields / sequences constructed according to this specification are sent in the form of [the specified format].

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

[0663] According to Figure 74 The example is used to receive the aforementioned PPDU.

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

[0665] Figure 74 Some steps in each step of the example (or detailed sub-steps described later) can be skipped / omitted.

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

[0667] The sub-steps of step S7410 can be based on Figure 73 Step S7330 is used to determine this. That is, in step S7410, the results of the CSD, spatial mapping, IDFT / IFFT operations, and GI insertion operations applied in step S7330 can be recovered.

[0668] In step S7420, the receiving device can perform decoding on all or part of the PPDU. Furthermore, the receiving device can obtain control information related to the tone plan (i.e., RU) from the decoded PPDU.

[0669] More specifically, the receiving device can decode the L-SIG and EHT-SIG of the PPDU based on the legacy STF / LTF and obtain the information included in the L-SIG and EHT SIG fields. Information about the 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 the tone scheme (i.e., RU) through the EHT-SIG.

[0670] In step S7430, 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 S7120. For example, the receiving STA can decode the STF / LTF field of the PPDU based on the information about a plan (i.e., RU). Additionally, the receiving STA can decode the data field of the PPDU based on the information about the audio plan (i.e., RU) and obtain the MPDU included in that data field.

[0671] Additionally, the receiving device can perform a processing operation to transmit the data decoded in step S7430 to a higher layer (e.g., the MAC layer). Furthermore, when a signal indicating the transmission from the upper layer to the PHY layer is generated in response to data sent to the upper layer, subsequent operations can be performed.

[0672] In the following text, reference will be made to Figures 1 to 74 The above embodiments are described.

[0673] Figure 75 This is a flowchart illustrating the process of an AP performing an MLD roaming using context transmission according to this embodiment.

[0674] Figure 75 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 are backward compatible with the 802.11be system.

[0675] This embodiment proposes a method for selecting the context to be transmitted from the serving AP MLD to the target AP MLD based on information about the context transmission level during the exchange of roaming request frames and roaming response frames for MLD roaming. Specifically, this embodiment has the effect of preventing delays due to unnecessary context transmission by selectively transmitting context based on performing renegotiation between the non-AP STA and the target AP MLD.

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

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

[0678] Roaming from the first AP to the second AP is performed based on MLD roaming request frames and MLD roaming response frames.

[0679] The first AP is attached to a first AP multi-link device (MLD), and the second AP is attached to a second AP MLD. The first AP MLD and the second AP MLD are included in a group that is capable of roaming.

[0680] The first AP can be referred to as the old AP (O_AP), the serving AP, or the current AP. The second AP can be referred to as the new AP (N_AP) or the target AP. The first AP MLD, which includes the first AP, can be referred to as the serving AP MLD. The second AP MLD, which includes the second AP, can be referred to as 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 without disconnection between the AP and the STA within the MLD.

[0681] A group that can roam 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 group that can roam, so roaming (or moving) from an AP in the first AP MLD to an AP in the second AP MLD is possible. APs in the first AP MLD are co-located. APs in the second AP MLD are also co-located.

[0682] MLD roaming request frames include information about the context delivery level.

[0683] The context to be transmitted from the first AP MLD to the second AP MLD is selected based on information about the context transmission level.

[0684] This embodiment proposes a method for selecting a context for proactively transmitting necessary information before a non-AP STA performs roaming to a target AP MLD. Specifically, this embodiment defines a context transmission level for the context and proposes a method for selecting the context required for roaming based on the context transmission level. This avoids delays caused by transmitting unnecessary context and allows only the necessary information to be transmitted, resulting in improved seamless roaming.

[0685] Context can be transferred from a first AP MLD to a second AP MLD based on an MLD roaming request frame. Specifically, the first AP MLD, the second AP MLD, and roaming groups can be connected to a distribution system (DS). After sending the MLD roaming request frame, the context can be transferred to the second AP MLD via the DS.

[0686] The context can be referred to as the set of parameters negotiated between the AP and STA (or between the non-AP MLD STA and the serving AP MLD). The DS can be the backbone network of a wireless LAN used to extend the wireless network by providing connectivity between different basic service sets (BSS).

[0687] Information about the context delivery level can be set in various ways.

[0688] As an example, information about the context delivery level can be set in a separate way.

[0689] For example, if the context transfer level information is set to 0, the context for transmission from the first AP MLD to the second AP MLD may not exist. Given that the context transfer level information is set to 0, proactive context transfer may not be necessary because the context information required for roaming is absent.

[0690] Based on the information about the context transmission level being set to 1, the context transmitted from the first AP MLD to the second AP MLD can be a sequence number (SN) or a packet number (PN).

[0691] Based on the information about the context transfer level being set to 2, the context transferred from the first AP MLD to the second AP MLD can be the Block Ack (BA) protocol.

[0692] Based on the information about the context transmission level being set to 3, the context transmitted from the first AP MLD to the second AP MLD can be packet reordered.

[0693] Based on the information about the context transmission level being set to 4 to 15, the context transmitted from the first AP MLD to the second AP MLD can be preserved.

[0694] As another example, information about the context delivery level can be set using an accumulative method.

[0695] Based on the information about the context transmission level being set to 1, the context transmitted from the first AP MLD to the second AP MLD can be either SN or PN.

[0696] Based on the information about the context transmission level being set to 2, the context transmitted from the first AP MLD to the second AP MLD can be either SN or PN and BA protocols.

[0697] Based on the information about the context transmission level being set to 3, the context transmitted from the first AP MLD to the second AP MLD can be SN or PN, BA protocol, and packet reordering.

[0698] As another example, information about the context delivery level can be set using a bitmap method.

[0699] For example, based on a bitmap of 3 bits, with B0 set to 1, the context transmitted from the first AP MLD to the second AP MLD can be SN or PN; with B1 set to 1, the context transmitted from the first AP MLD to the second AP MLD can be BA protocol; and with B2 set to 1, the context transmitted from the first AP MLD to the second AP MLD can be group reordered.

[0700] The context transmitted from the first AP MLD to the second AP MLD can include the first and second contexts.

[0701] After the MLD roaming request frame is sent, a link can be established between the first non-AP STA and the second AP. After the link is established between the first non-AP STA and the second AP, the first context can be transmitted from the first AP MLD to the second AP MLD. After the first context is transmitted, the MLD roaming response frame can be received.

[0702] In this scenario, the first context includes static information for negotiation, and the second context may include dynamic information for negotiation. Similarly, the first and second contexts can be determined based on information about the context delivery level.

[0703] The first AP can perform the roaming preparation phase and the roaming execution phase with the first non-AP STA (the first non-AP STA can perform the roaming preparation phase and the roaming execution phase with the first AP).

[0704] During the roaming preparation phase, a link is established between the first non-AP STA and the second AP, and the first context can be transmitted.

[0705] During the roaming execution phase, the second context is transmitted, and roaming from the first AP to the second AP can be performed after the distribution system (DS) mapping is updated from the first AP MLD to the second AP MLD.

[0706] The first AP can receive a transition request frame from the first non-AP STA (the first non-AP STA can send a transition request frame to the first AP). The first AP can send a transition response frame to the first non-AP STA (the first non-AP STA can receive a transition response frame from the first AP).

[0707] After sending the transition request frame, the roaming execution phase can be performed. After the roaming execution phase is completed, the transition response frame can be received.

[0708] Additionally, the MLD roaming request frame may further include information about the context that the first non-AP STA expects to transmit or the context that the first non-AP STA does not expect to transmit. The MLD roaming response frame may further include information about whether the context requested to be transmitted via the MLD roaming request frame has actually been transmitted.

[0709] Based on the remaining packets in the queue of the first AP MLD before the context is transmitted, after all packets in the queue of the first AP MLD are sent to the first non-AP STA, the Distribution System (DS) mapping is updated from the first AP MLD to the second AP MLD, and roaming from the first AP to the second AP can be performed. Packets can be accumulated in the queue of the second AP MLD starting after the context is transmitted.

[0710] After the context transfer is completed (or even before), the second AP MLD can send a request frame for link addition to the first non-AP STA (the first non-AP STA can receive the request frame for link addition from the second AP MLD). Based on the added link being established between the first non-AP STA and the second AP MLD, the second AP MLD can send frames containing packets in its queue to the first non-AP STA via the added link (the first non-AP STA can receive frames containing packets in its queue from the second AP MLD via the added link). The first AP MLD can receive messages from the first non-AP STA requesting the removal of the link connected to the first AP MLD (the first non-AP STA can request the removal of the link connected to the first AP MLD).

[0711] Frames containing packets in a queue that includes a second APMLD can be received (or sent) based on the sequence number (SN) or packet number (PN) included in the context.

[0712] Roaming from the first AP to the second AP can be completed because all links connecting the first non-AP STA and the first AP MLD are removed.

[0713] MLD roaming request frames can be defined based on reconfigured multilink information elements (IEs). MLD roaming response frames can be defined based on basic multilink IEs.

[0714] The MLD roaming request frame may include a first public information field and a first link information field.

[0715] The first public information field may include first information indicating whether a roaming reason code exists. Based on the first information indicating whether a roaming reason code exists, the roaming reason code may be included in the first public information field. The first link information field may include second information indicating whether a roaming reason code exists. Based on the second information indicating whether a roaming reason code exists, the roaming reason code may be included in the first link information field.

[0716] The MLD roaming response frame may include a second common information field and a second link information field. The second common information field may include first information indicating the presence of a roaming reason code. Based on the first information indicating the presence of a roaming reason code, the roaming reason code may be included in the second common information field. The second link information field may include second information indicating the presence of a roaming reason code. Based on the second information indicating the presence of a roaming reason code, the roaming reason code may be included in the second link information field.

[0717] Information about the reason for roaming, based on the value of the roaming reason code, can be set as follows.

[0718] When the roaming reason code is set to 0, no reason needs to be specified to recommend roaming to the AP. When the roaming reason code is set to 1, the reason for recommending roaming to the AP could be excessive frame loss rate or poor condition. When the roaming reason code is set to 2, the reason for recommending roaming to the AP could be excessive latency for the current traffic flow. When the roaming reason code is set to 3, the reason for recommending roaming to the AP could be insufficient Quality of Service (QoS) capacity for the current traffic flow. When the roaming reason code is set to 4, the reason for recommending roaming to the AP could be the discovery of a better link.

[0719] Roaming reason code set to 5 indicates a reason for recommending roaming to the AP, such as discovering a better AP. Roaming reason code set to 6 indicates a reason for recommending roaming to the AP, such as receiving too many replay counter failures. Roaming reason code set to 7 indicates a reason for recommending roaming to the AP, such as receiving too many Data Message Integrity Code (MIC) failures. Roaming reason code set to 8 indicates a reason for recommending roaming to the AP, such as exceeding the maximum retransmission count. Roaming reason code set to 9 indicates a reason for recommending roaming to the AP, such as receiving too many broadcast disconnections. Roaming reason code set to 10 indicates a reason for recommending roaming to the AP, such as receiving too many broadcast deauthentications.

[0720] When the roaming reason code is set to 11, the reason for recommending roaming to the AP could be a failure of a previous roaming session. When the roaming reason code is set to 12, the reason for recommending roaming to the AP could be a Low Received Signal Strength Indication (RSSI). When the roaming reason code is set to 13, the reason for recommending roaming to the AP could be a change based on a received roaming request frame. When the roaming reason code is set to 14, the reason for recommending roaming to the AP could include a recommended roaming list. When the roaming reason codes are set to 15 through 255, the reasons for recommending roaming to the AP can be reserved.

[0721] Based on the completion of roaming from the first AP to the second AP, the first non-AP STA can receive downlink (DL) data from the second AP.

[0722] Figure 76 This is a flowchart illustrating the process of STA performing MLD roaming using context transfer according to this embodiment.

[0723] Figure 76 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 are backward compatible with the 802.11be system.

[0724] This embodiment proposes a method for selecting the context to be transmitted from the serving AP MLD to the target AP MLD based on information about the context transmission level during the exchange of roaming request frames and roaming response frames for MLD roaming. Specifically, this embodiment has the effect of preventing delays due to unnecessary context transmission by selectively transmitting context based on whether to perform renegotiation between the non-AP STA and the target AP MLD.

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

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

[0727] In step S7630, the first non-AP STA performs roaming from the first AP to the second AP based on the MLD roaming request frame and the MLD roaming response frame.

[0728] The first AP is attached to a first AP multi-link device (MLD), and the second AP is attached to a second AP MLD. The first AP MLD and the second AP MLD are included in a group that is capable of roaming.

[0729] The first AP can be referred to as the old AP (O_AP), the serving AP, or the current AP. The second AP can be referred to as the new AP (N_AP) or the target AP. The first AP MLD, which includes the first AP, can be referred to as the serving AP MLD. The second AP MLD, which includes the second AP, can be referred to as 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 without disconnection between the AP and the STA within the MLD.

[0730] A group that can roam 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 group that can roam, so roaming (or moving) from an AP in the first AP MLD to an AP in the second AP MLD is possible. APs in the first AP MLD are co-located. APs in the second AP MLD are also co-located.

[0731] MLD roaming request frames include information about the context delivery level.

[0732] The context for transmission from the first AP MLD to the second AP MLD is selected based on information about the context transmission level.

[0733] This embodiment proposes a method for selecting a context for proactively transmitting necessary information before a non-AP STA performs roaming to a target AP MLD. Specifically, this embodiment defines a context transmission level for the context and proposes a method for selecting the context required for roaming based on the context transmission level. This avoids delays caused by transmitting unnecessary context and allows only the necessary information to be transmitted, resulting in improved seamless roaming.

[0734] Context can be transferred from a first AP MLD to a second AP MLD based on an MLD roaming request frame. Specifically, the first AP MLD, the second AP MLD, and roaming groups can be connected to a distribution system (DS). After sending the MLD roaming request frame, the context can be transferred to the second AP MLD via the DS.

[0735] The context can be referred to as the set of parameters negotiated between the AP and STA (or between the non-AP MLD STA and the serving AP MLD). The DS can be the backbone network of a wireless LAN used to extend the wireless network by providing connectivity between different basic service sets (BSS).

[0736] Information about the context delivery level can be set in various ways.

[0737] As an example, information about the context delivery level can be set in a separate way.

[0738] For example, if the context transfer level information is set to 0, the context for transmission from the first AP MLD to the second AP MLD may not exist. Given that the context transfer level information is set to 0, since the context information required for roaming does not exist, active context transfer is not necessary.

[0739] Based on the information about the context transmission level being set to 1, the context transmitted from the first AP MLD to the second AP MLD can be a sequence number (SN) or a packet number (PN).

[0740] Based on the information about the context transfer level being set to 2, the context transferred from the first AP MLD to the second AP MLD can be the Block Ack (BA) protocol.

[0741] Based on the information about the context transmission level being set to 3, the context transmitted from the first AP MLD to the second AP MLD can be packet reordered.

[0742] Based on the information about the context transmission level being set to 4 to 15, the context transmitted from the first AP MLD to the second AP MLD can be preserved.

[0743] As another example, information about the context delivery level can be set using an accumulative method.

[0744] Based on the information about the context transmission level being set to 1, the context transmitted from the first AP MLD to the second AP MLD can be either SN or PN.

[0745] Based on the information about the context transmission level being set to 2, the context transmitted from the first AP MLD to the second AP MLD can be either SN or PN and BA protocols.

[0746] Based on the information about the context transmission level being set to 3, the context transmitted from the first AP MLD to the second AP MLD can be SN or PN, BA protocol, and packet reordering.

[0747] As another example, information about the context delivery level can be set using a bitmap method.

[0748] For example, based on a bitmap of 3 bits, with B0 set to 1, the context transmitted from the first AP MLD to the second AP MLD can be SN or PN; with B1 set to 1, the context transmitted from the first AP MLD to the second AP MLD can be BA protocol; and with B2 set to 1, the context transmitted from the first AP MLD to the second AP MLD can be group reordered.

[0749] The context transmitted from the first AP MLD to the second AP MLD can include the first and second contexts.

[0750] After the MLD roaming request frame is sent, a link can be established between the first non-AP STA and the second AP. After the link is established between the first non-AP STA and the second AP, the first context can be transmitted from the first AP MLD to the second AP MLD. After the first context is transmitted, the MLD roaming response frame can be received.

[0751] In this scenario, the first context includes static information for negotiation, and the second context may include dynamic information for negotiation. Similarly, the first and second contexts can be determined based on information about the context delivery level.

[0752] The first AP can perform the roaming preparation phase and the roaming execution phase with the first non-AP STA (the first non-AP STA can perform the roaming preparation phase and the roaming execution phase with the first AP).

[0753] During the roaming preparation phase, a link is established between the first non-AP STA and the second AP, and the first context can be transmitted.

[0754] During the roaming execution phase, the second context is transmitted, and roaming from the first AP to the second AP can be performed after the distribution system (DS) mapping is updated from the first AP MLD to the second AP MLD.

[0755] The first AP can receive a transition request frame from the first non-AP STA (the first non-AP STA can send a transition request frame to the first AP). The first AP can send a transition response frame to the first non-AP STA (the first non-AP STA can receive a transition response frame from the first AP).

[0756] After sending the transition request frame, the roaming execution phase can be performed. After the roaming execution phase is completed, the transition response frame can be received.

[0757] Additionally, the MLD roaming request frame may further include information about the context that the first non-AP STA expects to transmit or the context that the first non-AP STA does not expect to transmit. The MLD roaming response frame may further include information about whether the context requested to be transmitted via the MLD roaming request frame has actually been transmitted.

[0758] Based on the remaining packets in the queue of the first AP MLD before the context is transmitted, after all packets in the queue of the first AP MLD are sent to the first non-AP STA, the Distribution System (DS) mapping is updated from the first AP MLD to the second AP MLD, and roaming from the first AP to the second AP can be performed. Packets can be accumulated in the queue of the second AP MLD starting after the context is transmitted.

[0759] After the context transfer is completed (or even before), the second AP MLD can send a request frame for link addition to the first non-AP STA (the first non-AP STA can receive the request frame for link addition from the second AP MLD). Based on the added link being established between the first non-AP STA and the second AP MLD, the second AP MLD can send frames containing packets in its queue to the first non-AP STA via the added link (the first non-AP STA can receive frames containing packets in its queue from the second AP MLD via the added link). The first AP MLD can receive messages from the first non-AP STA requesting the removal of the link connected to the first AP MLD (the first non-AP STA can request the removal of the link connected to the first AP MLD).

[0760] Frames containing packets in a queue that includes a second APMLD can be received (or sent) based on the sequence number (SN) or packet number (PN) included in the context.

[0761] Roaming from the first AP to the second AP can be completed because all links connecting the first non-AP STA and the first AP MLD are removed.

[0762] MLD roaming request frames can be defined based on reconfigured multilink information elements (IEs). MLD roaming response frames can be defined based on basic multilink IEs.

[0763] The MLD roaming request frame may include a first common information field and a first link information field.

[0764] The first public information field may include first information indicating whether a roaming reason code exists. Based on the first information indicating whether a roaming reason code exists, the roaming reason code may be included in the first public information field. The first link information field may include second information indicating whether a roaming reason code exists. Based on the second information indicating whether a roaming reason code exists, the roaming reason code may be included in the first link information field.

[0765] The MLD roaming response frame may include a second common information field and a second link information field. The second common information field may include first information indicating the presence of a roaming reason code. Based on the first information indicating the presence of a roaming reason code, the roaming reason code may be included in the second common information field. The second link information field may include second information indicating the presence of a roaming reason code. Based on the second information indicating the presence of a roaming reason code, the roaming reason code may be included in the second link information field.

[0766] Information about the reason for roaming, based on the value of the roaming reason code, can be set as follows.

[0767] When the roaming reason code is set to 0, no reason needs to be specified to recommend roaming to the AP. When the roaming reason code is set to 1, the reason for recommending roaming to the AP could be excessive frame loss rate or poor condition. When the roaming reason code is set to 2, the reason for recommending roaming to the AP could be excessive latency for the current traffic flow. When the roaming reason code is set to 3, the reason for recommending roaming to the AP could be insufficient Quality of Service (QoS) capacity for the current traffic flow. When the roaming reason code is set to 4, the reason for recommending roaming to the AP could be the discovery of a better link.

[0768] Roaming reason code set to 5 indicates a reason for recommending roaming to the AP, such as discovering a better AP. Roaming reason code set to 6 indicates a reason for recommending roaming to the AP, such as receiving too many replay counter failures. Roaming reason code set to 7 indicates a reason for recommending roaming to the AP, such as receiving too many Data Message Integrity Code (MIC) failures. Roaming reason code set to 8 indicates a reason for recommending roaming to the AP, such as exceeding the maximum retransmission count. Roaming reason code set to 9 indicates a reason for recommending roaming to the AP, such as receiving too many broadcast disconnections. Roaming reason code set to 10 indicates a reason for recommending roaming to the AP, such as receiving too many broadcast deauthentications.

[0769] When the roaming reason code is set to 11, the reason for recommending roaming to the AP could be a failure of a previous roaming session. When the roaming reason code is set to 12, the reason for recommending roaming to the AP could be a Low Received Signal Strength Indication (RSSI). When the roaming reason code is set to 13, the reason for recommending roaming to the AP could be a change based on a received roaming request frame. When the roaming reason code is set to 14, the reason for recommending roaming to the AP could include a recommended roaming list. When the roaming reason codes are set to 15 through 255, the reasons for recommending roaming to the AP can be reserved.

[0770] Based on the completion of roaming from the first AP to the second AP, the first non-AP STA can receive downlink (DL) data from the second AP.

[0771] <Device Configuration>

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

[0773] The technical features of this disclosure can be implemented based on a computer-readable medium (CRM). For example, the CRM proposed by this disclosure includes at least one computer-readable medium comprising instructions executed by at least one processor.

[0774] The CRM can store instructions that perform operations including: sending a Multilink Device (MLD) roaming request frame to a first access point (first AP); receiving an MLD roaming response frame from the first AP; and performing roaming from the first AP to a second AP based on the MLD roaming request frame and the MLD roaming response. 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 can 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.

[0775] The aforementioned technical features in this specification are applicable to various applications or business models. For example, the aforementioned technical features can be applied to wireless communication in devices that support artificial intelligence (AI).

[0776] Artificial intelligence (AI) refers to the field of research concerning artificial intelligence or the methods used to create it, while machine learning refers to the field of research concerning the methods used to define and solve various problems within the field of AI. Machine learning is also defined as algorithms used to improve the performance of operations through stable experience.

[0777] Artificial neural networks (ANNs) are models used in machine learning and can refer to overall problem-solving models that include artificial neurons (nodes) forming a network through the combination of synapses. An artificial neural network can be defined by the pattern of connections between neurons in different layers, the learning process that updates model parameters, and the activation function that generates output values.

[0778] 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 the value of an activation function of the input signal received through synapses, weights, and biases.

[0779] Model parameters refer to the parameters determined through learning, including the weights of synaptic connections and the biases of neurons. Hyperparameters refer to the parameters that are set in a machine learning algorithm before learning, including the learning rate, number of iterations, mini-batch size, and initialization function.

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

[0781] Machine learning can be classified into supervised learning, unsupervised learning, and reinforcement learning.

[0782] Supervised learning refers to methods that use labels provided for training data to train an artificial neural network, where the labels instruct the network when to infer the correct answer (or result value) from the training data. Unsupervised learning refers to methods that train an artificial neural network without providing labels for the training data. Reinforcement learning refers to training methods used to train an agent defined in an environment to select actions or sequences of actions to maximize the cumulative reward in each state.

[0783] Machine learning that utilizes deep neural networks (DNNs) with multiple hidden layers, including artificial neural networks, is called deep learning, and deep learning is a part of machine learning. In the following text, machine learning is interpreted as including deep learning.

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

[0785] A robot can refer to a machine that automatically processes or operates a given task and possesses its own capabilities. Specifically, a robot that has the ability to recognize its environment and autonomously make judgments to perform operations can be called an intelligent robot.

[0786] Robots can be classified according to their purpose or field, such as industrial, medical, domestic, and military robots. A robot may include actuators or drives, such as motors, to perform various physical operations, such as moving the robot's joints. Additionally, mobile robots may include wheels, brakes, propellers, etc., in the driver's arm to move on the ground or fly in the air by a driver.

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

[0788] 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-world object images; and MR technology is a computer graphics technology that provides virtual objects that are mixed and combined with the real world.

[0789] MR technology is similar to AR technology because real and virtual objects are displayed together. However, while virtual objects are used to complement real objects in AR, they are treated as equals in MR.

[0790] XR technology can be applied to head-mounted displays (HMDs), head-up displays (HUDs), mobile phones, tablet PCs, laptops, desktop computers, TVs, digital signage, and more. Devices that use XR technology can be called XR devices.

[0791] The claims set forth in this specification can be combined in various ways. For example, the technical features of the method claims can be combined to implement a device, and the technical features of the device claims can be combined to be implemented by a method. Furthermore, the technical features of the method claims and the device claims can be combined to implement a device, and the technical features of the method claims and the device claims can be combined to be implemented by a method.

Claims

1. A method in a wireless local area network (WLAN) system, the method comprising: The first non-access point station (non-AP STA) sends a multi-link device (MLD) roaming request frame to the first AP; The first non-AP STA receives an MLD roaming response frame from the first AP; as well as Based on the MLD roaming request frame and the MLD roaming response frame, the first non-AP STA performs the roaming from the first AP to the second AP. Wherein, the first AP is attached to a first AP MLD, and the second AP is attached to a 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 information about the context delivery level, and The context for transmission from the first AP MLD to the second AP MLD is selected based on information about the context transmission level.

2. The method according to claim 1, in, Since the information regarding the context transmission level is set to 0, the context for transmission from the first AP MLD to the second AP MLD does not exist. Wherein, based on information about the context transmission level being set to 1, the context transmitted from the first AP MLD to the second AP MLD is a sequence number (SN) or a packet number (PN). Wherein, based on the information regarding the context transmission level being set to 2, the context transmitted from the first AP MLD to the second AP MLD is the Block Ack (BA) protocol. Wherein, based on the information regarding the context transmission level being set to 3, the context transmitted from the first AP MLD to the second AP MLD is packet reordering, and Wherein, based on the information about the context transmission level being set to 4 to 15, the context transmitted from the first AP MLD to the second AP MLD is preserved.

3. The method according to claim 2, in, The context transmitted from the first AP MLD to the second AP MLD includes a first context and a second context. Specifically, after the MLD roaming request frame is sent, a link is established between the first non-AP STA and the second AP. Specifically, after the link is established between the first non-AP STA and the second AP, the first context is transmitted from the first AP MLD to the second AP MLD. The MLD roaming response frame is received after the first context is transmitted. Wherein, the first context includes static information for negotiation, and the second context includes dynamic information for negotiation, and The first context and the second context are determined based on information about the context transmission level.

4. The method of claim 3, further comprising: The first non-AP STA and the first AP perform the roaming preparation phase and the roaming execution phase. During the roaming preparation phase, the link is established between the first non-AP STA and the second AP, and the first context is transmitted. During the roaming execution phase, the second context is transmitted, and the roaming from the first AP to the second AP is performed after the distribution system (DS) mapping is updated from the first AP MLD to the second AP MLD.

5. The method of claim 4, further comprising: The first non-AP STA sends a transition request frame to the first AP; as well as The first non-AP STA receives the transition response frame from the first AP. The roaming execution phase is performed after the transformation request frame is sent, and The transition response frame is received after the roaming execution phase is completed.

6. The method according to claim 1, in, The first AP MLD, the second AP MLD, and the roaming group are connected to the distribution system (DS), and After the MLD roaming request frame is sent, the context is transmitted to the second APMLD via the DS.

7. The method according to claim 1, in, The MLD roaming request frame is defined based on the reconfigured multi-link information element (IE), and The MLD roaming response frame is defined based on the basic multi-link IE.

8. The method according to claim 7, in, The MLD roaming request frame includes a first public information field and a first link information field. The first public information field includes first information indicating whether a roaming reason code exists. Specifically, based on the first information indicating whether the roaming reason code exists, the roaming reason code is included in the first public information field. The first link information field includes second information indicating whether the roaming reason code exists, and Specifically, based on the second information indicating whether the roaming reason code exists, the roaming reason code is included in the first link information field.

9. The method according to claim 7, in, The MLD roaming response frame includes a second common information field and a second link information field. The second public information field includes first information indicating whether a roaming reason code exists. Specifically, based on the first information indicating the presence of the roaming reason code, the roaming reason code is included in the second public information field. The second link information field includes second information indicating whether the roaming reason code exists, and Specifically, the roaming reason code is included in the second link information field based on the second information indicating whether the roaming reason code exists.

10. 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, operable to be coupled to the memory and the transceiver, wherein the processor is configured to: Send a Multi-Link Device (MLD) roaming request frame to the first AP; Receive an MLD roaming response frame from the first AP; and Based on the MLD roaming request frame and the MLD roaming response frame, roaming is performed from the first AP to the second AP. Wherein, the first AP is attached to a first AP MLD, and the second AP is attached to a 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 information about the context delivery level, and The context for transmission from the first AP MLD to the second AP MLD is selected based on information about the context transmission level.

11. 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-access point station (non-AP STA); as well as The first AP sends an MLD roaming response frame to the first non-AP STA. Specifically, based on the MLD roaming request frame and the MLD roaming response frame, roaming is performed from the first AP to the second AP. Wherein, the first AP is attached to a first AP MLD, and the second AP is attached to a 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 information about the context delivery level, and The context for transmission from the first AP MLD to the second AP MLD is selected based on information about the context transmission level.

12. The method according to claim 11, in, Since the information regarding the context transmission level is set to 0, the context for transmission from the first AP MLD to the second AP MLD does not exist. Wherein, based on information about the context transmission level being set to 1, the context transmitted from the first AP MLD to the second AP MLD is a sequence number (SN) or a packet number (PN). Wherein, based on the information regarding the context transmission level being set to 2, the context transmitted from the first AP MLD to the second AP MLD is the Block Ack (BA) protocol. Wherein, based on the information regarding the context transmission level being set to 3, the context transmitted from the first AP MLD to the second AP MLD is packet reordering, and Wherein, based on the information about the context transmission level being set to 4 to 15, the context transmitted from the first AP MLD to the second AP MLD is preserved.

13. The method according to claim 12, in, The context transmitted from the first AP MLD to the second AP MLD includes a first context and a second context. Specifically, after the MLD roaming request frame is sent, a link is established between the first non-AP STA and the second AP. Specifically, after the link is established between the first non-AP STA and the second AP, the first context is transmitted from the first AP MLD to the second AP MLD. The MLD roaming response frame is received after the first context is transmitted. Wherein, the first context includes static information for negotiation, and the second context includes dynamic information for negotiation, and The first context and the second context are determined based on information about the context transmission level.

14. The method of claim 13, further comprising: The roaming preparation phase and the roaming execution phase are performed by the first AP and the first non-AP STA. During the roaming preparation phase, the link is established between the first non-AP STA and the second AP, and the first context is transmitted. During the roaming execution phase, the second context is transmitted, and the roaming from the first AP to the second AP is performed after the distribution system (DS) mapping is updated from the first AP MLD to the second AP MLD.

15. The method of claim 14, further comprising: The first AP receives a transition request frame from the first non-AP STA; as well as The first AP sends a transition response frame to the first non-AP STA. The roaming execution phase is performed after the transformation request frame is sent, and The transition response frame is received after the roaming execution phase is completed.

16. The method according to claim 11, in, The first AP MLD, the second AP MLD, and the roaming group are connected to the distribution system (DS), and After the MLD roaming request frame is sent, the context is transmitted to the second APMLD via the DS.

17. The method according to claim 11, in, The MLD roaming request frame is defined based on the reconfigured multi-link information element (IE), and The MLD roaming response frame is defined based on the basic multi-link IE.

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, operable to be coupled to the memory and the transceiver, wherein the processor is configured to: Receive a multi-link device (MLD) roaming request frame from the first non-access point station (non-AP STA); and Send an MLD roaming response frame to the first non-AP STA. Specifically, based on the MLD roaming request frame and the MLD roaming response frame, roaming is performed from the first AP to the second AP. Wherein, the first AP is attached to a first AP MLD, and the second AP is attached to a 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 information about the context delivery level, and The context for transmission from the first AP MLD to the second AP MLD is selected based on information about the context transmission level.

19. A computer-readable medium including instructions that are executed by at least one processor and 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 Based on the MLD roaming request frame and the MLD roaming response frame, roaming is performed from the first AP to the second AP. in, The first AP is attached to a first AP MLD, and the second AP is attached to a 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 information about the context delivery level, and The context for transmission from the first AP MLD to the second AP MLD is selected based on information about the context transmission level.

20. A device in a wireless local area network (WLAN) system, the device comprising: Memory; as well as A processor, operable to be coupled to the memory, wherein the processor is configured to: 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 Based on the MLD roaming request frame and the MLD roaming response frame, roaming is performed from the first AP to the second AP. Wherein, the first AP is attached to a first AP MLD, and the second AP is attached to a 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 information about the context delivery level, and The context for transmission from the first AP MLD to the second AP MLD is selected based on information about the context transmission level.

Images