Method and device for defining time points of context transfer and DS mapping change in wireless LAN system

Abstract

Proposed are a method and device for defining time points of context transfer and DS mapping change in a wireless LAN system. Specifically, a non-AP STA belonging to a non-AP MLD transmits a roaming request frame to a first AP belonging to a first AP MLD. After the context is transferred from the first AP MLD to a second AP MLD, the non-AP STA receives a roaming response frame from the first AP. On the basis that the transfer of the context is performed before the DS mapping is changed from the first AP MLD to the second AP MLD, the context of packets in a queue of the first AP MLD is transferred until a time point at which the transfer of the context starts.

Description

Method and device for defining the timing of context transfer and DS mapping change in a wireless LAN system

[0001] This specification relates to a technique for defining a time point for context transfer and DS mapping change in a wireless LAN system, and more specifically, to a method and device for defining a time point for transferring a context from a Serving AP MLD to a Target AP MLD and a time point for changing a DS mapping, and for distinguishing between context transfer according to the order of the two time points and packets buffered in the queues of the Serving AP MLD and the Target AP MLD.

[0002] Wireless local area networks (WLANs) have been improved in various ways. For example, the IEEE 802.11ax standard proposed an improved communication environment using orthogonal frequency division multiple access (OFDMA) and downlink multi-user multiple input, multiple output (DL MU MIMO) techniques.

[0003] This specification proposes technical features that can be utilized in a new communications standard. For example, the new communications standard could be the Extreme High Throughput (EHT) standard, which is currently under discussion. The EHT standard could utilize newly proposed increased bandwidth, an improved PHY layer protocol data unit (PPDU) structure, improved sequences, and the Hybrid Automatic Repeat Request (HARQ) technique. The EHT standard could also be referred to as the IEEE 802.11be standard.

[0004] New wireless LAN standards may allow for an increased number of spatial streams. This may necessitate improvements to signaling techniques within the wireless LAN system to properly utilize these increased spatial streams.

[0005] This specification proposes a method and device for defining the timing of context transfer and DS mapping change in a wireless LAN system.

[0006] An example in this specification proposes a method for defining when context is passed and when DS mapping changes occur.

[0007] The present embodiment can be performed in a network environment that supports a next-generation wireless LAN system (UHR (Ultra High Reliability) wireless LAN system or next wi-fi). The next-generation wireless LAN system is a wireless LAN system that improves the 802.11be system and can satisfy backward compatibility with the 802.11be system.

[0008] This embodiment defines the time point at which a context is transferred from a Serving AP MLD to a Target AP MLD and the time point at which a DS mapping is changed, and proposes a method for distinguishing between context transfer according to the order of the two time points and packets buffered in the queues of the Serving AP MLD and the Target AP MLD.

[0009] A non-AP STA (station) belonging to a non-AP (non-access point) MLD (multi-link device) transmits a roaming request frame to the first AP belonging to the first AP MLD.

[0010] After the context is transferred from the first AP MLD to the second AP MLD, the non-AP STA receives a roaming response frame from the first AP.

[0011] Based on the fact that the context transfer is performed before the DS (Distribution System) mapping is changed from the first AP MLD to the second AP MLD, the context of the packet existing in the queue of the first AP MLD is transferred until the transfer of the context starts. After the DS mapping is changed, the context of the packet existing in the queue of the second AP MLD is set based on the context of the packet existing in the queue of the first AP MLD that has been transferred.

[0012] For example, the context of a packet existing in the queue of the first AP MLD to be transmitted at the time when the transmission of the context starts may be the last SN (Sequence Number) or the last PN (Packet Number). After the transmission of the context starts, but before the DS mapping is changed, based on the existence of an additional packet in the queue of the first AP MLD, the context of a packet existing in the queue of the second AP MLD after the DS mapping is changed can be distinguished from the additional packet existing in the queue of the first AP MLD based on the last SN or the last PN. That is, since a new packet buffered in the queue of the second AP MLD after the DS mapping is changed is set based on the last SN or the last PN of the packet buffered in the queue of the first AP MLD, there is an effect that an overlapping problem with the additional packet buffered in the queue of the first AP MLD before the DS mapping is changed can be solved.

[0013] Conversely, based on the fact that the change in the DS mapping is performed before the transmission of the context, the context existing in the queue of the first AP MLD until the time when the change in the DS mapping is initiated can be transmitted. After the DS mapping is changed, a new packet can be buffered in the queue of the second AP MLD.

[0014] In both cases, when the time of context transmission is earlier than the time of change in DS mapping and when the time of change in DS mapping is earlier than the time of context transmission, the context of the packet buffered in the queue of the first AP MLD is transmitted at the time when the transmission of the context begins.

[0015] That is, the present embodiment proposes a method of setting packets buffered in the queue of the Target AP MLD after the context is transferred and the DS mapping is changed, in order of the timing of transferring the context from the Serving AP MLD to the Target AP MLD and the timing of changing the DS mapping, to be distinguished from packets buffered in the queue of the Serving AP MLD.

[0016] According to the embodiment proposed in this specification, the problem of packets buffered in the queue of the Serving AP MLD and packets buffered in the queue of the Target AP MLD overlapping with each other depending on the time of context transfer and the time of change in DS mapping can be solved, thereby having the effect of efficiently performing MLD roaming.

[0017] Figure 1 illustrates an example of a transmitting device and / or a receiving device of the present specification.

[0018] Figure 2 is a conceptual diagram showing the structure of a wireless local area network (WLAN).

[0019] Figure 3 is a diagram illustrating a general link setup process.

[0020] Figure 4 illustrates one embodiment of a multi-link (ML).

[0021] FIG. 5 illustrates a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted / received by an STA of this specification.

[0022] Figure 6 is a diagram showing the layout of resource units (RUs) used for 20MHz PPDU.

[0023] Figure 7 is a diagram showing the layout of resource units (RUs) used for 40MHz PPDU.

[0024] Figure 8 is a diagram showing the layout of resource units (RUs) used for 80MHz PPDU.

[0025] Figure 9 shows the operation according to UL-MU.

[0026] Figure 10 shows an example of channels used / supported / defined within the 2.4 GHz band.

[0027] Figure 11 illustrates an example of channels used / supported / defined within the 5 GHz band.

[0028] Figure 12 illustrates an example of channels used / supported / defined within the 6 GHz band.

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

[0030] FIG. 14 illustrates a modified example of a transmitting device and / or a receiving device of the present specification.

[0031] Figure 15 illustrates an over-the-air (OTA) FT protocol in a Robust Security Network (RSN).

[0032] Figure 16 illustrates the high-level architecture for AP MLD.

[0033] Figure 17 illustrates an example of a high-level architecture for UHR AP MLD.

[0034] Figure 18 illustrates another example of a high-level architecture for UHR AP MLD.

[0035] Figure 19 illustrates another example of the High-level Architecture for UHR AP MLD.

[0036] Figure 20 illustrates an example of a high-level architecture in the case where there are only entities that are not MLD-based.

[0037] Figure 21 illustrates another example of a High-level Architecture in the case of entities that are not MLD-based.

[0038] Figure 22 illustrates an example of a Roaming Architecture in an AP MLD area.

[0039] Figure 23 shows an example of an RNR IE.

[0040] Figure 24 shows another example for the RNR IE.

[0041] Figure 25 shows another example for the RNR IE.

[0042] Figure 26 illustrates an example of the AP Roaming Recommendation enabled field and the Roaming Reason Code field in the Common Info field.

[0043] Figure 27 illustrates an example of the AP Roaming Recommendation enabled field in the Link Info field.

[0044] Figure 28 illustrates an example of the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0045] Figure 29 illustrates an example of the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0046] Figure 30 illustrates an example in which the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes a UHR AP MLD ID and an AP MLD ID.

[0047] Figure 31 illustrates an example in which an AP MLD ID is included in the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0048] Figure 32 illustrates an example in which the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes a UHR AP MLD ID and an AP MLD ID.

[0049] Figure 33 illustrates an example in which an AP MLD ID is included in the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0050] Fig. 34 illustrates another example in which the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes the UHR AP MLD ID and the AP MLD ID.

[0051] Figure 35 illustrates another example in which the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes an AP MLD ID.

[0052] Figure 36 illustrates an example in which a Temporary field is included in the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0053] Figure 37 illustrates an example in which a Temporary field is included in the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0054] Figure 38 illustrates another example in which a Temporary field is included in the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0055] Figure 39 illustrates an example in which the AP Removal Timer field is included in the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0056] Figure 40 illustrates an example of the Common Info field of the Basic Multi-link IE proposed in this embodiment.

[0057] Figure 41 illustrates an example of the Link Info field of the Basic Multi-link IE proposed in this embodiment.

[0058] Figure 42 illustrates an example of the Group Key Information field.

[0059] Figure 43 illustrates a procedure for determining whether an N_AP is capable of roaming using the Collocation Enabled field.

[0060] Figure 44 illustrates a procedure for determining whether an N_AP is capable of roaming using a Collocation ID.

[0061] Figure 45 illustrates the MLD Roaming procedure when a UHR AP MLD ID is entered in the Reconfiguration element.

[0062] Figure 46 illustrates the MLD Roaming procedure when the UHR AP MLD ID is not entered in the Reconfiguration element.

[0063] Figure 47 illustrates an example of a collocated AP set.

[0064] Figure 48 illustrates Example 1 for the MLD Roaming procedure.

[0065] Figure 49 shows the operation process of Example 1 for the MLD Roaming procedure.

[0066] Figure 50 illustrates Example 2 for the MLD Roaming procedure.

[0067] Figure 51 shows the operation process of Example 2 for the MLD Roaming procedure.

[0068] Figure 52 illustrates Example 3 for the MLD Roaming procedure.

[0069] Figure 53 shows the operation process of Example 3 for the MLD Roaming procedure.

[0070] Figure 54 illustrates Example 4 for the MLD Roaming procedure.

[0071] Figure 55 shows the operation process of examples 3 and 4 for the MLD Roaming procedure.

[0072] Figure 56 illustrates Example 5 for the MLD Roaming procedure.

[0073] Figure 57 illustrates Example 6 for the MLD Roaming procedure.

[0074] Figure 58 shows an example of MLD Roaming using TIM.

[0075] Figure 59 shows the operation process for the MLD Roaming procedure using TIM.

[0076] Figure 60 illustrates an example of the Add link process.

[0077] Figure 61 illustrates an example of the Add link process through a Roaming Request frame.

[0078] Figure 62 illustrates an example of the Delete link process.

[0079] Figure 63 shows an example of the process of setting a Delete Timer.

[0080] Figure 64 illustrates the process of transmitting and receiving a frame for adding a link.

[0081] Figure 65 illustrates the process of transmitting and receiving a frame for adding a link through a Roaming Request frame.

[0082] Figure 66 illustrates the process of transmitting and receiving a frame for deleting a link.

[0083] Figure 67 illustrates the process of transmitting and receiving a frame for Delete link using a delete timer.

[0084] Figure 68 illustrates a first embodiment of a process for setting a Delete Timer.

[0085] Figure 69 illustrates a second embodiment of the process for setting a Delete Timer.

[0086] Figure 70 illustrates a process for notifying Link Delete in an unsolicited manner by transmitting an Add Link Response.

[0087] Figure 71 illustrates a process for notifying Link Delete in an unsolicited manner by transmitting a Roaming Response frame.

[0088] Figure 72 illustrates an example of a Roaming Procedure using Context transfer (only entities exist).

[0089] Figure 73 illustrates an example of a roaming process using context transfer.

[0090] Figure 74 illustrates another example of a roaming process using context transfer.

[0091] Figure 75 illustrates an example of Context Transfer Confirmation when a Non-AP MLD STA makes a Roaming Request first.

[0092] Figure 76 is a procedure flow diagram showing the operation of Context Transfer Confirmation when a Non-AP MLD STA makes a Roaming Request first.

[0093] Figure 77 illustrates an example of Context Transfer Confirmation when AP MLD makes a Roaming Request first.

[0094] Figure 78 is a procedure flow diagram showing the operation of Context Transfer Confirmation when AP MLD first makes a Roaming Request.

[0095] Figure 79 illustrates an embodiment 1 of a Seamless Roaming process using context transfer.

[0096] Figure 80 illustrates a flowchart of Embodiment 1 of a Seamless Roaming process using context transfer.

[0097] Figure 81 illustrates an embodiment 2 of a Seamless Roaming process using context transfer.

[0098] Figure 82 illustrates a flowchart of Embodiment 2 of a Seamless Roaming process using context transfer.

[0099] Figure 83 illustrates an example of a Seamless Roaming process using context transfer (Add Link All at Once).

[0100] Figure 84 illustrates a procedure diagram of an example of a Seamless Roaming process using context transfer (Add Link All at Once).

[0101] Figure 85 illustrates another example of a Seamless Roaming process using context transfer (Delete Link All at Once).

[0102] Figure 86 illustrates a procedure diagram of another example of a Seamless Roaming process using context transfer (Delete Link All at Once).

[0103] Figure 87 illustrates an example in which a link between a non-AP STA and two AP MLDs uses the same channel during a seamless roaming process.

[0104] Figure 88 illustrates an example in which a link between a non-AP STA and two AP MLDs uses the same channel during a seamless roaming process.

[0105] Figure 89 illustrates another example where a link between a non-AP STA and two AP MLDs uses the same channel during a Seamless Roaming process.

[0106] Figure 90 illustrates an example of the Context Transfer and DS Mapping Change sequence.

[0107] Figure 91 illustrates an example of DS Mapping Change and Update.

[0108] Figure 92 illustrates an example 1 of a procedure diagram for DS Mapping Change and Update.

[0109] Figure 93 illustrates an example 2 of a procedure diagram for DS Mapping Change and Update.

[0110] Figure 94 illustrates an example 3 of a procedure diagram for DS Mapping Change and Update.

[0111] Figure 95 illustrates an example 4 of a procedure diagram for DS Mapping Change and Update.

[0112] Figure 96 is a flowchart illustrating the operation of a transmitting device according to the present embodiment.

[0113] Figure 97 is a flowchart illustrating the operation of a receiving device according to the present embodiment.

[0114] Figure 98 is a flowchart illustrating a procedure in which AP MLD defines the timing of context transfer and DS mapping change in MLD roaming according to the present embodiment.

[0115] Figure 99 is a flowchart illustrating a procedure for defining a time point for transfer of context and DS mapping change by a non-AP MLD in MLD roaming according to the present embodiment.

[0116] In this specification, “A or B” can mean “only A,” “only B,” or “both A and B.” In other words, “A or B” in this specification can be interpreted as “A and / or B.” For example, “A, B or C” in this specification can mean “only A,” “only B,” “only C,” or “any combination of A, B, and C.”

[0117] As used herein, a slash ( / ) or a comma can mean "and / or." For example, "A / B" can mean "and / or B." Accordingly, "A / B" can mean "only A," "only B," or "both A and B." For example, "A, B, C" can mean "A, B, or C."

[0118] In this specification, “at least one of A and B” can mean “only A,” “only B,” or “both A and B.” Additionally, in this specification, the expressions “at least one of A or B” or “at least one of A and / or B” can be interpreted identically to “at least one of A and B.”

[0119] In addition, parentheses used in this specification may mean “for example.” Specifically, when “control information (UHR-Signal field)” is indicated, the “UHR-Signal field” may be suggested as an example of “control information.” In other words, the “control information” in this specification is not limited to the “UHR-Signal field,” and the “UHR-Signal field” may be suggested as an example of “control information.” In addition, even when indicated as “control information (UHR-Signal field),” the “UHR-Signal field” may be suggested as an example of “control information.”

[0120] Additionally, as used herein, “a / an” can mean “at least one” or “one or more.” Additionally, terms ending in “(s)” can mean “at least one” or “one or more.”

[0121] Additionally, the expressions “based on” or “on the basis of” or “according to” used herein mean “based at least in part on” and not “based solely on.”

[0122] Technical features individually described in a single drawing in this specification may be implemented individually or simultaneously.

[0123] The following examples of this specification can be applied to various wireless communication systems. For example, the following examples of this specification can be applied to wireless local area network (WLAN) systems. For example, the following examples of this specification can be applied to the IEEE 802.11a / g / n / ac / ax / be / bn standards. In addition, the examples of this specification can be applied to the Ultra High Reliability (UHR) standard or the next-generation wireless LAN standard that enhances IEEE 802.11bn. In addition, the examples of this specification can be applied to mobile communication systems. For example, the following examples of this specification can be applied to mobile communication systems based on the Long Term Evolution (LTE) and its evolution based on the 3rd Generation Partnership Project (3GPP) standard.

[0124] In order to explain the technical features of this specification, the technical features to which this specification can be applied are described below.

[0125] Figure 1 illustrates an example of a transmitting device and / or a receiving device of the present specification.

[0126] An example of FIG. 1 can perform various technical features described below. FIG. 1 relates to at least one STA (station). For example, the STA (110, 120) of the present specification may also be referred to by various names such as a mobile terminal, a wireless device, a Wireless Transmit / Receive Unit (WTRU), a User Equipment (UE), a Mobile Station (MS), a Mobile Subscriber Unit, or simply a user. The STA (110, 120) of the present specification may also be referred to by various names such as a network, a base station, a Node-B, an access point (AP), a repeater, a router, a relay, etc. The STA (110, 120) of the present specification may also be referred to by various names such as a receiving apparatus, a transmitting apparatus, a receiving STA, a transmitting STA, a receiving device, a transmitting device, etc.

[0127] For example, STA (110, 120) may perform the role of an AP (access point) or a non-AP role. That is, STA (110, 120) of the present specification may perform the functions of an AP and / or a non-AP. In the present specification, AP may also be indicated as an AP STA.

[0128] The STA (110, 120) of this specification can support various communication standards other than the IEEE 802.11 standard. For example, it can support communication standards according to the 3GPP standard (e.g., LTE, LTE-A, 5G NR standard). In addition, the STA of this specification can be implemented in various devices such as mobile phones, vehicles, and personal computers. In addition, the STA of this specification can support communication for various communication services such as voice calls, video calls, data communications, and autonomous driving (Self-Driving, Autonomous-Driving).

[0129] In this specification, STA (110, 120) may include a medium access control (MAC) and a physical layer interface for a wireless medium that follow the provisions of the IEEE 802.11 standard.

[0130] Based on the sub-drawing (a) of Fig. 1, STA (110, 120) is described as follows.

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

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

[0133] For example, the first STA (110) can perform the intended operation of the AP. For example, the processor (111) of the AP can receive a signal through the transceiver (113), process the received signal, generate a transmission signal, and perform control for signal transmission. The memory (112) of the AP can store a signal received through the transceiver (113) (i.e., a reception signal) and store a signal to be transmitted through the transceiver (i.e., a transmission signal).

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

[0135] For example, the processor (121) of the Non-AP STA can receive a signal through the transceiver (123), process the received signal, generate a transmission signal, and perform control for signal transmission. The memory (122) of the Non-AP STA can store a signal received through the transceiver (123) (i.e., a reception signal) and store a signal to be transmitted through the transceiver (i.e., a transmission signal).

[0136] For example, in the specification below, the operation of a device indicated as AP may be performed in the first STA (110) or the second STA (120). For example, if the first STA (110) is an AP, the operation of the device indicated as AP may be controlled by the processor (111) of the first STA (110), and a related signal may be transmitted or received through a transceiver (113) controlled by the processor (111) of the first STA (110). In addition, control information related to the operation of the AP or a transmission / reception signal of the AP may be stored in the memory (112) of the first STA (110). In addition, when the second STA (110) is an AP, the operation of the device indicated as an AP is controlled by the processor (121) of the second STA (120), and a related signal can be transmitted or received through a transceiver (123) controlled by the processor (121) of the second STA (120). In addition, control information related to the operation of the AP or the transmission / reception signal of the AP can be stored in the memory (122) of the second STA (110).

[0137] For example, in the specification below, the operation of a device indicated as a non-AP (or User-STA) may be performed in the 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 may be controlled by the processor (121) of the second STA (120), and a related signal may be transmitted or received through a transceiver (123) controlled by the processor (121) of the second STA (120). In addition, control information related to the operation of the non-AP or the transmission / reception signal of the AP may 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 a device indicated as a non-AP is controlled by the processor (111) of the first STA (110), and a related signal may be transmitted or received through a transceiver (113) controlled by the processor (111) of the first STA (120). In addition, control information related to the operation of the non-AP or the transmission / reception signal of the AP may be stored in the memory (112) of the first STA (110).

[0138] In the following specification, devices called (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 refer to the STA (110, 120) of FIG. 1. For example, devices indicated 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. without specific drawing symbols may also refer to the STA (110, 120) of FIG. 1. For example, in the example below, the operation of various STAs transmitting and receiving signals (e.g., PPDUs) may be performed by the transceivers (113, 123) of FIG. 1. In addition, in the example below, the operation of various STAs generating transmission and reception signals or performing data processing or calculations in advance for transmission and reception signals may be performed by the processors (111, 121) of FIG. 1.For example, an example of an operation that generates a transmission / reception signal or performs data processing or operation in advance for a transmission / reception signal may include 1) an operation of determining / obtaining / configuring / computing / decoding / encoding bit information of a subfield (SIG, STF, LTF, Data) field included in a PPDU, 2) an operation of determining / configuring / obtaining time resources or frequency resources (e.g., subcarrier resources) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 3) an operation of determining / configuring / obtaining a specific sequence (e.g., a pilot sequence, an STF / LTF sequence, an extra sequence applied to SIG) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 4) a power control operation and / or a power saving operation applied to an STA, 5) an operation related to determining / obtaining / configuring / computing / decoding / encoding an ACK signal, etc. Additionally, in the examples below, various information (e.g., information related to fields / subfields / control fields / parameters / power, etc.) used by various STAs for determining / acquiring / configuring / computing / decoding / encoding transmission / reception signals can be stored in the memory (112, 122) of FIG. 1.

[0139] The device / STA of the sub-drawing (a) of the above-described FIG. 1 can be modified as in the sub-drawing (b) of FIG. 1. Hereinafter, the STA (110, 120) of the present specification will be described based on the sub-drawing (b) of FIG. 1.

[0140] For example, the transceiver (113, 123) illustrated in sub-drawing (b) of FIG. 1 may perform the same function as the transceiver illustrated in sub-drawing (a) of FIG. 1 described above. For example, the processing chip (114, 124) illustrated in sub-drawing (b) of FIG. 1 may include a processor (111, 121) and a memory (112, 122). The processor (111, 121) and the memory (112, 122) illustrated in sub-drawing (b) of FIG. 1 may perform the same function as the processor (111, 121) and the memory (112, 122) illustrated in sub-drawing (a) of FIG. 1 described above.

[0141] The mobile terminal, wireless device, Wireless Transmit / Receive Unit (WTRU), User Equipment (UE), Mobile Station (MS), Mobile Subscriber Unit, user, user STA, network, Base Station, Node-B, Access Point (AP), repeater, router, relay, receiving device, transmitting device, receiving STA, transmitting STA, receiving Device, transmitting Device, receiving Apparatus, and / or transmitting Apparatus described below may refer to the STA (110, 120) illustrated in the sub-drawings (a) / (b) of FIG. 1, or may refer to the processing chip (114, 124) illustrated in the sub-drawing (b) of FIG. 1. That is, the technical feature of the present specification may be performed in the STA (110, 120) illustrated in the sub-drawings (a) / (b) of FIG. 1, or may be performed only in the processing chip (114, 124) illustrated in the sub-drawings (b) of FIG. 1. For example, the technical feature that the transmitting STA transmits a control signal may be understood as a technical feature that the control signal generated in the processor (111, 121) illustrated in the sub-drawings (a) / (b) of FIG. 1 is transmitted through the transceiver (113, 123) illustrated in the sub-drawings (a) / (b) of FIG. 1. Alternatively, the technical feature that the transmitting STA transmits a control signal may be understood as a technical feature that the control signal to be transmitted to the transceiver (113, 123) is generated in the processing chip (114, 124) illustrated in the sub-drawings (b) of FIG. 1.

[0142] For example, the technical feature of a receiving STA receiving a control signal can be understood as a technical feature of a control signal being received by a transceiver (113, 123) illustrated in sub-drawing (a) of FIG. 1. Alternatively, the technical feature of a receiving STA receiving a control signal can be understood as a technical feature of a control signal received by a transceiver (113, 123) illustrated in sub-drawing (a) of FIG. 1 being acquired by a processor (111, 121) illustrated in sub-drawing (a) of FIG. 1. Alternatively, the technical feature of a receiving STA receiving a control signal can be understood as a technical feature of a control signal received by a transceiver (113, 123) illustrated in sub-drawing (b) of FIG. 1 being acquired by a processing chip (114, 124) illustrated in sub-drawing (b) of FIG.

[0143] Referring to the sub-drawing (b) of FIG. 1, software code (115, 125) may be included in the memory (112, 122). The software code (115, 125) may include instructions that control the operation of the processor (111, 121). The software code (115, 125) may be included in various programming languages.

[0144] The processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include an application-specific integrated circuit (ASIC), another chipset, a logic circuit, and / or a data processing device. The processor may be an application processor (AP). For example, the processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modem (modulator and demodulator). For example, the processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may be a SNAPDRAGON™ series processor manufactured by Qualcomm®, an EXYNOSTM series processor manufactured by Samsung®, an A series processor manufactured by Apple®, a HELIO™ series processor manufactured by MediaTek®, an ATOM™ series processor manufactured by INTEL®, or an enhanced processor thereof.

[0145] In this specification, uplink may mean a link for communication from a non-AP STA to an AP STA, and uplink PPDU / packet / signal, etc. may be transmitted through the uplink. In addition, in this specification, downlink may mean a link for communication from an AP STA to a non-AP STA, and downlink PPDU / packet / signal, etc. may be transmitted through the downlink.

[0146] Figure 2 is a conceptual diagram showing the structure of a wireless local area network (WLAN).

[0147] The upper part of Figure 2 shows the structure of the infrastructure BSS (basic service set) of IEEE (institute of electrical and electronic engineers) 802.11.

[0148] The upper part of Figure 2 shows the structure of the infrastructure BSS (basic service set) of IEEE (institute of electrical and electronic engineers) 802.11.

[0149] Referring to the top of FIG. 2, the wireless LAN system may include one or more infrastructure BSSs (200, 205) (hereinafter, BSS). The BSSs (200, 205) are a collection of APs and STAs, such as an access point (AP) 225 and a station (STA1, 200-1), that have successfully synchronized and can communicate with each other, and are not a concept that designates a specific area. The BSS (205) may also include one or more STAs (205-1, 205-2) that can be associated with one AP (230).

[0150] A BSS may include at least one STA, an AP (225, 230) providing a distribution service, and a distribution system (DS, 210) connecting multiple APs.

[0151] A distributed system (210) can connect multiple BSSs (200, 205) to implement an extended service set (ESS, 240). An ESS (240) can be used as a term to indicate a network formed by connecting one or more APs through the distributed system (210). APs included in a single ESS (240) can have the same SSID (service set identification).

[0152] The portal (portal, 220) can act as a bridge to connect a wireless LAN network (IEEE 802.11) to another network (e.g., 802.X).

[0153] In a BSS such as the upper part of Fig. 2, a network between APs (225, 230) and a network between APs (225, 230) and STAs (200-1, 205-1, 205-2) can be implemented. However, it may also be possible to establish a network and perform communication between STAs without an AP (225, 230). A network that establishes a network and performs communication between STAs without an AP (225, 230) is defined as an ad-hoc network or an independent basic service set (IBSS).

[0154] The bottom of Figure 2 is a conceptual diagram showing IBSS.

[0155] Referring to the bottom of Fig. 2, the IBSS is a BSS that operates in ad-hoc mode. Since the IBSS does not include an AP, there is no centralized management entity. That is, in the IBSS, the STAs (250-1, 250-2, 250-3, 255-4, 255-5) are managed in a distributed manner. In the IBSS, all STAs (250-1, 250-2, 250-3, 255-4, 255-5) can be mobile STAs, and access to the distributed system is not permitted, forming a self-contained network.

[0156] Figure 3 is a diagram illustrating a general link setup process.

[0157] In step S310, the STA may perform a network discovery operation. This network discovery operation may include scanning by the STA. That is, for the STA to access the network, it must find a network it can join. Before joining a wireless network, the STA must identify compatible networks. The process of identifying networks in a specific area is called scanning. Scanning methods include active scanning and passive scanning.

[0158] Figure 3 illustrates a network discovery operation that includes an active scanning process as an example. In active scanning, an STA performing scanning transmits a probe request frame to discover which APs exist in the vicinity while moving between channels and waits for a response. A responder transmits a probe response frame to the STA that transmitted the probe request frame in response to the probe request frame. Here, the responder may be the STA that last transmitted a beacon frame in the BSS of the channel being scanned. In a BSS, the AP transmits the beacon frame, so the AP becomes the responder. In an IBSS, the STAs within the IBSS take turns transmitting beacon frames, so the responder is not constant. For example, an STA that transmits a probe request frame on channel 1 and receives a probe response frame on channel 1 can store BSS-related information included in the received probe response frame and move to the next channel (e.g., channel 2) to perform scanning (i.e., transmitting and receiving probe requests / responses on channel 2) in the same manner.

[0159] Although not shown in the example of FIG. 3, the scanning operation can also be performed in a passive scanning manner. An STA performing scanning based on passive scanning can wait for a beacon frame while moving between channels. A beacon frame is one of the management frames in IEEE 802.11. It announces the presence of a wireless network and is periodically transmitted so that the scanning STA can find the wireless network and participate in the wireless network. In the BSS, the AP periodically transmits the beacon frame, and in the IBSS, the STAs within the IBSS take turns transmitting the beacon frame. When the scanning STA receives a beacon frame, it stores the information about the BSS included in the beacon frame and moves to another channel, recording the beacon frame information on each channel. An STA that receives a beacon frame can store the BSS-related information included in the received beacon frame, move to the next channel, and perform scanning on the next channel in the same manner.

[0160] An STA that discovers a network can perform an authentication process through step S320. This authentication process may be referred to as the first authentication process to clearly distinguish it from the security setup operation of step S340 described below. The authentication process of S320 may include a process in which the STA transmits an authentication request frame to the AP, and the AP responds by transmitting an authentication response frame to the STA. The authentication frame used for the authentication request / response corresponds to a management frame.

[0161] The authentication frame may include information such as an authentication algorithm number, an authentication transaction sequence number, a status code, a challenge text, a Robust Security Network (RSN), and a Finite Cyclic Group.

[0162] An STA can transmit an authentication request frame to an AP. The AP can determine whether to grant authentication to the STA based on the information contained in the received authentication request frame. The AP can provide the result of the authentication process to the STA via an authentication response frame.

[0163] A successfully authenticated STA may perform an association process based on step S330. The association process includes a process in which the STA transmits an association request frame to the AP, and the AP transmits an association response frame to the STA in response. For example, the association request frame may include information related to various capabilities, such as a beacon listen interval, a service set identifier (SSID), supported rates, supported channels, RSN, mobility domain, supported operating classes, a Traffic Indication Map Broadcast request, and interworking service capabilities. For example, the association response frame may contain information related to various capabilities, status codes, Association ID (AID), supported rates, Enhanced Distributed Channel Access (EDCA) parameter sets, Received Channel Power Indicator (RCPI), Received Signal to Noise Indicator (RSNI), mobility domains, timeout interval (association comeback time), overlapping BSS scan parameters, TIM broadcast response, QoS maps, etc.

[0164] In step S340, the STA may perform a security setup process. The security setup process of step S340 may include, for example, a process of setting up a private key through a four-way handshaking using an Extensible Authentication Protocol over LAN (EAPOL) frame.

[0165] Figure 4 illustrates one embodiment of a multi-link (ML).

[0166] As illustrated in FIG. 4, multiple multi-link devices (MLDs) can communicate over a remote link. The MLDs can be categorized into AP MLDs including multiple AP STAs and non-AP MLDs including multiple non-AP STAs. That is, the AP MLD can include affiliated APs (i.e., AP STAs), and the non-AP MLD can include affiliated STAs (i.e., non-AP STAs, or user-STAs).

[0167] A multilink may include a first link and a second link, and different channels / subchannels / frequency resources may be allocated to the first and second links. The first and second multilinks may be identified through a link ID of 4 bits (or other n bits). The first and second links may be configured in the same 2.4 GHz, 5 GHz, or 6 GHz band. Alternatively, the first link and the second link may be configured in different bands.

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

[0169] In the example of FIG. 4, AP1 may initiate a multi-link setup procedure (ML setup procedure) by transmitting an Association Request frame to non-AP STA1. In the example of FIG. 4, non-AP STA1 may transmit an Association Response frame in response to the Association Request frame. Each AP (e.g., AP1 / 2 / 3) illustrated in FIG. 4 may be identical to the AP illustrated in FIG. 1 and / or FIG. 2, and each non-AP (e.g., non-AP1 / 2 / 3) illustrated in FIG. 4 may be identical to the STA (i.e., user-STA or non-AP STA) illustrated in FIG. 1 and / or FIG. 2.

[0170] The specific features of this specification are not limited to the specific features of FIG. 4. That is, the number of links can be defined in various ways, and multiple links can be defined in various ways within at least one band.

[0171] FIG. 5 illustrates a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted / received by an STA of this specification.

[0172] The STA (e.g., AP STA, non-AP STA, AP MLD, non-AP MLD) of the present specification can transmit and / or receive the PPDU of FIG. 5. The PPDU described in the present specification may have, for example, the structure of FIG. 5. In addition, the PPDU described in the present specification may be called by various names such as a transmission PPDU, a reception PPDU, a first type PPDU, or an Nth type PPDU, etc. The PPDU described in the present specification can be used in a WLAN system defined according to IEEE 802.11bn and / or a next-generation WLAN system that improves IEEE 802.11bn.

[0173] The PPDU of FIG. 5 may be related to various PPDU types used in a UHR system. For example, the example of FIG. 5 may be used for at least one of a single-user (SU) mode / type / transmission, a multi-user (MU) mode / type / transmission, and a null data packet (NDP) mode / type / transmission related to channel sounding. For example, if the example of FIG. 5 is related to NDP, the Data field illustrated may be omitted. If the PPDU of FIG. 5 is used for a trigger-based (TB) mode, the UHR-SIG of FIG. 5 may be omitted. In other words, an STA that has received a trigger frame for UL-MU (Uplink-MU) communication may transmit a PPDU with the UHR-SIG omitted in the example of FIG. 5.

[0174] In FIG. 5, L-STF or UHR-LTF may be called a preamble or physical preamble, and may be generated / transmitted / received / acquired / decoded in the physical layer (included in the transmitting / receiving STA).

[0175] Each block illustrated in Fig. 5 may be called a field / subfield / signal, etc. The names of these fields / subfields / signals may be, as illustrated in Fig. 5, L-STF (legacy short training field), L-LTF (legacy long training field), L-SIG (legacy signal), RL-SIG (repeated L-SIG), U-SIG (Universal Signal), UHR-SIG (UHR-signal), etc.

[0176] The subcarrier spacing of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields in FIG. 5 may be set to 312.5 kHz, and the subcarrier spacing of the UHR-STF, UHR-LTF, and Data fields may be set to 78.125 kHz. That is, the tone index (or subcarrier index) of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields may be expressed in units of 312.5 kHz, and the tone index (or subcarrier index) of the UHR-STF, UHR-LTF, and Data fields may be expressed in units of 78.125 kHz.

[0177] In the PPDU of Fig. 5, L-LTF and L-STF may be identical to conventional fields (e.g., non-HT LTF and non-HT STF defined in conventional WLAN standards).

[0178] The L-SIG field of FIG. 5 may include, for example, 24 bits of bit information. For example, the 24 bits of information may include a 4 bit Rate field, a 1 bit Reserved bit, a 12 bit Length field, a 1 bit Parity bit, and a 6 bit Tail bit. For example, the 12 bit Length field may include information about the length or time duration of the PPDU. For example, the value of the 12 bit Length field may be determined based on the type of the PPDU. For example, if the PPDU is a non-HT (non-High Throughput), HT (High Throughput), VHT (Very High Throughput) PPDU, or an EHT (extremely high throughput) PPDU or UHR PPDU, the value of the Length field may be determined as a multiple of 3. For example, if the PPDU is a HE PPDU, the value of the Length field may be determined as "a multiple of 3 + 1" or "a multiple of 3 + 2". In other words, for non-HT, HT, VHT PPDU, EHT PPDU, UHR PPDU, the value of the Length field can be determined as a multiple of 3, and for HE (High-Efficiency) PPDU, the value of the Length field can be determined as "a multiple of 3 + 1" or "a multiple of 3 + 2". In other words, the Length field in an UHR PPDU is set to a value satisfying the condition that the remainder is zero when LENGTH is divided by 3.

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

[0180] For example, (non-AP and AP) STA can generate RL-SIG, which is generated in the same manner as L-SIG. BPSK modulation can be applied to RL-SIG. Receiving (non-AP and AP) STA can determine whether the received PPDU is a HE PPDU, EHT PPDU, or UHR PPDU based on the presence of RL-SIG. In other words, if RL-SIG is present, receiving (non-AP and AP) STA can determine whether the received PPDU is one of HE PPDU, EHT PPDU, or UHR PPDU. In other words, if RL-SIG is not present, receiving (non-AP and AP) STA can determine whether the received PPDU is one of non-HT PPDU, HT PPDU, or VHT PPDU. In other words, the RL-SIG field is a repeat of the L-SIG field and is used to differentiate an UHR PPDU from a non-HT PPDU, HT PPDU, and VHT PPDU.

[0181] After the RL-SIG in Fig. 5, a U-SIG (Universal SIG) may be inserted. The U-SIG may be called by various names such as the first SIG field, the first SIG, the first type SIG, the control signal, the control signal field, the first (type) control signal, the common control field, and the common control signal.

[0182] A U-SIG can contain N bits of information and can include information for identifying the type of EHT PPDU. For example, a U-SIG can be formed based on two symbols (e.g., two consecutive OFDM symbols). Each symbol (e.g., an OFDM symbol) for a U-SIG can have a duration of 4 microseconds. Each symbol of a U-SIG can be used to transmit 26 bits of information. For example, each symbol of a U-SIG can be transmitted and received based on 52 data tones and 4 pilot tones.

[0183] For example, A bit information (e.g., 52 uncoded bits) can be transmitted through U-SIG, and the first symbol of U-SIG can transmit the first X bits of information (e.g., 26 uncoded bits) out of the total A bit information, and the second symbol of U-SIG can transmit the remaining Y bits of information (e.g., 26 uncoded bits) out of the total A bit information. For example, the transmitting STA can obtain 26 uncoded bits included in each U-SIG symbol. The transmitting STA can perform convolutional encoding (i.e., BCC encoding) based on a rate of R=1 / 2 to generate 52 coded bits, and 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 allocated to each U-SIG symbol. A single U-SIG symbol can be transmitted based on 56 tones (subcarriers) from subcarrier index -28 to subcarrier index +28, excluding DC index 0. The 52 BPSK symbols generated by the transmitting STA can be transmitted based on the remaining tones (subcarriers) excluding the pilot tones -21, -7, +7, and +21.

[0184] For example, A bit information (e.g., 52 uncoded bits) transmitted by U-SIG may include a CRC field (e.g., a 4-bit long field) and a tail field (e.g., a 6-bit long field). The CRC field and the tail field may be transmitted through the second symbol of the U-SIG. The CRC field may be generated based on 26 bits allocated to the first symbol of the U-SIG and the remaining 16 bits excluding the CRC / tail field within the second symbol, and may be generated based on a conventional CRC calculation algorithm. In addition, the tail field may be used to terminate the trellis of the convolutional decoder and may be set to, for example, "000000".

[0185] The A bit information (e.g., 52 uncoded bits) transmitted by the U-SIG (or U-SIG field) can be divided into version-independent bits and version-dependent bits. For example, the size of the version-independent bits can be fixed or variable. For example, the version-independent bits can be assigned only to the first symbol of the U-SIG, or the version-independent bits can be assigned to both the first symbol and the second symbol of the U-SIG. For example, the version-independent bits and the version-dependent bits can be called by various names, such as the first control bit and the second control bit.

[0186] For example, the version-independent bits of the U-SIG may include a 3-bit PHY version identifier. For example, the 3-bit PHY version identifier may include information related to the PHY version of the transmitted and received PPDU. For example, a first value (e.g., a value of 000) of the 3-bit PHY version identifier may indicate that the transmitted and received PPDU is an EHT PPDU. In addition, a second value (e.g., a value of 001) of the 3-bit PHY version identifier may indicate that the transmitted and received PPDU is an UHR PPDU.

[0187] In other words, when the (AP / non-AP) STA transmits an EHT PPDU, it can set the 3-bit PHY version identifier to the first 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 having the first value, and can determine that the received PPDU is an UHR PPDU based on the PHY version identifier having the second value.

[0188] 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 relates to UL communication, and the second value of the UL / DL flag field relates to DL communication.

[0189] For example, the version-independent bits of U-SIG may include information about the length of a transmission opportunity (TXOP) and information about the BSS color ID.

[0190] For example, if a UHR PPDU is classified into various types (e.g., a type related to SU transmission (performed based on UL or DL), a type related to DL transmission, a type related to NDP transmission, a type related to DL non-MU-MIMO, a type related to DL MU-MIMO, a type related to Multi-AP operation, a type related to CBF (Coordinated beamforming), SR (Spatial Reuse), a type related to C-OFDMA (Coordinated OFDMA), a type related to C-TDMA (Coordinated TDMA)), information about the type of the EHT PPDU (e.g., 2-bit or 3-bit information) can be included in the version-dependent bits of the U-SIG.

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

[0192] Preamble puncturing may be applied to the PPDU of FIG. 5. Preamble puncturing refers to applying puncturing to a portion of the entire bandwidth of the PPDU (e.g., the secondary 20 MHz band). For example, when an 80 MHz PPDU is transmitted, the STA applies puncturing to the secondary 20 MHz band within the 80 MHz band, and can transmit the PPDU only through the primary 20 MHz band and the secondary 40 MHz band.

[0193] For example, the pattern of preamble puncturing can be preset. For example, when the first puncturing pattern is applied, puncturing can be applied only to the secondary 20 MHz band within the 80 MHz band. For example, when the second puncturing pattern is applied, puncturing can be applied only to one of the two secondary 20 MHz bands included in the secondary 40 MHz band within the 80 MHz band. For example, when the third puncturing pattern is applied, puncturing can be applied only to the secondary 20 MHz band included in the primary 80 MHz band within the 160 MHz band (or 80+80 MHz band). For example, when the fourth puncturing pattern is applied, a primary 40 MHz band included in the primary 80 MHz band within the 160 MHz band (or 80+80 MHz band) may be present, and puncturing may be applied to at least one 20 MHz channel that does not belong to the primary 40 MHz band.

[0194] Information regarding preamble puncturing applied to the PPDU may be included in the U-SIG and / or UHR-SIG. For example, the first field of the U-SIG may include information regarding the contiguous bandwidth of the PPDU, and the second field of the U-SIG may include information regarding preamble puncturing applied to the PPDU.

[0195] For example, U-SIG and UHR-SIG may include information regarding preamble puncturing based on the following method. If the bandwidth of the PPDU exceeds 80 MHz, the U-SIG may be individually configured in units of 80 MHz. For example, if the bandwidth of the PPDU is 160 MHz, the PPDU may include a first U-SIG for the first 80 MHz band and a second U-SIG for the second 80 MHz band. In this case, the first field of the first U-SIG may include information regarding the 160 MHz bandwidth, and the second field of the first U-SIG may include information regarding preamble puncturing applied to the first 80 MHz band (i.e., information regarding the preamble puncturing pattern). Additionally, the first field of the second U-SIG may include information about a 160 MHz bandwidth, and the second field of the second U-SIG may include information about preamble puncturing applied to the second 80 MHz band (i.e., information about a preamble puncturing pattern). Meanwhile, the UHR-SIG consecutive to the first U-SIG may include information about preamble puncturing applied to the second 80 MHz band (i.e., information about a preamble puncturing pattern), and the UHR-SIG consecutive to the second U-SIG may include information about preamble puncturing applied to the first 80 MHz band (i.e., information about a preamble puncturing pattern).

[0196] Additionally or alternatively, U-SIG and UHR-SIG may include information regarding preamble puncturing based on the following methods. U-SIG may include information regarding preamble puncturing for all bands (i.e., information regarding preamble puncturing patterns). That is, UHR-SIG may not include information regarding preamble puncturing, and only U-SIG may include information regarding preamble puncturing (i.e., information regarding preamble puncturing patterns).

[0197] U-SIGs can be configured in 20 MHz units. For example, if an 80 MHz PPDU is configured, U-SIGs can be duplicated. That is, four identical U-SIGs can be included within an 80 MHz PPDU. PPDUs exceeding the 80 MHz bandwidth can contain different U-SIGs.

[0198] The UHR-SIG of FIG. 5 may include control information for a receiving STA. The UHR-SIG may be transmitted via at least one symbol, and each symbol may have a length of 4 us. Information regarding the number of symbols used for the UHR-SIG may be included in the U-SIG.

[0199] UHR-SIG provides additional signals to the U-SIG field to enable STAs to interpret / decode UHR PPDUs. The UHR-SIG field may contain U-SIG overflow bits that are common to all users. The UHR-SIG field also contains resource allocation information, allowing STAs to look up resources used in fields containing data fields / UHR-STF / UHR-LTF (i.e., UHR modulated fields of an UHR PPDU).

[0200] The frequency resources of the UHR-LTF, UHR-STF, and data fields illustrated in FIG. 5 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 specification can be transmitted / received through RUs (resource units) defined by multiple subcarriers / tones.

[0201] FIG. 6 is a diagram illustrating the layout of resource units (RUs) used for a 20 MHz PPDU. That is, the UHR-LTF, UHR-STF, and / or data fields included in the 20 MHz PPDU can be transmitted / received through at least one of the various RUs defined in FIG. 6.

[0202] As shown at the top of Fig. 6, 26 units (i.e., units corresponding to 26 tones) can be arranged. Six tones can be used as a guard band in the leftmost band of the 20 MHz band, and five tones can be used as a guard band in the rightmost band of the 20 MHz band. In addition, seven DC tones can be inserted in the center band, i.e., the DC band, and 26 units corresponding to 13 tones can exist on each side of the DC band. In addition, 26 units, 52 units, and 106 units can be allocated to other bands. Each unit can be allocated for a receiving station, i.e., a user.

[0203] Meanwhile, the RU arrangement of FIG. 6 is utilized not only in a situation for multiple users (MUs) but also in a situation for a single user (SU), in which case it is possible to use one 242-unit as shown at the bottom of FIG. 4, in which case three DC tones can be inserted.

[0204] In the example of Fig. 6, RUs of various sizes, such as 26-RU, 52-RU, 106-RU, and 242-RU, are proposed. Since the specific sizes of these RUs can be expanded or increased, the present embodiment is not limited to the specific size of each RU (i.e., the number of corresponding tones). In this specification, N-RU may be represented as N-tone RU, etc. For example, 26-RU may be represented as 26-tone RU.

[0205] Figure 7 is a diagram showing the layout of resource units (RUs) used for 40MHz PPDU.

[0206] As in the example of Fig. 6 where RUs of various sizes were used, the example of Fig. 7 can also use 26-RU, 52-RU, 106-RU, 242-RU, 484-RU, etc. In addition, 5 DC tones can be inserted at the center frequency, 12 tones can be used as a guard band in the leftmost band of the 40 MHz band, and 11 tones can be used as a guard band in the rightmost band of the 40 MHz band.

[0207] Additionally, as illustrated, 484 RUs may be used when used for a single user. Meanwhile, the specific number of RUs may be changed, as in the example of FIG. 6.

[0208] Figure 8 is a diagram illustrating the layout of resource units (RUs) used for an 80MHz PPDU. The layout of resource units (RUs) used in this specification may vary. For example, the layout of resource units (RUs) used in the 80MHz band may vary.

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

[0210] TB PPDUs (941, 942) are transmitted at the same time and can be transmitted from multiple STAs (e.g., User STAs) whose AIDs are indicated in the Trigger frame (930). The ACK frame (950) for the TB PPDU can be implemented in various forms.

[0211] Figure 10 shows an example of channels used / supported / defined within the 2.4 GHz band.

[0212] The 2.4 GHz band may be referred to by other names, such as the first band (band). Furthermore, the 2.4 GHz band may refer to a frequency range in which channels with a center frequency adjacent to 2.4 GHz (e.g., channels with a center frequency between 2.4 and 2.5 GHz) are used / supported / defined.

[0213] The 2.4 GHz band may include multiple 20 MHz channels. The 20 MHz within the 2.4 GHz band may have multiple channel indices (e.g., indices 1 through 14). For example, the center frequency of a 20 MHz channel assigned channel index 1 may be 2.412 GHz, the center frequency of a 20 MHz channel assigned channel index 2 may be 2.417 GHz, and the center frequency of a 20 MHz channel assigned channel index N may be (2.407 + 0.005*N) GHz. The channel indices may be referred to by various names, such as channel numbers. The specific numerical values ​​of the channel indices and center frequencies may change.

[0214] Figure 10 exemplarily illustrates four channels within the 2.4 GHz band. The illustrated first frequency region (1010) to fourth frequency region (1040) may each include one channel. For example, the first frequency region (1010) may include channel 1 (a 20 MHz channel having an index of 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.

[0215] Figure 11 illustrates an example of channels used / supported / defined within the 5 GHz band.

[0216] The 5 GHz band may be referred to by other names, such as a second band / band, etc. The 5 GHz band may refer to a frequency range in which channels with center frequencies greater than or equal to 5 GHz and less than 6 GHz (or less than 5.9 GHz) are used / supported / defined. Alternatively, the 5 GHz band may include multiple channels between 4.5 GHz and 5.5 GHz. The specific figures shown in FIG. 11 are subject to change.

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

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

[0219] Figure 12 illustrates an example of channels used / supported / defined within the 6 GHz band.

[0220] The 6 GHz band may also be referred to by other names, such as the third band / band. The 6 GHz band may refer to the frequency range in which channels with center frequencies above 5.9 GHz are used, supported, or defined. The specific figures shown in Figure 12 are subject to change.

[0221] For example, the 20 MHz channel of FIG. 12 can be defined from 5.940 GHz. Specifically, the leftmost channel among the 20 MHz channels of FIG. 12 can have an index of 1 (or channel index, channel number, etc.), and a center frequency of 5.945 GHz can be assigned. That is, the center frequency of the indexed channel N can be determined as (5.940 + 0.005*N) GHz.

[0222] Accordingly, the indexes (or channel numbers) of the 20 MHz channels of FIG. 12 are 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, It can be 197, 201, 205, 209, 213, 217, 221, 225, 229, 233. Also, according to the (5.940 + 0.005*N) GHz rule mentioned above, the indices of the 40 MHz channels in Fig. 12 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.

[0223] Below, the structure and types / subtypes of MAC frames are described.

[0224] Fig. 13 illustrates an example of a header of a MAC frame. As illustrated, the MAC frame may include a frame control field / information of 2 octets in length, a duration field / information of 2 octets in length, a RA (Receiver Address) field / information of 6 octets in length, and a TA (Transmitter Address) field / information of 6 octets in length. As illustrated in Fig. 13, the four fields may be consecutive to each other. The MAC header of Fig. 13 may be modified in various ways, and a new field may be inserted between the four illustrated fields, or at least one of the illustrated fields may be omitted.

[0225] The MAC header illustrated in Fig. 13 may be positioned at the very front of a MAC frame. That is, the MAC frame may include a MAC header as illustrated in Fig. 13 and MAC body fields / information subsequent to the MAC header. The MAC frame including the MAC header of Fig. 13 is inserted / included in the data field of the PPDU (e.g., UHR PPDU) illustrated in Fig. 5.

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

[0227] For example, the management frame includes Association Request, Association Response, Reassociation Request, Reassociation Response, Probe Request, Probe Response, Beacon, Disassociation, Authentication, and Deauthentication frames / signals defined in conventional WLAN. For the management frame, the values ​​of the type fields (B3 and B2) in FIG. 13 are set to 00. In addition, the values ​​of the subtype fields (B7, B6, B5, B4) in FIG. 13 are as follows: Association Request (0000), Association Response (0001), Reassociation Request (0010), Reassociation Response (0011), Probe Request (0100), Probe Response (0101), Beacon (1000), Disassociation (1010), Authentication (1011), Deauthentication (1100).

[0228] For example, the control frame includes Trigger Beamforming Report Poll, NDP Announcement (NDPA), Control Frame Extension, Control Wrapper, Block Ack Request (BlockAckReq), Block Ack (BlockAck), PS-Poll, RTS, CTS, Ack, and CF-End frames / signals defined in conventional WLAN. For the control frame, the value of the type field (B3 and B2) in FIG. 13 is set to 01. Also, the values ​​of the subtype fields (B7, B6, B5, B4) of FIG. 13 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 (1010), RTS (1011), CTS (1100), Ack (1101), CF-End (1110).

[0229] For example, the data frame includes (QoS) Data, (QoS) Null, etc. defined in conventional WLAN. For the management frame, the value of the type field (B3 and B2) of Fig. 13 is set to 10.

[0230] The MAC frame / signal used in this specification can be identified through the type field / information and subtype field / information described above. For example, “frame” in this specification can mean a MAC frame in which the type bits B3 and B2 bits in the frame control field of the MAC header are set to 01, and the subtype bits B7, B6, B5, and B4 bits in the frame control field are set to 0010. Various MAC frames described in this specification are inserted / included in the data fields of various PPDUs (e.g., HE / VHT / HE / EHT / UHR PPDUs).

[0231] FIG. 14 illustrates a modified example of a transmitting device and / or a receiving device of the present specification.

[0232] The devices (e.g., AP STA, non-AP STA) illustrated in FIGS. 1 to 4 may be modified as illustrated in FIG. 14. The transceiver (630) of FIG. 14 may be identical to the transceivers (113, 123) of FIG. 1. The transceiver (630) of FIG. 14 may include a receiver and a transmitter.

[0233] The processor (610) of FIG. 14 may be identical to the processor (111, 121) of FIG. 1. Alternatively, the processor (610) of FIG. 14 may be identical to the processing chip (114, 124) of FIG. 1.

[0234] The memory (150) of FIG. 14 may be the same as the memory (112, 122) of FIG. 1. Alternatively, the memory (150) of FIG. 14 may be a separate external memory different from the memory (112, 122) of FIG. 1.

[0235] Referring to FIG. 14, a power management module (611) manages power to a processor (610) and / or a transceiver (630). A battery (612) supplies power to the power management module (611). A display (613) outputs results processed by the processor (610). A keypad (614) receives input to be used by the processor (610). The keypad (614) may be displayed on the display (613). A SIM card (615) may be an integrated circuit used to securely store an international mobile subscriber identity (IMSI) and an associated key used to identify and authenticate a subscriber in a mobile phone device, such as a mobile phone or computer.

[0236] Referring to FIG. 14, the speaker (640) can output sound-related results processed by the processor (610). The microphone (641) can receive sound-related input to be used by the processor (610).

[0237] 1. Problems with prior art (Fast BSS Transition (FT))

[0238] Figure 15 illustrates an over-the-air (OTA) FT protocol in a Robust Security Network (RSN).

[0239] Currently, in 802.11, when a non-AP STA moves (roams) from an AP (Old AP) to another AP (New AP), i.e., for a BSS (Basic Service Set) Transition, it must go through a reassociation process in the same mobility domain. A representative example is the Fast BSS Transition (FT) technology. In FT, as shown in Figure 15, several processes such as authentication and reassociation are performed with the FT Originator (FTO) and the Target FT Responder (FTR) (i.e., the New AP).

[0240] After this process, many operational parameters such as Agreement, Sequence Number (SN), EDCAF Parameter, etc. related to BlockAck (BA), Stream Classification Service (SCS), etc. are reset. Accordingly, there is an overhead that requires re-performing agreement / configuration along with multiple frame exchanges, and data loss may also occur during the FT process. Furthermore, from the perspective of a non-AP STA, seamless roaming without interruption is not easy. Therefore, this specification proposes a seamless roaming method utilizing AP MLD (Multi-Link Device) to solve this problem. Unlike FT, roaming does not require re-authentication / association.

[0241] In this specification, an STA performing BSS Transition (i.e., Roaming) is referred to as an RSTA, the AP to which the STA is currently associated when roaming is referred to as an Old AP (O_AP), and the AP to which the STA will roam is referred to as a New AP (N_AP). In addition, the Roaming method proposed in this specification is referred to as MLD Roaming. The designations (names) in this specification may be changed, and an STA may include an AP STA or a non-AP STA.

[0242] 2. UHR AP MLD structure for roaming

[0243] 2.1 General Procedure of Roaming in AP MLD

[0244] Figure 16 illustrates the high-level architecture for AP MLD.

[0245] Basically, an AP MLD can include one or more APs and has a high-level architecture as shown in Figure 16. Basically, the MLD can control several procedures / parameters common to multiple APs using the upper MAC sublayer. Examples of these procedures / parameters include authentication, association, SN / PN assignment, and power-save buffering of individually addressed frames.

[0246] Therefore, by utilizing AP MLD functionality, MLD-level parameters can be maintained without being reset when moving between APs (affiliated APs) involved in AP MLD. This specification proposes a roaming method utilizing AP MLD functionality.

[0247] Figure 17 illustrates an example of a high-level architecture for UHR AP MLD.

[0248] Figure 17 illustrates the architecture of APs supporting Seamless Roaming. To support Seamless Roaming, devices must be compatible with previous standard versions and enable seamless roaming between multiple devices. First, to ensure legacy compatibility with older devices, non-UHR non-AP STAs must be able to see non-UHR APs. This requires maintaining the MLD definition itself and preserving the existing architecture. Therefore, as shown in Figure 17, we define a new UHR AP MLD that maintains the existing MLD architecture while hierarchically affiliates MLDs that support seamless roaming. Each LMAC of the AP MLDs interfaces with a UHR UMAC, and the functions of the UMAC of the AP MLD that supports seamless roaming are managed by the UHR UMAC. A separate entity can manage various functions for roaming between AP MLDs (e.g., multi-link authentication (e.g., PTK), multi-link discovery / setup, multi-link reconfiguration). That is, this specification does not limit roaming support to UMAC. An example of such a case is shown in Figure 18. An entity can manage the control plane context and, as needed, other contexts. The AP MLD and UHR AP MLD are each individually connected to a DS (Distribution System). This architecture can also resolve scalability issues caused by the limitations of the Link ID bit size.Basically, the link ID is a 4-bit identifier and can support up to 16 link IDs. This link ID is required to move from one link to another during roaming, but the existing method limits the number of APs that can be roamed to 16. To address this issue, link IDs are grouped together with AP MLD IDs, addressing scalability issues. This is described in more detail in Section 2.2 below.

[0249] Figure 18 illustrates another example of a high-level architecture for UHR AP MLD.

[0250] Figure 19 illustrates another example of the High-level Architecture for UHR AP MLD.

[0251] Figure 19 shows an example with a similar architecture to Figure 17 but with different interfacing. Figure 18 shows that the LMAC of the AP MLD and the UHR UMAC are not directly connected, but are interfaced to the TID-to-Link Mapping function of the UMAC. This architecture allows for TID-to-Link Mapping to be performed individually in the UMAC of the AP MLD or in the UHR UMAC. The AP MLD and the UHR AP MLD are each individually connected to the DS. The method of use of this architecture and the types and number of functions that interface with the UHR UMAC are not limited.

[0252] Figure 20 illustrates an example of a high-level architecture in the case where there are only entities that are not MLD-based.

[0253] Figure 21 illustrates another example of a High-level Architecture in the case of entities that are not MLD-based.

[0254] The entities in Figures 18, 20, and 21 have functionality for roaming. AP MLDs capable of roaming are connected to a single entity and can perform association, authentication, link setup, and other operations with this entity. The entity also manages control plane contexts. AP MLDs capable of roaming can be grouped under the concept of a domain, and one or more entities can exist within a domain. It manages contexts that must be shared between APs for non-AP STAs to perform seamless roaming.

[0255] Figure 22 illustrates an example of a Roaming Architecture in an AP MLD area.

[0256] Figure 22 shows the structure and process for basic Roaming.

[0257] Each AP MLD is in a different location (i.e., non-collocated), and the APs belonging to each AP MLD are in the same or similar locations (i.e., collocated). This collocated may mean belonging to the exact same physical device, or it may mean belonging to a logically similar location even if it does not belong to a physical device. Since an AP MLD is a logical entity, it can be any physical device, but regardless of location, it can operate as an MLD that includes affiliated APs and can apply multi-link operation (MLO). Ultimately, all APs belonging to each AP MLD become affiliated APs of one AP MLD. For example, AP MLD 1 in Figure 22 includes affiliated APs 1, 2, and 3.

[0258] Based on Fig. 22, when a non-AP MLD moves, it will typically roam from one AP MLD to another. For example, if a non-AP MLD is configured with a multi-link setup with an AP MLD, and STA 1 and STA 2 are connected to AP 2 and AP 3 of AP MLD 1, when roaming to AP MLD 2, STA 1 may be connected to AP 4 and STA 2 may be connected to AP 5. In this case, each STA may temporarily associate with AP 4 and AP 5 so that AP 4 and AP 5 can transmit frames to each STA during the roaming process.

[0259] For reference, in Fig. 22, this architecture can be applied to a non-AP MLD with one affiliated STA, not a non-AP MLD with multiple affiliated STAs, or a non-AP STA that is not an MLD.

[0260] However, roaming does not necessarily only involve moving between different AP MLDs. For example, roaming can also involve changing APs within an AP MLD.

[0261] That is, a UHR AP MLD (or roaming-capable group) is affiliated with at least one (EHT) AP MLD, each AP MLD is non-collocated, and the APs belonging to each AP MLD are collocated.

[0262] Typically, a non-AP MLD (or STA) roams from one AP MLD to another (although roaming can also change APs within a specific AP MLD).

[0263] Since we are changing APs within the AP MLD, we can consider Roaming as a way to change links while maintaining the Multi-link Setup without completely tearing down the existing Multi-link Setup.

[0264] Since these processes are changing APs within the AP MLD, Roaming can be considered as a way to change links while maintaining the Multi-link Setup without completely tearing down the existing Multi-link Setup.

[0265] Basically, it can be composed of a) Announcement process and b) Frame exchange.

[0266] a) Announcement process: Each AP in the AP MLD announces to STAs whether it can perform MLD Roaming as proposed in this specification and information related to roaming APs within the AP MLD.

[0267] b) Frame exchange process: This is the process of exchanging frames that can trigger MLD roaming. Once frame exchange is complete, MLD roaming is completed based on the negotiated information, and operations with the O_AP are no longer performed, but rather with the N_AP.

[0268] In particular, this specification proposes to use the following method for MLD Roaming.

[0269] - One or more STAs belonging to a non-AP MLD can establish multiple links, each with a single radio. Therefore, we propose a method where a single STA adds and deletes links. This allows two or more links to be connected to a single STA.

[0270] - However, since frame exchange is performed only on one link and frame exchange cannot be performed on the remaining links, it becomes a doze state or disabled state.

[0271] - To achieve this, the non-AP MLD basically informs whether it is capable of the above-described capabilities in the Association Request frame during ML setup, i.e., when transmitting a Management frame containing the Basic Multi-link ML IE. This can be included in the MLD Capabilities and Operations subfield of the Common Info field if all STAs are capable, or in the Link Info field if only some STAs are capable. The information to be included is as follows:

[0272] => Single-radio ML setup enabled: This information indicates that STAs in a non-AP MLD can each have one radio and set up multiple links. This means that more than two links can be connected to one STA.

[0273] 2.2 Announcement Process for MLD Roaming

[0274] Each AP of each AP MLD can announce whether the roaming proposed in this specification is possible (i.e., whether the frame exchange b) described above is possible). Information that can be commonly conveyed to all APs can be whether the AP belongs to a UHR AP MLD or Entity, and more specifically, which UHR AP MLD / Entity it belongs to and collocation information, etc. If it is an architecture type that is affiliated with a UHR AP MLD, whether it is affiliated with a UHR AP MLD and UHR AP MLD ID information can be used, and if it is an architecture type that uses an Entity, whether it is connected to an Entity and information identifying the Entity, such as the Entity ID, can be included. The relevant information is as follows, and at least one or more can be included.

[0275] - MLD Roaming enabled: Indicates whether roaming is possible (e.g., can be indicated by 1 bit). Roaming is possible when affiliated with the same UHR AP MLD or connected to the same entity. If the AP is affiliated with a different UHR AP MLD or another entity (i.e., an AP belonging to a different mobility domain), roaming is not possible, and this can be indicated with the MLR Roaming enabled bit.

[0276] - UHR AP MLD ID / Entity ID: An ID that identifies the UHR AP MLD or entity presented above. The configuration for this UHR AP MLD ID / Entity ID is as follows.

[0277] A. ID Configuration for Roaming in AP MLD

[0278] Basically, you can assign an ID to the UHR AP MLD that is affiliated with the collocated AP MLDs. This is referred to as the UHR AP MLD ID in this specification. This UHR AP MLD ID can be unique within the UHR AP MLD or can be assigned a unique ID to the UHR AP MLD within the entire network. By defining a UHR AP MLD ID and distinguishing the UHR AP MLD, you can solve the scalability issue caused by the limited number of links and help identify more APs.

[0279] A-1) Unique ID Configuration within UHR AP MLD in a Network

[0280] This section proposes a method for ensuring that UHR AP MLD IDs are unique within a network. UHR AP MLD IDs can be assigned values ​​such as 0, 1, 2, etc. For example, a 4-bit UHR AP MLD ID can have values ​​from 0 to 15, while an 8-bit UHR AP MLD ID can have values ​​from 0 to 127. This size can be modified. The following explains the meaning of each UHR AP MLD ID.

[0281] 1) When the UHR AP MLD ID is 0: In this case, it can be known that the APs with this UHR AP MLD ID correspond to APs belonging to an AP MLD within the same UHR AP MLD. That is, when a non-AP MLD (or STA) recognizes this, it can recognize that the APs currently belong to the same UHR AP MLD. Therefore, roaming is possible only when the UHR AP MLD ID is 0. In addition, since other APs (transmitted BSSID (TxBSSID) or nontransmitted BSSID (NonTxBSSID)) of the Multiple BSSID set to which each AP belonging to this UHR AP MLD belongs also use the same Physical resource, this UHR AP MLD ID is assigned to them. However, the AP MLD ID of the AP MLD to which these APs belong (transmitted BSSID (TxBSSID) or nontransmitted BSSID (NonTxBSSID)) may be different.

[0282] Other UHR AP MLD IDs are mapped to uniquely identify each UHR AP MLD.

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

[0284] In this section, we propose a method to assign unique IDs to APs that can roam within the entire UHR AP MLD.

[0285] - Temporary link addition / deletion: Indicates whether a link can be temporarily added or removed for an STA. This means that one STA can have two or more links for a certain period of time (e.g., indicated by 1 bit).

[0286] - Collocation enabled: Indicates whether AP MLDs are collocated (e.g., indicated by 1 bit)

[0287] => If Collocation enabled = 1, it means that the AP and the reporting AP are physically close. Therefore, you can communicate with the existing connected AP without moving to the AP set to 1. Therefore, if a neighboring AP has Collocation enabled set to 1, you can avoid roaming. In other words, MLD Roaming Request / Response is not sent or received to an AP with Collocation enabled = 1.

[0288] - Collocation ID: An ID that distinguishes collocated AP MLDs. The configuration for this Collocation ID is as follows.

[0289] B. Collocation ID Configuration for Roaming in UHR AP MLD

[0290] Basically, you can assign an ID to collocated AP MLDs. This is referred to as a collocation ID in this specification. This collocation ID can be unique within a group of collocated AP MLDs or can be assigned a unique ID to a collocated AP MLD within a UHR AP MLD.

[0291] B-1. Unique Collocation ID Configuration within the Collocation Set in UHR AP MLD

[0292] This section proposes a method for ensuring that collocation IDs are unique within a collocated AP MLD group. Collocation IDs can be assigned values ​​such as 0, 1, 2, etc. For example, a 4-bit collocation ID can have values ​​from 0 to 15, while an 8-bit collocation ID can have values ​​from 0 to 127. This size can be changed. The following explains the meaning of each collocation ID.

[0293] => If Collocation ID is 0: In this case, APs with this Collocation ID can be considered as APs belonging to the same collocated AP MLD group. That is, if the MLD (or STA) recognizes this, it can recognize that the APs are currently collocated. In addition, other APs (transmitted BSSID (TxBSSID) or nontransmitted BSSID (NonTxBSSID)) of the Multiple BSSID set to which each AP belonging to this group belongs are also assigned this Collocation ID because they use the same Physical resource. However, the AP MLD ID of the AP MLD to which these APs belong (transmitted BSSID (TxBSSID) or nontransmitted BSSID (NonTxBSSID)) may be different.

[0294] Multiple AP MLDs can be included within a set of APs with the same Collocation ID.

[0295] Other Collocation IDs are mapped to uniquely identify each collocated AP MLD group.

[0296] B-2) Unique Collocation ID Configuration within UHR AP MLD

[0297] This section proposes a method for assigning unique collocation IDs within a collocated AP MLD group within a UHR AP MLD. Collocation IDs can be assigned values ​​such as 0, 1, 2, etc. For example, a 4-bit collocation ID can have values ​​from 0 to 15, while an 8-bit collocation ID can have values ​​from 0 to 127, and this size can be changed.

[0298] The above information can be included in the Management (MGMT) frame such as Beacon or Probe Response, and can be included in the MLD Roaming IE containing new MLD Roaming information or the existing Reduced Neighbor Report (RNR) IE (Information Element). The following is an example of when it can be included in the RNR IE. Basically, the information can be included in the TBTT Information field for each AP. The MLD Roaming parameters include at least one of the fields added in FIGS. 23 and 24 and can be included as in FIGS. 23 and 24. In addition to FIGS. 23 and 24, at least one of all fields defined in this specification is included.

[0299] Figure 23 shows an example of an RNR IE.

[0300] Non-AP STAs send and receive MLD Roaming Request / Response only to APs with Collocation Enabled = 0 via RNR IE.

[0301] Figure 24 shows another example for the RNR IE.

[0302] Non-AP STAs send and receive MLD Roaming Request / Response only to APs with Collocation ID ≠ via RNR IE.

[0303] If the size of the existing MLD Parameters subfield is not sufficient, as shown in FIGS. 23 and 24, a new MLD Roaming Parameters subfield can be created in the RNR IE to contain information. While the existing size can be changed, this has the problem that it may cause decoding issues for 802.11be STAs. In this case, the MLD Roaming Parameters subfield may not include MLD Roaming Enabled because the inclusion of MLD Roaming Parameters itself may indicate that MLD Roaming is possible.

[0304] The RNR IE can reduce overhead by only sending information such as whether another AP is collocated or non-collocated with the AP currently sending a Beacon or Probe Response in the Collocation Enabled field, as shown in Fig. 23. Furthermore, it can also indicate which AP is included in which collocation set by providing the AP's Collocation ID, as shown in Fig. 24. The RNR IE can include either the Collocation Enabled field or the Collocation ID, or both.

[0305] Figure 25 shows another example for the RNR IE.

[0306] If only the MLD Roaming availability is included, as in Fig. 25, the MLD Roaming Enabled can be indicated using the existing MLD Parameters subfield. Other information can be included as separate parameters, as in Fig. 23.

[0307] 2.3 Recommendation of Roaming APs

[0308] By looking at the MLD Roaming enabled of the RNR IE, the non-AP MLD can request information about the APs it wants to roam to through the Multi-Link Probe Request for the enabled APs, and in response, it can inform whether the AP is suitable for roaming through the Multi-Link Probe Response. When sending the ML Probe request frame to roam to the corresponding AP, MLD Roaming enabled = 1 can be set.

[0309] 2.3.1 AP Recommendation ML Probe Request frame format

[0310] In case of a Probe Request that is not for roaming, the AP Roaming Recommend enabled field can be added to reduce overhead that may occur when the AP makes unnecessary AP Recommendations.

[0311] 1) If included in the Common Info field

[0312] Figure 26 illustrates an example of the AP Roaming Recommendation enabled field and the Roaming Reason Code field in the Common Info field.

[0313] This can indicate whether or not to include AP Roaming Recommendation enabled via the Presence Bitmap. If it is included only in the Common Info field, it means that information about all APs sending a Probe Request is requested for roaming. In other words, if at least one AP is included in the ML Probe Request frame for a different operation, such as Association, rather than roaming, the AP Roaming Recommendation enabled field is not added to Common Info.

[0314] When an STA requests a recommendation for one or more AP MLDs, it may request recommendations for APs in one or more AP MLDs that are affiliated with the same SMD or UHR AP MLD by not including the AP MLD ID field.

[0315] Before roaming, when a non-AP STA sends a list of APs to which it can roam, it can set a Roaming Reason Code to inform the AP of the reason for roaming. At this time, the Probe Request Multi-Link element can be added to the Link Reconfiguration Notify Request frame, and the AP can use this Roaming Reason Code as a reference when determining which APs to recommend to the non-AP STA.

[0316] If a Roaming Reason Code is present in the Link Reconfiguration Notify Request frame, it is not included in the Probe Request Multi-Link element. If the reason for requesting roaming on all links is the same, it can be included in the Common Info field to reduce overhead. The Roaming Reason Code settings are described in Table 2.

[0317] Additionally, to reduce overhead, the AP Roaming Recommendation enabled Present field can be omitted from the Presence field and the AP Roaming Recommendation enabled field can be added only to the Common Info field.

[0318] 2) If included in the Link Info field

[0319] Figure 27 illustrates an example of the AP Roaming Recommendation enabled field in the Link Info field.

[0320] In the case of including it in the Link Info field, it is when requesting information about APs individually for roaming. If at least one AP is included in the ML Probe Request frame for a different operation than roaming, such as an Association, the AP Roaming Recommendation enabled field can be added to the Link Info. When making recommendations individually rather than for a single UHR AP MLD or all AP MLDs belonging to an Entity, the UHR AP MLD and AP MLD ID in the STA Control field can be used instead of the AP MLD ID in the Common Info field to inform the AP MLDs that recommend one or more AP MLDs.

[0321] When making a recommendation for more than one AP MLD, you can make a recommendation by repeatedly including the Link Info field. At this time, there are two ways to read the last field of the Per-STA Profile and know that another Per-STA Profile for another AP MLD follows. The first method is to check the total number of Per-STA Profiles through the number stored in the Number of Per-STA profile(s) field in the Common Info field. That is, you can know how many Recommended AP MLDs are recommended, and you can know that there are that many Per-STA Profiles. Therefore, you can decode this number of Per-STA Profiles. The second method is to use the More STA Control field of the Per-STA Profile. If More STA Control is set to 1, you can know that another Per-STA Profile exists after the Per-STA Profile currently being decoded. If the More STA Control field is 0, you can know that it is the information of the last AP MLD among the Recommended AP MLDs.

[0322] If the Link Info field is not included, it indicates that recommendations are being requested for all STAs affiliated with that non-AP MLD.

[0323] 2.3.2 AP Recommendation ML Probe Response frame format

[0324] By looking at MLD Roaming enabled, non-AP MLD can request information about APs it wants to roam to through Multi-Link Probe Request for enabled APs, and in response, it can inform whether the AP is suitable for roaming.

[0325] The Recommended AP List in the Probe Response framed contains a list of Link IDs for additional APs suitable for roaming.

[0326] 2.3.3. AP Recommendation Link Reconfiguration Notify Request frame

[0327] A non-AP MLD can send a Link Reconfiguration Notify Request frame to the UHR AP MLD individually, without waiting for the UHR AP MLD to receive a Link Reconfiguration Notify frame for AP recommendation. At this time, the reason for requesting roaming can be notified through the Roaming Reason Code. The settings for the Roaming Reason Code are described in Table 2. If a non-AP STA informs the AP of the reason for roaming in this way, the AP can recommend a more suitable AP. If the Roaming Reason Code is included in the Probe Request Multi-Link element, it is not included in the Link Reconfiguration Notify Request frame. Also, if the reason for roaming is different for each link, it is not included in the Link Reconfiguration Notify Request frame.

[0328] OrderMeaning1Category2Protected UHR Action3Dialog Token4Probe Request element or Reconfiguration Multi-Link element5Roaming Reason Code (Optional)

[0329] Roaming Reason ValueDescription0Unspecified1Excessive frame loss rates and / or poor conditions2Excessive delay for current traffic streams3Insufficient QoS capacity for current traffic streams4Better link found5Better AP found6Received too many replay counter failures7Received too many data MIC failures8Exceeded maximum number of retransmissions9Received too many broadcast disassociations10Received too many broadcast de-authentications11Previous roaming failed12Low RSSI13Transition due to received Roaming Request frame14Preferred Roaming List of Recommendation included15 - 255Reserved

[0330] 2.3.4. AP Recommendation Link Reconfiguration Notify frame

[0331] ML Probe Request / Response frame이 아닌 Link Reconfiguration Notify frame을 이용하여 UHR AP MLD가 non-AP MLD에게 Roaming 하기 좋은 link를 알려줄 수 있다. 하기 표 3은 Link Reconfiguration Notify frame Action field의 포맷의 일례를 나타낸다.

[0332] OrderMeaning1Category2Protected UHR Action3Dialog Token4Probe Request element5Roaming Reason Code (Optional)

[0333] Order 4: The Reconfiguration Multi-link IE defined in the existing 802.11be can be used to provide the information required for link recommendations. While the Reconfiguration ML element can recommend deletion or addition for a single link with a single STA Profile, it cannot recommend multiple links in this case. Therefore, to improve efficiency, one or more STA Profile subelements can be included to provide recommendations for multiple links. At this time, the UHR AP MLD can indicate the most suitable AP to move to among the roaming APs. This can be indicated in STA Profile order or through the Add / Delete Link ID list field. When indicating in STA Profile order, the link to be deleted or added can be placed first, followed by the link with the highest preference. When indicating via the Add / Delete Link ID list field, the link to be deleted or added can be placed first in the list of links, followed by the link with the highest preference.

[0334] Order 5: If a non-AP STA sends a Reconfiguration Notify Request frame first and does not include a Roaming Reason Code, or sends a Reconfiguration Notify frame without receiving a Reconfiguration Notify Request frame, the non-AP STA may send a Reconfiguration Notify frame including a Roaming Reason Code.

[0335] 2.4 Frame exchange process for MLD Roaming

[0336] Basically, for MLD Roaming to be triggered, frame exchange is required between the non-AP MLD (or STA) and the AP MLD. This frame can utilize the MGMT frame, particularly the Action frame, a type of MGMT frame. The frames are referred to as follows:

[0337] - The frame in which the STA requests MLD Roaming to the AP can be called the MLD Roaming Request frame.

[0338] - The frame in which the AP requests MLD Roaming to the STA can be called the MLD Roaming Response frame.

[0339] 2.4.1 MLD Roaming Request frame format

[0340] The MLD Roaming Request frame format can be configured in the following order:

[0341] OrderInformation1Category2UHR Action or Protected UHR Action3Dialog Token4Reconfiguration Multi-Link element5Context Transfer Level

[0342] Order 1: Basically, a Category can be included in a new UHR Action or a Protected UHR Action, but is not limited to these.

[0343] Order 4: The Reconfiguration Multi-link IE defined in the existing 802.11be can be used to provide the information required for MLD Roaming requests.

[0344] - The modified Reconfiguration Multi-link IE is as follows:

[0345] Order 5: When requesting MLD Roaming, the degree to which context transfer is required or possible can be indicated by setting the bit value of the Context Transfer Level.

[0346] 1) Common Info field

[0347] Figure 28 illustrates an example of the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0348] When moving to a new AP, if one or more STAs, particularly from a non-AP MLD perspective, simultaneously perform MLD roaming, MLD capabilities and operation or EML Capabilities may change. Therefore, this information can be additionally included in the Common Info field. As before, the presence of subfields in the Common Info field is determined by the Presence Bitmap.

[0349] When a Reconfiguration Notify Request frame includes a Reconfiguration Multi-Link IE or a Roaming Reason Code is transmitted via the Reconfiguration Notify frame, the Roaming Reason Code may be included within the Reconfiguration Multi-Link IE. In this case, if the reason for requesting roaming is the same for all links, the Roaming Reason Code is entered in the Common Info field, and the Roaming Reason Code has the value in Table 2.

[0350] 2) Link Info field

[0351] As mentioned in 1), if more than one STA performs MLD Roaming simultaneously, one or more Per-STA Profile subelements may be required.

[0352] Figure 29 illustrates an example of the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0353] - Basically, when transitioning to a different AP, the information on whether each link is STR (Simultaneous transmission and receive) or NSTR (non-STR) from a non-AP MLD perspective may change, so the NSTR indication bitmap may be included in the STA Info field. Similarly, as before, the presence or absence of subfields in STA Info can be determined by the Present subfields in STA Control.

[0354] - Here, Link ID is indicated as the Link ID corresponding to N_AP.

[0355] - The Complete Profile, as before, refers to the STA's Complete information, i.e., all information included when transmitting an Association Request frame. However, since this is an existing STA moving, not a new STA, the STA's capabilities or operational parameters may not change. Since the AP MLD already knows this, it can be used as an instruction that only includes the changed information, instead of the Complete Profile.

[0356] => For example, in the case of the Complete Profile = 0, which is a Partial Profile as before, when moving to N_AP in the STA Profile, only the information that will be changed (i.e., field / IE) is included. Or, if the Complete Profile is referred to as a Changed Profile and this value is 1, when moving to N_AP in the STA Profile, only the information that will be changed (i.e., field / IE) is included.

[0357] - The MLD Roaming Timer refers to the time when MLD Roaming is completed, no longer operating with the O_AP, and operating with the N_AP. In other words, it can refer to the remaining time until the expected time to switch to the AP to which to roam. This is related to the TIM field described later in 2.4.

[0358] => If the MLD Roaming timer is applied commonly to all APs, it can be included in the Common Info field, unlike in Fig. 23. In this case, the presence or absence of the MLD Roaming timer in the Common Info field can be indicated through the Presence Bitmap.

[0359] Since this is information transmitted by STA, it can be interpreted as a reference to AP MLD.

[0360] - UHR AP MLD ID, AP MLD ID, Collocation ID may be additionally included in the above-described information based on FIGS. 25 and 26 as follows. AP MLD ID is the ID of the AP MLD to which the APs to which the non-AP MLD (or STA) will roam belong, and UHR AP MLD ID is the ID of the UHR AP MLD to which the AP MLDs to which the non-AP MLD (or STA) will roam belong. In a situation where the AP MLD checks the UHR AP MLD ID in advance through a beacon or probe request / response process and sends a roaming request only to the same UHR AP MLD, the UHR AP MLD ID field may not exist in the Reconfiguration Multi-link element. Such cases are described in 1-2) case 2 when included in the Common Info field, 2-2) case 2 when included in the Link Info field - always present, and 3-2) case 2 when included in the Link Info field - not always present.

[0361] That is, it describes the format depending on whether the Reconfiguration Multi-link IE always includes the UHR AP MLD ID, AP MLD ID, and Collocation ID.

[0362] 1-1) Case 1 when included in the Common Info field

[0363] Figure 30 illustrates an example in which the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes a UHR AP MLD ID and an AP MLD ID.

[0364] This can indicate whether to include UHR AP MLD ID, AP MLD ID, Collocation ID, Roaming Recommended List, and Roaming Reason Code through the Presence Bitmap. If it is included only in the Common Info field, roaming can only be requested to APs with the same UHR AP MLD ID, AP MLD ID, and Collocation ID. In other words, requests cannot be made for multiple AP MLD IDs or multiple Collocation IDs even within the same UHR AP MLD. For example, one or more STAs cannot request reconfiguration to an AP in the same AP MLD and an AP in a different AP MLD. However, if roaming to the same AP MLD is common, overhead can be reduced compared to including it in each Link Info field below.

[0365] 1-2) Case 2 when included in the Common Info field

[0366] Figure 31 illustrates an example in which an AP MLD ID is included in the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0367] If the STA and AP have confirmed and recognized through the previous association process that the UHR AP MLDs to which N_AP and O_AP are affiliated are the same, there is no need to transmit the UHR AP MLD ID, so overhead can be reduced without separately adding the UHR AP MLD ID field as shown in Fig. 28. The method of including fields is the same as case 1, except for whether or not the UHR AP MLD ID field is included, and the method of adding the remaining fields is the same as case 1 if included in 1-1) Common Info field.

[0368] 2-1) If included in the Link Info field - case 1 if always present

[0369] Figure 32 illustrates an example in which the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes a UHR AP MLD ID and an AP MLD ID.

[0370] The Link Info field can contain multiple Per-STA Profile subelements, each of which can indicate a roaming request to an AP via its Link ID. The STA Control field of the Per-STA Profile subelement can identify the AP to which the STA wishes to roam via the AP MLD ID and UHR AP MLD ID. This allows roaming requests to multiple APs corresponding to different AP MLD IDs, but when requesting for the same AP MLD ID, the overhead is greater than that indicated via the Common Info field.

[0371] 2-2) If included in the Link Info field - case 2 if always present

[0372] Figure 33 illustrates an example in which an AP MLD ID is included in the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0373] If the STA and AP have confirmed and recognized that the UHR AP MLDs to which N_AP and O_AP are affiliated are the same through the previous association process, there is no need to transmit the UHR AP MLD ID, so overhead can be reduced without adding a separate UHR AP MLD ID field as shown in Fig. 31.

[0374] 3-1) If included in the Link Info field - case 1 if it does not always exist

[0375] Figure 34 illustrates another example in which the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes the UHR AP MLD ID and the AP MLD ID.

[0376] The inclusion of the UHR AP MLD ID and AP MLD ID corresponding to the AP corresponding to the Link ID can be indicated through the UHR AP MLD ID Present and AP MLD ID Present of the STA Control field of the Per-STA Profile subelement. The UHR AP MLD ID, AP MLD ID, Roaming Recommended List, and Roaming Reason Code can be included in the STA Info field or the STA Profile field. Similarly, this can request information about multiple APs corresponding to multiple AP MLD IDs. In particular, if combined with the indication method in the Common Info field of method 1), overhead can be reduced compared to method 2) by not including the UHR AP MLD ID, AP MLD ID, Roaming Recommended List, and Roaming Reason Code when requesting roaming for APs corresponding to the same AP MLD ID.

[0377] Meanwhile, if the UHR AP MLD ID and AP MLD ID are indicated in Common Info in another way, it may be implicitly recognized that this is a roaming request for APs corresponding to the same UHR AP MLD ID and AP MLD ID, and thus the UHR AP MLD ID, AP MLD ID, Roaming Recommended List, and Roaming Reason Code may not be included. In other words, the UHR AP MLD ID Present field and AP MLD ID Present field may not be included.

[0378] 3-2) If included in the Link Info field - case 2 if it does not always exist

[0379] Figure 35 illustrates another example in which the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment includes an AP MLD ID.

[0380] If the STA and AP have confirmed and recognized through the previous association process that the UHR AP MLDs to which N_AP and O_AP are affiliated are the same, there is no need to transmit the UHR AP MLD ID, so overhead can be reduced without adding a separate UHR AP MLD ID field as shown in Fig. 32.

[0381] Additionally, since this specification includes functions to temporarily add and delete links for MLD Roaming, a method to instruct this is needed, and the following method can be used.

[0382] Basically, using 2 bits or more, Type can be Type 0: Add / Type 1: Delete / Type 2: Temporary Add / Type 3: Temporary Delete. Temporary Delete can also be replaced with Type 1. Add means that an STA of a non-AP MLD requests an additional link connection with an AP of an AP MLD. Delete means that the currently connected link is disconnected (removed). Temporary Add means that an STA of a non-AP MLD requests an additional connection with an AP other than the currently connected AP so that multiple links can be configured.

[0383] => The Temporary of the Type field above can also be composed of a separate field. For example, it can be composed of the Type field excluding Temporary 1 bit and Temporary add / delete, and Temporary Add can be composed using the values ​​of the two fields (e.g., Temporary = 1, Type = Add).

[0384] When requesting both delete and add simultaneously during MLD Roaming, you can set the Common Info Type to 4 or 5. That is, you can define it as Type 4: Add then Delete, or Type 5: Delete then Add. In the case of Type 4, links corresponding to add are added first, and then links corresponding to delete are deleted. Conversely, Type 5 first deletes links corresponding to delete, and then links corresponding to add are added.

[0385] Type 8 is when a Link Switch is performed. Unlike add and delete, a Link Switch allows you to switch a link to another link at once.

[0386] The Add / Delete Link ID list field is an optional field that can be entered when the Type field is set to 4 or 5. The Link IDs corresponding to this Add / Delete Link ID list include a list of Link IDs of links that request both Add and Delete. For Link Info with a Link ID included in this list, if the Type is add, it indicates that it is an add link among links that both add and delete, and if it is delete, it indicates that it is a delete link.

[0387] The Type field of Link Info requires a value for both adding and deleting simultaneously, in addition to the value required for simply adding or deleting. The Type field of Link Info can be configured as follows, but the values ​​and settings of the Type field are not limited to the values ​​mentioned.

[0388] - Type 0: Add

[0389] - Type 1: Delete

[0390] - Type 2: Temporary Add

[0391] - Type 3: Temporary Delete

[0392] - Type 4: Add then Delete (Add)

[0393] - Type 5: Add then Delete (Delete)

[0394] - Type 6: Delete then Add (Add)

[0395] - Type 7: Delete then Add (Delete)

[0396] - Type 8: Link Switch

[0397] Type 4 is the case of a link being added in an action of adding and then deleting a link, and Type 5 is the case of a link being deleted in an action of adding and then deleting a link.

[0398] Type 6 is the case of a link being added in an action of deleting a link and then adding it, and Type 7 is the case of a link being deleted in an action of deleting a link and then adding it.

[0399] The above Type field and the above Temporary field can be included as follows, and at least one or more fields are included.

[0400] 1) When included in the MLD Roaming Request frame body or the Common Info field of Reconfiguration IE

[0401] Figure 36 illustrates an example in which a Temporary field is included in the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0402] In this case, only one operation can be performed for all APs. That is, in the case of Add, only a request to add a link can be made for the APs indicated in Link Info. Figure 36 is an example included in Common Info.

[0403] 2-1) When included in the MLD Roaming Request frame body or the Link Info field of Reconfiguration IE

[0404] Figure 37 illustrates an example in which a Temporary field is included in the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0405] In this case, different operations can be requested for each AP. For example, a temporary add can be requested for one AP, and a delete can be requested for another AP. Figure 37 is an example included in Link Info.

[0406] 2-2) When included in the MLD Roaming Request frame body or the Link Info field of Reconfiguration IE

[0407] Figure 38 illustrates another example in which a Temporary field is included in the Link Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0408] Figure 38 is an example in which the Type field is included in Link Info in the case of Link Info in which the UHR AP MLD ID field is omitted.

[0409] 3-1) Example of sending add and delete requests simultaneously - When you want to add a new link first and then delete an existing link

[0410] - When the Common Info field contains both the Type field and the Add / Delete Link ID list field.

[0411] Set the Type of the Common Info field to 4 and add the Link IDs of the newly added link and the Link IDs of the deleted link to the Add / Delete Link ID list. At this time, the Link ID of the added link can be placed before the deleted link in the list order. For example, if the Link ID of the added link is 5 and the Link ID of the deleted link is 2, you can set the Add / Delete Link ID List to 5, 2. By setting the order in this way, you can tell which link is added and which link is deleted in Common Info, but since this can also be known through the Type field of the Link Info field, the action of setting the order may not be necessary.

[0412] Since the Type of the Link Info field already indicates whether the frame requests Add and Delete individually or simultaneously through Common Info, it is possible to indicate whether the link is being added or deleted using only Type 0 and 1. Alternatively, if the Link IDs are ordered in the Add / Delete Link ID List of Common Info, the overhead can be reduced by omitting the Type field in the Link Info.

[0413] - If only the Type field is included in the Common Info field

[0414] You can set the Type of the Common Info field to 4 and use Type 0, 1 in the Link Info field to indicate whether the link is being added or deleted.

[0415] - If the Common Info field does not contain both the Type field and the Add / Delete Link ID list field.

[0416] In this case, you can request Add then Delete using the Type field value of 4 or 5 in the Link Info field. In this case, the link being added is set to Type 4, and the link being deleted is set to Type 5. The link set to Type 4 is added first, and then the link set to Type 5 is deleted.

[0417] 3-2) Example of sending add and delete requests at the same time - When you want to delete the existing link first and then add a new link

[0418] - When the Common Info field contains both the Type field and the Add / Delete Link ID list field.

[0419] When the Type of the Common Info field is set to 5 and the remaining operations are the same as in the case of 3-1) sending Add and Delete requests simultaneously - adding a new link first and deleting an existing link, and including both the Type field and the Add / Delete Link ID list field in the Common Info field.

[0420] - If only the Type field is included in the Common Info field

[0421] When the Type of the Common Info field is set to 5 and the remaining operations are the same as in the case of 3-1) sending Add and Delete requests simultaneously - adding a new link first, deleting an existing link, and including only the Type field in the Common Info field.

[0422] - If the Common Info field does not contain both the Type field and the Add / Delete Link ID list field.

[0423] In this case, you can request Add then Delete using the Type field value of 6 or 7 in the Link Info field. In this case, the link being added is set to Type 6, and the link being deleted is set to Type 7. The link set to Type 6 is added first, and then the link set to Type 7 is deleted.

[0424] 4) When performing a Link Switch using the Type field

[0425] Figure 39 illustrates an example in which the AP Removal Timer field is included in the Common Info field of the Reconfiguration Multi-link IE proposed in this embodiment.

[0426] When switching links using Type 8 of Common Info instead of using add / delete when changing links, the link sending the MLD Roaming Request frame is removed and the switch is made with the Link ID in the Link Info field. In the case of link switching, overhead can be reduced by omitting the Type field in the Link Info field. When performing a link switch, the AP and STA must know when the link switch is to be performed. This can be determined by the AP and notified to the STA, or by the STA and notified to the AP. Due to the link switch, the channels of the New AP and the Old AP are different, and the New AP needs information about deletion, and the Old AP needs information about addition.

[0427] When the AP notifies the STA, it can notify in the MLD Roaming Response by adding the Channel Switch Count field as shown in FIG. 40 or FIG. 41 described below. When the STA determines and notifies the AP, it can notify in the MLD Roaming Request by using the Delete Timer field (or AP Removal Timer field) in the Reconfiguration element.

[0428] When using the Delete Timer of Reconfiguration IE to notify the link switch completion time, if all links that requested a link switch through MLD Roaming Request have the same Delete Timer value, it can be added to Common Info instead of Link Info as shown in Fig. 36 to reduce overhead. In this case, the Delete Timer Present field (or AP Removal Timer Present field) of Link Info can be used to avoid using the Delete Timer field. If the Delete Timer values ​​of the links that requested a link switch are different, the Delete Timer field can be added to Link Info instead of Common Info. If there is only one link to be linked switched, the Delete Timer field can be added to Common Info, or the Delete Timer field can be added to User Info.

[0429] 2.4.2 MLD Roaming Response frame format

[0430] In the MLD Roaming Response frame, it is necessary to consider the link-level parameters that must be provided because the link must be changed while maintaining the multi-link setup.

[0431] OrderInformation1Category2UHR Action or Protected UHR Action3Dialog Token4Status Code5Basic Multi-Link element6Context Transfer Level7Context Transfer End

[0432] Order 1: Basically, a Category can be included in a new UHR Action or a Protected UHR Action, but is not limited to these.

[0433] Order 4: Status Code can utilize the existing Status code field.

[0434] - When responding to an MLD Roaming request, the Basic Multi-link IE defined in the existing 802.11be can be used to obtain the necessary information about AP MLD and N_AP.

[0435] Order 5: The modified Basic Multi-link IE is as follows:

[0436] Order 6: When sending an MLD Roaming Response, the degree of context transfer required can be indicated by setting the bit value of the Context Transfer Level.

[0437] Order 7: If the number of contexts to be transferred, as determined through the Context Transfer Level in the previous AP MLD, has been transferred to the new AP MLD, the field can be used to indicate whether the transfer has been completed.

[0438] 1) Common Info field

[0439] Figure 40 illustrates an example of the Common Info field of the Basic Multi-link IE proposed in this embodiment.

[0440] - The existing Common Info field can be utilized. The Common Info information here corresponds to the N_APs where one or more STAs perform MLD Roaming.

[0441] - When sending a Beacon or Multi-Link Probe Response frame and including the Basic Multi-link element, the Channel Switch Count field may be omitted by using the Channel Switch Count Present field.

[0442] When the Type field of Common Info in the Reconfiguration IE of the MLD Roaming Request frame is set to Type 8 or the Type field of User Info is set to Type 8, the Channel Switch Count field of the Common Info of the Basic ML IE can be included. When included in the Common Info, if more than one link(s) requesting a link switch simultaneously with one MLD Roaming Request take the same amount of time to finish switching to the new link(s), the Channel Switch Count field of the Common Info can be used to inform the AP how long to perform the link switch. The Link Switch Count indicates the number of TBTTs to be received from the AP connected to the existing link before the link switches to the new link. The Channel Switch Count field allows the AP to inform the STA how long to perform the link switch to the new link. Channel Switch Count is the period during which operations are allowed (e.g. DL forwarding) with the AP MLDs connected to the previously added link, and when it expires, the existing link is deleted and the AP MLDs roam to the newly added link, until it moves to a completely new link. This value can represent the number of TBTTs, and in addition, the Channel Switch Count field, which actually takes in units of X units (e.g. us), allows the AP to inform the STA how long it will perform the link switch to the new link.If the times at which each link must complete a link switch are different, the Channel Switch Count field can be added to the Link Info to individually indicate when the link switch will be completed for each link. If a link switch is requested for only one link in the MLD Roaming Request, the Channel Switch Count field can be included in the Common Info or the Link Info. The Channel Switch Count is used when switching to a new link from O_AP to N_AP, and when the channels of the two links are different, and information such as when the link was switched to a different link cannot be exchanged. By setting a specified Count or time, the link switch can be determined until when even if the channels are different.

[0443] 2) Link Info field

[0444] As mentioned in 1), if more than one STA performs MLD Roaming simultaneously, one or more Per-STA Profile subelements may be required for the corresponding APs.

[0445] The information changed for the STA Control field, STA Info field, and STA Profile field of the existing Basic Multi-link IE is as follows.

[0446] Figure 41 illustrates an example of the Link Info field of the Basic Multi-link IE proposed in this embodiment.

[0447] - Basically, the Link ID in the STA Info field indicates the Link ID corresponding to N_AP.

[0448] - Complete Profile refers to the AP's Complete information, i.e., all information included when transmitting an Association Response frame, as before. However, since the AP's STA performs MLD Roaming, its Capability or operational parameters may not change. Therefore, in this case, the Complete Profile is set to 0.

[0449] - Additionally, it includes information about the MLD Roaming Timer. For this, the STA Control field includes the MLD Roaming Timer Present field, and the STA Info field includes the MLD Roaming Timer field. This means the time when MLD Roaming is completed and no longer operates with the O_AP, but operates with the N_AP. This can utilize the MLD Roaming Timer information transmitted by the STA, but may not be included if the STA transmitted it and the Response's Status Code is SUCCESS.

[0450] When included in the Association Request / Response and including the Basic Multi-Link IE, since Roaming-related information is not required, the UHR MLD MAC Address, UHR AP MLD ID, Collocation ID, Channel Switch Count, UHR Roaming Timer included in Fig. 37 and the MLD Roaming Timer, UHR AP MLD ID, AP MLD ID, Channel Switch Count fields included in Fig. 38 can be configured to configure the Basic ML element without adding them using the presence field.

[0451] If the time required for each link to complete a link switch varies, the Channel Switch Count field can be added to the Link Info field to indicate the individual time required for the link switch to complete for each link. If the MLD Roaming Request requests a link switch for only one link, the Channel Switch Count field can be included in either the Common Info or the Link Info field.

[0452] - In addition to the above information, the UHR AP MLD ID and AP MLD ID can be included as follows. The AP MLD ID is the ID of the AP MLD to which the APs to which the non-AP MLD (or STA) will roam belong, and the UHR AP MLD ID is the ID of the UHR AP MLD to which the AP MLDs to which the non-AP MLD (or STA) will roam belong. If the UHR AP MLD ID is not included in the MLD Roaming Request frame, it can be determined that it is affiliated with the same UHR AP MLD, so the UHR AP MLD ID field may not be included. This case is described in 1-2) case 2 when included in the Common Info field, 2-2) case 2 when included in the Link Info field - always present, and 3-2) case 2 when included in the Link Info field - not always present.

[0453] 1-1) Case 1 when included in the Common Info field

[0454] This can be utilized when requested in the case 1 of the Reconfiguration ML IE described above, 1-1) Common Info field case 1.

[0455] Similarly, the presence bitmap indicates 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 Common Info field. This can only provide information on APs whose AP MLD has UHR AP MLD ID = 0 and Collocation ID≠.

[0456] 1-2) Case 2 when included in the Common Info field

[0457] This can be utilized when requested using case 2 method if it is included in the 1-2) Common Info field in the Reconfiguration ML IE described above.

[0458] Similarly, the presence bitmap indicates whether or not to include the AP MLD ID, and accordingly the AP MLD ID is included in the Common Info field.

[0459] 2-1) If included in the Link Info field - case 1 if always present

[0460] This can be utilized when requested using the case 1 method - if it is included in the 2-1) Link Info field in the Reconfiguration ML IE described above - and always exists.

[0461] The STA Control field includes the UHR AP MLD ID and AP MLD ID corresponding to the AP corresponding to the Link ID of each Per-STA Profile subelement. This can provide information about multiple APs corresponding to multiple AP MLD IDs, but when providing information for the same AP MLD ID, the overhead is greater than the method of indicating it in the Common Info field.

[0462] 2-2) If included in the Link Info field - case 2 if always present

[0463] This can be used when requested using the case 2 method - if it is included in the 2-2) Link Info field in the Reconfiguration ML IE described above - and always exists.

[0464] The STA Control field includes the AP MLD ID corresponding to the AP corresponding to the Link ID of each Per-STA Profile subelement. This can provide information about multiple APs corresponding to multiple AP MLD IDs, but when providing information for the same AP MLD ID, the overhead is greater than the method of indicating it in the Common Info field.

[0465] 3-1) If included in the Link Info field - case 1 if it does not always exist

[0466] This can be used when requested in case 1 - if it is included in the 3-1) Link Info field in the Reconfiguration ML IE described above - and is not always present.

[0467] The inclusion of the AP MLD ID corresponding to the AP corresponding to the Link ID can be indicated through the UHR AP MLD ID Present and AP MLD ID Present of the STA Control field of the Per-STA Profile subelement. The UHR AP MLD ID and AP MLD ID can be included in the STA Info field or the STA Profile field. Similarly, this can provide information about multiple APs corresponding to multiple AP MLD IDs. In particular, if combined with the indication method in the Common Info field of method 1), when only information about APs corresponding to the same AP MLD ID is provided, overhead can be reduced compared to method 2) by not including the UHR AP MLD ID and AP MLD ID.

[0468] => Meanwhile, in the case of Unique ID Configuration within the Collocation Set in AP MLD described above, if the Collocation ID is 0, the UHR AP MLD ID, AP MLD ID, and Collocation ID may be omitted. That is, if the Collocation ID does not exist, the AP that received the request can implicitly recognize that it is a request for information from other APs regarding the AP MLD to which it belongs.

[0469] => On the other hand, if the Collocation ID is indicated in Common Info in another way, it may not include the UHR AP MLD ID, AP MLD ID, and Collocation ID because it is implicitly recognized that this is information about APs corresponding to the same Collocation Set. In other words, the UHR AP MLD ID Present and AP MLD ID Present fields may not be included.

[0470] 3-2) If included in the Link Info field - case 2 if it does not always exist

[0471] This can be used when requested in case 2 - if it is included in the 3-2) Link Info field in the Reconfiguration ML IE described above - and is not always present.

[0472] The presence or absence of an AP MLD ID corresponding to an AP corresponding to a Link ID can be indicated through the AP MLD ID Present in the STA Control field of the Per-STA Profile subelement. The AP MLD ID can be included in the STA Info field or the STA Profile field. Similarly, this can provide information about multiple APs corresponding to multiple AP MLD IDs. In particular, if combined with the indication method in the Common Info field of method 1), the overhead can be reduced compared to method 2) by not including the AP MLD ID when only providing information about APs corresponding to the same AP MLD ID.

[0473] => Meanwhile, in the case of Unique ID Configuration within the Collocation Set in AP MLD described above, if the Collocation ID is 0, the AP MLD ID and Collocation ID may be omitted. That is, if the Collocation ID does not exist, the AP that received the request can implicitly recognize that it is a request for information from other APs regarding the AP MLD to which it belongs.

[0474] => On the other hand, if the Collocation ID is indicated in Common Info in another way, it may not include the AP MLD ID and Collocation ID because it is implicitly recognized that this is information about APs corresponding to the same Collocation Set. In other words, the UHR AP MLD ID Present and AP MLD ID Present fields may not be included.

[0475] Order 6: Group key Information

[0476] Basically, since the Group key is different for each link, it is necessary to provide Group key information for N_APs.

[0477] Figure 42 illustrates an example of the Group Key Information field.

[0478] Referring to Figure 42, Length indicates the length of the Group key Information. The Group key Information for each N_AP includes the MLO GTK KDE format, MLO IGTK KDE, and MLO BIGTK KDE, which each include the Link ID of the N_AP as defined in 802.11be.

[0479] Order 7: Because the total AID (Association Identifier) ​​space is limited, each AP MLD can manage its own AID. This means that AIDs can be assigned when roaming to other AP MLDs. However, AIDs may not be included in the following cases:

[0480] - When roaming to another AP MLD and granting the same AID

[0481] - In case the entire AID space is managed by UHR AP MLD as before

[0482] Orders 8 and 9: In these cases, the channel of each AP to which roaming is performed is the same, but it can be considered different from the channels of previously connected APs. However, the following cases may be included differently for Orders 8 and 9:

[0483] - These IEs are not included as all APs that enable MLD Roaming are always on the same channel.

[0484] - The channel of an AP to be roamed to may be the same as or different from the channel of the previously connected AP. In this case, the Channel Switching Announcement IE or Extended Channel Switching Announcement IE may be included in the Link Info of the Basic Multi-link IE in Order 5, respectively. This is to perform a channel switch for each AP to be roamed to.

[0485] Order 10: This can be used to map TIDs in advance for newly connected links through TID-to-link mapping. If separate TID-to-link mapping is not performed, the default mapping can be applied.

[0486] Additionally, an MLD Roaming Timer can be added to both the MLD Roaming Request / Response frames.

[0487] Additionally, the AP MLD can include the MLD Roaming Timer of the above Reconfiguration ML IE. This can also indicate a set MLD Roaming Timer since the AP MLD can control the current roaming. For example, if the STA does not include the MLD Roaming Timer or it is inappropriate, the AP MLD can set it and notify. Also, if the STA did not transmit the MLD Roaming Timer, the AP MLD can set it and notify. The meaning of the MLD Roaming Timer is the same. That is, it means the time when MLD Roaming is completed, no more operations are performed with the O_AP, and operations are performed with the N_AP.

[0488] => When a Temporary Add request is received, after the MLD Roaming Timer expires, the STA completely disconnects from the O_AP (i.e., Temporary Delete or Delete) and allows it to connect to the N_AP.

[0489] => If the MLD Roaming timer is applied commonly to all APs, it can be included in the Common Info field. At this time, the presence or absence of the Common Info field can be indicated through the Presence Bitmap.

[0490] - Additionally, the MLD Roaming Response frame can include information about the MLD Roaming Timer. To this end, the STA Control field includes an MLD Roaming Timer Present field, and the STA Info field includes an MLD Roaming Timer field. This can indicate the remaining time until the STA can receive data from the AP to which it is roaming. This can also utilize the MLD Roaming Timer information transmitted by the STA. This is basically related to the TIM field presented in 2.5.

[0491] => If the MLD Roaming timer is applied commonly to all APs, it can be included in the Common Info field. In this case, the presence of the Common Info field can be indicated through the Presence Bitmap. Alternatively, it can be included in the MLD Roaming Probe Response frame body.

[0492] 2.5 MLD Roaming Example

[0493] The operation process of AP and STA performing MLD Roaming is as follows.

[0494] Figure 43 illustrates a procedure for determining whether an N_AP is capable of roaming using the Collocation Enabled field.

[0495] Referring to Figure 43, the transmission and reception process of the AP is as follows.

[0496] O_AP transmits the RNR IE to the STA in the Beacon. When O_AP receives the MLD Roaming Request frame from the STA, it checks the Link ID, AP MLD ID, and UHR AP MLD ID (optional) of the AP to which the STA wishes to roam. O_AP sends the STA whether it accepts the request and the information described in the Roaming Response frame format through the MLD Roaming Response frame.

[0497] Referring to Figure 43, the transmission and reception process of STA is as follows.

[0498] When the STA receives a Beacon, it checks whether the MLD Roaming Parameters field exists in the TBTT Information field. The STA checks the MLD Roaming Enabled, UHR AP MLD ID, and Collocation Enabled fields in the MLD Roaming Parameters field. At this time, MLD Roaming Enabled=1, UHR AP MLD ID=0, and Collocation Enabled=0. The STA transmits an MLD Roaming Request frame to the O_AP. The STA receives an MLD Roaming Response frame from the O_AP, and if accepted, roams to the N_AP.

[0499] Figure 44 illustrates a procedure for determining whether an N_AP is capable of roaming using a Collocation ID.

[0500] Referring to Figure 44, the transmission and reception process of the AP is as follows.

[0501] O_AP transmits the RNR IE to the STA in the Beacon. When O_AP receives the MLD Roaming Request frame from the STA, it checks the Link ID, AP MLD ID, and UHR AP MLD ID (optional) of the AP to which the STA wishes to roam. O_AP sends the STA whether it accepts the request and the information described in the Roaming Response frame format through the MLD Roaming Response frame.

[0502] Referring to Figure 44, the transmission and reception process of STA is as follows.

[0503] When the STA receives a Beacon, it checks whether the MLD Roaming Parameters field exists in the TBTT Information field. The STA checks the MLD Roaming Enabled, UHR AP MLD ID, and Collocation ID in the MLD Roaming Parameters field. At this time, MLD Roaming Enabled=1, UHR AP MLD ID=0, and Collocation ID≠ are set. The STA transmits an MLD Roaming Request frame to the O_AP. The STA receives an MLD Roaming Response frame from the O_AP, and if accepted, roams to the N_AP.

[0504] Figure 45 illustrates the MLD Roaming procedure when a UHR AP MLD ID is entered in the Reconfiguration element.

[0505] Referring to Figure 45, the transmission and reception process of the AP is as follows.

[0506] O_AP transmits information about other APs to STA through Beacon. When receiving MLD Roaming Request frame from STA, STA checks the ID of AP to which it wants to roam through Link ID and AP MLID. Additionally, if MLD Roaming Request frame includes UHR AP MLD ID, STA also checks UHR AP MLD ID. O_AP transmits to STA whether it accepts and the information described in 2.4.2. Roaming Response frame format through MLD Roaming Response frame.

[0507] Referring to Figure 45, the transmission and reception process of STA is as follows.

[0508] The STA receives information about other APs via the beacon from the O_AP. Based on the information about the APs received from the O_AP, the STA determines the AP to which to roam. The STA transmits a Roaming Request frame to the O_AP. The STA receives an MLD Roaming Response frame from the O_AP, and if accepted, roams to the N_AP.

[0509] Figure 46 illustrates the MLD Roaming procedure when the UHR AP MLD ID is not entered in the Reconfiguration element.

[0510] Referring to Figure 46, the transmission and reception process of the AP is as follows.

[0511] O_AP transmits information about other APs to STAs via Beacon. Upon receiving an MLD Roaming Request frame from an STA, the STA verifies the ID of the AP it wishes to roam to using the Link ID and AP MLID. O_AP then transmits the MLD Roaming Response frame to the STA, indicating whether it accepts the request and including the information described in 2.4.2. Roaming Response frame format.

[0512] Referring to Figure 46, the transmission and reception process of STA is as follows.

[0513] The STA receives information about other APs via the beacon from the O_AP. Based on the information about the APs received from the O_AP, the STA determines the AP to which to roam. The STA transmits a Roaming Request frame to the O_AP. The STA receives an MLD Roaming Response frame from the O_AP, and if accepted, roams to the N_AP.

[0514] Figure 47 illustrates an example of a collocated AP set.

[0515] Figure 47 shows an example of determining whether to roam based on collocation information when a non-AP MLD moves while already connected to AP 2. Collocation information can be obtained through the Collocation Enabled field or Collocation ID field of the RNR IE. Although AP 4 and AP 5, which are affiliated with AP MLD 2, exist around the non-AP MLD, they are included in the same collocated AP set as the currently connected AP 2, so the non-AP MLD does not make a roaming request to AP 4 and AP 5. On the other hand, the non-AP MLD can make a roaming request to AP 6, AP 7, and AP 8, which are included in a different collocated AP set from AP 2. By defining a collocated AP set in this way, unnecessary roaming can be prevented by informing the non-AP MLD of information about APs that are physically close and do not need to roam.

[0516] 1) Example #1 - Only some STAs roam to the AP first.

[0517] Figure 48 illustrates Example 1 for the MLD Roaming procedure.

[0518] Figure 48 illustrates a case where only some STAs roam to APs first, rather than all STAs simultaneously moving to APs in a different AP MLD. For example, STA 1 first roams from AP 1 to AP 3, and then STA 2 roams from AP 3 to AP 5. In this example, there are two STAs in the non-AP MLD, but even if there are three STAs, only two STAs can roam first, and the remaining STAs can roam later.

[0519] In this example, STA 1 and AP 1, as presented above, can first exchange MLD Roaming Request / Response. 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 include information about AP 4 in the Basic Multi-link IE along with whether to accept it. Next, STA 2 and AP 3 will go through the same process for AP 5. At this time, the process can also be performed for AP 4, to which STA 1 is connected, instead of STA 2.

[0520] This example can be effective for data reception. While AP 1 and STA 1 are roaming, AP 2 and STA 3 can exchange data. Similarly, while AP 3 and STA 2 are roaming, AP 4 and STA 1 can exchange data. In this case, all TIDs must be mapped to the links exchanging data. However, this example is difficult to apply to non-MLD STAs or when there is only one STA in the MLD, and it can incur relatively high frame exchange overhead.

[0521] Figure 49 shows the operation process of Example 1 for the MLD Roaming procedure.

[0522] Referring to Figure 49, the transmission and reception process of the AP is as follows.

[0523] AP 1 receives a Roaming Request frame from STA 1. The STA determines the ID of the AP to which it wishes to roam using the Link ID, AP MLD ID, and UHR AP MLD ID (optional). AP 1 transmits to STA 1 whether it accepts the roaming request and the information described in 2.4.2. Roaming Response frame format for APs 4 and 5 via the MLD Roaming Response frame.

[0524] Referring to Figure 49, the transmission and reception process of STA is as follows.

[0525] STA 1 transmits an MLD Roaming Request frame for APs 4 and 5 to AP 1. If STA 1 receives roaming acceptance from AP 1 by receiving an MLD Roaming Response frame, STA 1 roams to AP 4 based on the information about AP 4 it received. After STA 1's roaming is complete, STA 2 also roams to AP 4 based on whether STA 1 accepted AP 5 and the information about APs 4 and 5.

[0526] 2) Example #2 - When all STAs are transferred to APs of a different Group at once.

[0527] Figure 50 illustrates Example 2 for the MLD Roaming procedure.

[0528] Figure 50 illustrates a case where all STAs simultaneously move to APs in a different group. For example, STA 1 simultaneously roams from AP 1 to AP 3, and STA 2 simultaneously roams from AP 3 to AP 5.

[0529] In this example, STA 1 and AP 1 or STA 2 and AP 3 presented above can exchange MLD Roaming Request / Response. 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 include information about AP 4 and AP 5 in the Basic Multi-link IE along with whether to accept it.

[0530] This example can reduce frame overhead compared to Example 1 and, depending on the AP MLD Roaming domain structure, reduce data latency. For example, if there is an Anchor AP in AP MLD that manages data reception from the DS and MLD Roaming, if this Anchor AP accepts the MLD Roaming Request, the data path can be set for Roaming in advance.

[0531] Figure 51 shows the operation process of Example 2 for the MLD Roaming procedure.

[0532] Referring to Figure 51, the transmission and reception process of the AP is as follows.

[0533] AP 1 receives a Roaming Request frame from STA 1. The STA determines the ID of the AP to which it wishes to roam using the Link ID, AP MLD ID, and UHR AP MLD ID (optional). AP 1 transmits to STA 1 whether it accepts the roaming request and the information described in 2.4.2. Roaming Response frame format for APs 4 and 5 via the MLD Roaming Response frame.

[0534] Referring to Figure 51, the transmission and reception process of STA is as follows.

[0535] STA 1 transmits an MLD Roaming Request frame for APs 4 and 5 to AP 1. If STA 1 receives roaming acceptance from AP 1 by receiving an MLD Roaming Response frame, STA 1 roams to AP 4 based on the information about AP 4 it received. After STA 1's roaming is complete, STA 2 also roams to AP 4 based on whether STA 1 accepted AP 5 and the information about APs 4 and 5.

[0536] 3) Example #3 - Procedure to perform temporary add and delete respectively (If using Timer, these procedures can be performed simultaneously)

[0537] Figure 52 illustrates Example 3 for the MLD Roaming procedure.

[0538] Figure 52 is an example in which STA 1 first adds AP 4 and STA 2 temporarily adds AP 5, and then deletes AP 1 and AP 3, respectively.

[0539] In this example, for the Temporary add presented above, first, STA 1 and AP 1 or STA 2 and AP 3 can exchange MLD Roaming Request / Response. 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 include information about AP 4 and AP 5 in the Basic Multi-link IE along with whether to accept it. When this process is completed, STA 1 will be temporarily connected to AP 1 and AP 4, and STA 2 will be connected to AP 3 and AP 5. STA 1 can transmit or receive data from AP 1 and AP 4. That is, when exchanging frames with AP 1, it cannot exchange frames with AP 4. Next, STA 1 performs a Temporary delete (or delete) operation on AP 1, STA 2, and AP 3. Through this procedure, STA 1 completes roaming to AP 4, and STA 2 completes roaming to AP 5.

[0540] The above example is a procedure that performs temporary add and delete respectively. If a timer is used here, these procedures can be performed simultaneously. For example, STA 1 and AP 1 or STA 2 and AP 3 can exchange MLD Roaming Request / Response. At this time, in the MLD Roaming Request, AP 1 and AP 3 simultaneously request Delete (or Temporary Delete), and AP 4 and AP 5 request Temporary add. At this time, the MLD Roaming Timer presented above is set. As mentioned above, non-AP MLD or AP MLD can set this through the MLD Roaming Response. After the MLD Roaming Response is successfully transmitted, the timer starts running, and when the timer expires, the AP 1 link is deleted from STA 1, and AP 4 is fully connected, and AP 3 is deleted from STA 2, and AP 5 is fully connected.

[0541] Figure 53 shows the operation process of Example 3 for the MLD Roaming procedure.

[0542] Referring to Figure 53, the transmission and reception process of the AP is as follows.

[0543] AP 1 receives a Roaming Request frame from STA 1. The STA checks the ID of the AP to which it wants to roam using the Link ID, AP MLD ID, and UHR AP MLD ID (optional). AP 1 sends STA 1 whether it accepts the connection and the information described in 2.4.2. Roaming Response frame format for APs 4 and 5 via the MLD Roaming Response frame. AP 1 sets the MLD Roaming Timer. At this time, when the MLD Roaming Timer times out, the existing connection is completely deleted and the roamed AP is completely connected.

[0544] Referring to Figure 53, the transmission and reception process of STA is as follows.

[0545] STA 1 sends an MLD Roaming Request frame for APs 4 and 5 to AP 1. If STA 1 receives roaming acceptance from AP 1 by receiving an MLD Roaming Response frame, STA 1 roams to AP 4 based on the information about AP 4 it received. After STA 1's roaming is complete, STA 2 also roams to AP 4 based on whether it accepted AP 5 received from STA 1 and the information about APs 4 and 5. STA 1 sets the MLD Roaming Timer. At this time, when the MLD Roaming Timer times out, the existing connection is completely deleted and the roamed AP is fully connected.

[0546] 4) Examples #4 to #6 - Procedure for deleting and then adding or adding and then deleting

[0547] Figure 54 illustrates Example 4 for the MLD Roaming procedure.

[0548] Figure 51 is an example in which 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.

[0549] In this example, for the delete presented above, STA 1 and AP 1 or STA 2 and AP 3 can first exchange MLD Roaming Request / Response. At this time, the MLD Roaming Request will indicate (Optional) UHR AP MLD, AP MLD ID, and Link ID for AP 4 and AP 5, and AP 1 or AP 3 will include information about AP 4 and AP 5 in the Basic Multi-link IE along with whether to accept this. After this process is complete, STA 1 or STA 2 can disconnect from AP 1 and AP 3. Even when one link is deleted, if data arrives from the AP that performed the link deletion, the STA that has not yet deleted the link can receive it instead, or the UHR AP MLD can send it to the AP to which it will roam after roaming. Next, STA 1 performs an add operation for AP 4, and STA 2 performs an add operation for AP 5. Through this procedure, STA 1 completes roaming to AP 4 and STA 2 completes roaming to AP 5.

[0550] The above example is a procedure for performing temporary add and delete, respectively. If a timer is used here, these procedures can be performed simultaneously. For example, STA 1 and AP 1, or STA 2 and AP 3 can exchange MLD Roaming Request / Response. At this time, in the MLD Roaming Request, AP 1 and AP 3 can request Delete (or Temporary Delete), and AP 4 and AP 5 can request Add (or Temporary Add) simultaneously or individually. At this time, the MLD Roaming Timer presented above is set. As mentioned above, this can be set by non-AP MLD or AP MLD through the MLD Roaming Response. After the MLD Roaming Response is successfully transmitted, the timer starts running, and when the timer expires, the AP 1 link is deleted from STA 1, and AP 4 is fully connected, and STA 2 deletes AP 3, and AP 5 is fully connected.

[0551] Figure 55 shows the operation process of examples 3 and 4 for the MLD Roaming procedure.

[0552] Referring to Figure 55, the transmission and reception process of the AP is as follows.

[0553] AP 1 receives a Roaming Request frame from STA 1. STA 1 and 2 check the IDs of the APs (AP 4, 5) to which they want to roam using the Link ID, AP MLD ID, and UHR AP MLD ID (optional). AP 1 sends STA 1 whether to accept the connection and the information described in 2.3.2. Roaming Response frame format for AP 4 and 5 via the MLD Roaming Response frame. AP 1 sets the MLD Roaming Timer. At this time, when the MLD Roaming Timer times out, the existing connection is completely deleted and the roamed AP is completely connected.

[0554] Referring to Figure 55, the transmission and reception process of STA is as follows.

[0555] STA 1 transmits MLD Roaming Request frames for APs 4 and 5 to AP 1. At this time, STA1 requests Delete (or Temporary Delete) for AP 1 and AP 2, and Temporary Add for AP 4 and AP 5. STA 1 receives MLD Roaming Response frames from AP 1 to determine whether roaming for APs 4 and 5 is accepted and to receive information about the APs (refer to 2.3.1). STA 1 sets the MLD Roaming Timer. At this time, when the MLD Roaming Timer times out, the existing connection is completely deleted and the roamed AP is fully connected.

[0556] Figure 56 illustrates Example 5 for the MLD Roaming procedure.

[0557] Figure 57 illustrates Example 6 for the MLD Roaming procedure.

[0558] Figures 56 and 57 illustrate embodiments of a method for setting the Type field of an MLD Request frame when sending link add and delete requests simultaneously. Figure 56 shows that a non-AP MLD first requests link add in order to roam to a new AP MLD (AP MLD 2), and then a connection is created between STA 1 and AP 4, and then a request is made to delete the connection with AP 1, which was previously connected to STA 1. When requesting Add and Delete, the Link ID and AP MLD ID can be used to request the AP to which the request is sent. When the Delete request is sent and the connection between STA 1 and AP 1 is completely deleted, STA 1 cannot transmit and receive data with AP MLD 1, but STA 2 of the non-AP MLD is connected to AP 3 of AP MLD 1, so the non-AP MLD and AP MLD 1 can transmit and receive data. Therefore, data discontinuity can be reduced during roaming. After the link change of STA 1 is completed, STA 2 can also request a link add to AP 5 and then disconnect from AP 3 to completely roam to the new AP MLD 2. At this time, since AP MLD 1 and AP MLD 2 are affiliated with the same AP MLD for a seamless roaming, the data accumulated in the queue of AP MLD 1 can be transferred to AP MLD 2. Fig. 57 has the same overall roaming procedure as Fig. 56, but the link is deleted first and then a link with AP MLD 2 is added.

[0559] When adding and deleting a Link, you can request it twice by requesting it once in the MLD Roaming Request frame, or you can request both actions in one frame at the same time. In case of requesting it at the same time, in the case of Fig. 56, the MLD Roaming Request frame can be configured in the manner of 3-1) Example of sending Add and delete requests at the same time in 2.4.1 MLD Roaming Request frame format - If you want to add a new link first and delete an existing link, and in the case of Fig. 57, the MLD Roaming Request frame can be configured in the manner of 3-2) Example of sending Add and delete requests at the same time in 2.4.1 MLD Roaming Request frame format - If you want to delete an existing link first and add a new link. That is, the Link Info field can be configured with two Per-STA Profiles (one Per-STA Profile for add, and the other Per-STA Profile for delete). When requesting Add and Delete separately, the configuration of the MLD Roaming Request frame that sends the add / delete request can be configured as follows: 1) If included in the Common Info field of the MLD Roaming Request frame body or Reconfiguration IE, 2-1) If included in the Link Info field of the MLD Roaming Request frame body or Reconfiguration IE, 2-2) If included in the Link Info field of the MLD Roaming Request frame body or Reconfiguration IE.Afterwards, the response to the request is received as an MLD Roaming Response frame, and the status code can be used to determine whether the MLD Roaming Request frame is accepted or rejected.

[0560] Additionally, in order for STA 1 to completely transition from AP 1 to AP 4, processes such as those in FIGS. 58 and 59 are required.

[0561] Figure 58 shows an example of MLD Roaming using TIM.

[0562] AP 1 notifies STA 1 via TIM whether it has DL data to transmit via Beacon. At this time, STA 1 transmits MLD Roaming Request to add AP 4 for roaming. Note that this example only includes STA 1, but it can also request link addition of AP 5 to STA 2, as shown in FIG. 44. AP 1 confirms this and responds with accept to AP 4. However, STA 1 may have received information that it is not currently buffering DL data from the latest Beacon of AP 1, or it may have buffered it but not yet received it. Therefore, AP 1 can notify STA 1 that AP 4 or UHR AP MLD has the DL data. In other words, when switching to AP 4, STA 1 can receive DL data from AP 4 through PS-poll transmission without waiting for the Beacon to be received. To achieve this, additional information needs to be indicated in the MLD Roaming Response frame, which is as follows:

[0563] -> TIM (Traffic Indication Map) field (e.g., 1 bit): This indicates that the corresponding AP or AP MLD is buffering DL data for the currently requesting STA.

[0564] From an MLD-level perspective, if the UHR AP MLD indicates that it is buffering DL data for the requesting STA, the TIM field may be included in the MLD Roaming Response frame body or Common Info field.

[0565] From the perspective of the AP, for example, if it is notified that AP 4 has DL data before switching to AP 4, the TIM field can be included in the Link Info field.

[0566] Meanwhile, an STA (e.g., STA 1) can additionally use the MLD Roaming Timer of the MLD Roaming Response frame to determine the time to switch. For example, if there is still a lot of time left until data is received from the AP to which it is currently roaming (e.g., AP 4) before switching, STA 1 can first receive DL data from the currently connected AP (e.g., AP 1) through PS-Poll (if necessary) and then switch. Alternatively, if there is still time to receive data from AP 4 even if it switches immediately, STA 1 can switch immediately.

[0567] Figure 59 shows the operation process for the MLD Roaming procedure using TIM.

[0568] Referring to Figure 59, the transmission and reception process of the AP is as follows.

[0569] AP 1 notifies STA 1 via TIM whether it has DL data to transmit via Beacon. Upon receiving the Roaming Request, AP 1 responds with accept to AP 4 (+AP 5). AP 1 then informs who has the DL data. The AP or UHR AP MLD that has the DL data transmits the DL data to STA 1 (+STA 2). Upon receiving a connection deletion request from an STA, AP 1 (+AP 3) deletes the existing connection.

[0570] Referring to Figure 59, the transmission and reception process of STA is as follows.

[0571] STA 1 performs roaming and transmits an MLD Roaming Request to add AP 4. At this time, it can also request the addition of a link for AP 5 to STA 2. STA 1 receives information about DL data. STA 1 (+STA 2) performs roaming to AP 4 (+AP 5). STA 1 (+STA 2) transmits a PS-Poll to AP 4 (+AP 5) and receives the corresponding DL data. STA 1 (+STA 2) requests link deletion to AP 1 (+AP 3).

[0572] 2.6 Link Add and Delete Request and Response

[0573] Adding a new link or deleting an existing link during the Roaming process requires a request process and a confirmation process after the link has been added or deleted. Link addition and deletion are processes performed after the Roaming Request. Link addition / deletion can be performed using the link specified in the Roaming Request frame, or a Link Reconfiguration Request / Response frame can be sent to request a Link Add / Delete.

[0574] Figure 60 illustrates an example of the Add link process.

[0575] Figure 61 illustrates an example of the Add link process through a Roaming Request frame.

[0576] Figure 61 illustrates a method for simultaneously requesting an Add link when sending a Roaming Request. When a non-AP MLD STA sends a Roaming Request, it can request an Add link by including information on the link to be added in the Roaming Request frame. When an AP MLD sends a Roaming Request, it can include information on the link to be added in the AP MLD. There can be more than one link to be added, and when a link is created and the AP MLD sends an Add link confirmation, a Context Transfer is performed and a Roaming Response is transmitted to confirm the completion of the Context Transfer.

[0577] Figure 62 illustrates an example of the Delete link process.

[0578] Figures 60 and 62 show examples of the process of adding and deleting links. First, when a non-AP MLD STA creates a link with a new AP MLD, either the non-AP MLD STA or the AP MLD may request Add link. The request for Add link can be made using the Link Reconfiguration Request frame or the Roaming Request frame. At this time, if there is an already added link between the non-AP MLD and the target AP MLD and it is connected to the target AP MLD, the target AP MLD requests Add link or requests Add link from the target AP MLD. If there is no added link between the non-AP MLD and the target AP MLD and it is connected to the serving AP MLD, the serving AP MLD requests Add link or requests Add link from the serving AP MLD. After the Add link request is accepted and a link is created, the target AP MLD can send a confirmation that the add link has been completed as a new link. At this time, confirmation can be transmitted using the Link Reconfiguration Response frame or the Roaming Response frame.

[0579] The Delete link process, which deletes a link connected to a non-AP MLD STA and a serving AP MLD, is similar to the Add link process. Either the non-AP MLD STA or the target AP MLD can request a Delete link. The Delete link request can be made using the Link Reconfiguration Request frame or the Roaming Request frame. When the Delete link request is sent and the requested link is deleted, the target AP MLD notifies the non-AP MLD STA of the link deletion via the Delete Link Response.

[0580] Figure 63 shows an example of the process of setting a Delete Timer.

[0581] A request for a delete link can be made using a Link Reconfiguration Request frame or a Roaming Request frame. At this time, a Delete Timer is set, and the requested link must be deleted when the Timer value becomes 0. From the moment the Delete Timer becomes 0, the non-AP MLD STA and the Target AP MLD can implicitly know that the delete link has been completed.

[0582] Figure 64 illustrates the process of transmitting and receiving a frame for adding a link.

[0583] Referring to Figure 64, the transmission and reception process of AP MLD is as follows.

[0584] The AP MLD transmits and receives an Add link Request frame (Link Reconfiguration Request frame or Roaming Request frame) for the AP MLD requested in the Roaming Request frame. Once the link is created, the AP MLD transmits an Add link response frame (Link Reconfiguration Response frame or Roaming Response frame) to indicate that the add link has been completed.

[0585] Referring to Figure 64, the transmission and reception process of non-AP MLD is as follows.

[0586] The non-AP MLD transmits and receives an Add link Request frame (Link Reconfiguration Request frame or Roaming Request frame) to the AP MLD requested in the Roaming Request frame. The non-AP MLD confirms that the add link has been completed through the Link Reconfiguration Response frame or Roaming Response frame.

[0587] Figure 65 illustrates the process of transmitting and receiving a frame for adding a link through a Roaming Request frame.

[0588] Referring to Figure 65, the transmission and reception process of AP MLD is as follows.

[0589] The AP MLD sends and receives Roaming Request frames, requests Add links, or receives Add link requests. Once the requested link(s) are added, the AP MLD sends Add link Confirmation. After context transfer, the AP MLD sends a Roaming Response frame.

[0590] Referring to Figure 65, the transmission and reception process of non-AP MLD is as follows.

[0591] Non-AP MLDs send and receive Roaming Request frames, requesting or receiving Add link requests. Non-AP MLDs receive Add link Confirmation. Non-AP MLDs receive Roaming Response frames.

[0592] Figure 66 illustrates the process of transmitting and receiving a frame for deleting a link.

[0593] Referring to Figure 66, the transmission and reception process of AP MLD is as follows.

[0594] The AP MLD transmits and receives a Delete link Request frame (Link Reconfiguration Request frame or Roaming Request frame) to the AP MLD requested in the Roaming Request frame. When the link is created, the AP MLD transmits a Delete link response frame (Link Reconfiguration Response frame or Roaming Response frame) to indicate that the delete link has been completed.

[0595] Referring to Figure 66, the transmission and reception process of non-AP MLD is as follows.

[0596] The non-AP MLD transmits and receives a Delete link Request frame (Link Reconfiguration Request frame or Roaming Request frame) to the AP MLD requested in the Roaming Request frame. The non-AP MLD confirms that the Delete link has been completed through the Link Reconfiguration Response frame or Roaming Response frame.

[0597] Figure 67 illustrates the process of transmitting and receiving a frame for Delete link using a delete timer.

[0598] Referring to Figure 67, the transmission and reception process of AP MLD is as follows.

[0599] The AP MLD transmits and receives a Delete link Request frame (Link Reconfiguration Request frame or Roaming Request frame) for the AP MLD requested in the Roaming Request frame. A Delete Timer can be set based on the Delete link Request frame. When the Delete Timer reaches 0, it indicates that the link has been deleted. (That is, there is no need to send a separate Delete link response frame.)

[0600] Referring to Figure 67, the transmission and reception process of non-AP MLD is as follows.

[0601] The non-AP MLD sends and receives a Delete link Request frame (Link Reconfiguration Request frame or Roaming Request frame) to the AP MLD requested in the Roaming Request frame. When the Delete Timer reaches 0, it indicates that the link has been deleted (i.e., there is no need to send a separate Delete link response frame).

[0602] Figure 68 illustrates a first embodiment of a process for setting a Delete Timer.

[0603] Figure 69 illustrates a second embodiment of the process for setting a Delete Timer.

[0604] When deleting a link connected to a Non-AP MLD STA and a Serving AP MLD, link deletion can be performed in an unsolicited manner without a separate Request / Response request, as in Add link. In the case of Fig. 68, when Link Add is performed, a Delete Link request is also made at the same time, and when a Link Add Response is received, the link deletion is known to be complete. Alternatively, the completion of the deletion can be implicitly notified when a Roaming Response frame sending a Context Transfer Confirmation is sent, as in Fig. 69.

[0605] Figure 70 illustrates a process for notifying Link Delete in an unsolicited manner by transmitting an Add Link Response.

[0606] Referring to Figure 70, the transmission and reception process of AP MLD is as follows.

[0607] The AP MLD transmits and receives an Add link Request frame (Link Reconfiguration Request frame or Roaming Request frame) for the AP MLD requested in the Roaming Request frame. At this time, a request for a Delete link is also simultaneously made through the Add link Request frame. When a link is created, the AP MLD transmits an Add link response frame (Link Reconfiguration Response frame or Roaming Response frame) to notify that the add link has been completed. At this time, it can also be notified through the Add link response frame that the link has been deleted.

[0608] Referring to Figure 70, the transmission and reception process of non-AP MLD is as follows.

[0609] The Non-AP MLD transmits and receives an Add link Request frame (Link Reconfiguration Request frame or Roaming Request frame) to the AP MLD requested in the Roaming Request frame. At this time, a request for a Delete link is also simultaneously made through the Add link Request frame. The Non-AP MLD confirms that the add link has been completed through the Link Reconfiguration Response frame or Roaming Response frame. At this time, it can also know that the link has been deleted through the Add link response frame.

[0610] Figure 71 illustrates a process for notifying Link Delete in an unsolicited manner by transmitting a Roaming Response frame.

[0611] Referring to Figure 71, the transmission and reception process of AP MLD is as follows.

[0612] The AP MLD transmits and receives an Add link Request frame (Link Reconfiguration Request frame or Roaming Request frame) for the AP MLD requested in the Roaming Request frame. At this time, a request for a Delete link is also simultaneously made through the Add link Request frame. When a link is created, the AP MLD transmits an Add link response frame (Link Reconfiguration Response frame or Roaming Response frame) to indicate that the add link has been completed. Context Transfer is performed from the Serving AP MLD to the Target AP MLD. The Target AP MLD transmits a Roaming Response frame to indicate that the Context Transfer has been completed. At this time, it can be simultaneously notified through the Roaming Response frame that the link has been deleted.

[0613] Referring to Figure 71, the transmission and reception process of non-AP MLD is as follows.

[0614] The Non-AP MLD transmits and receives an Add link Request frame (Link Reconfiguration Request frame or Roaming Request frame) to the AP MLD requested in the Roaming Request frame. At this time, a request for a Delete link is also simultaneously made through the Add link Request frame. The Non-AP MLD confirms that the add link has been completed through the Link Reconfiguration Response frame or the Roaming Response frame. The Non-AP MLD receives a Roaming Response frame indicating that the Context Transfer has been completed. At this time, it can also be known through the Roaming Response frame that the link has been deleted.

[0615] 2.7. Context Transfer Level

[0616] To prevent data discontinuity due to phenomena such as packet loss when a non-AP STA roams to a new AP MLD, context transfer can be used, as shown in the example in FIG. 70 described below, to preemptively transmit necessary information from the previously connected AP MLD to the new AP MLD before the non-AP STA roams. At this time, the non-AP STA waits for the context transfer time after requesting roaming and performs roaming. The delay caused by the context transfer increases as the amount of information to be transferred increases. Here, we define the concept of Context Transfer Level, which allows only the necessary information to be transferred to avoid delays caused by unnecessary context transfers in situations where context transfer is not necessary. The non-AP STA can specify the Context Transfer Level when making a Roaming Request, or the Serving AP MLD can specify it and notify the non-AP STA of it. If a non-AP MLD STA does not need to know the Context Transfer Level, it may not inform the non-AP MLD STA of the Context Transfer Level.

[0617] The Context Transfer Level can be set in at least one of the following ways:

[0618] 1) Accumulation method

[0619] Context Transfer Level = 0: Transfer a context called A

[0620] Context Transfer Level = 1: Transfer contexts called A + B

[0621] …

[0622] As above, this is a method that includes contexts transferred to the previous Context Transfer Level and new contexts.

[0623] Examples of contexts being transferred, such as A and B, can be as follows.

[0624] A = SN(Sequence Number)

[0625] B = PN(Packet Number)

[0626] C = BA agreement

[0627] D = BA parameters

[0628] …

[0629] The above example is only one example and is not limited to this one. Furthermore, more contexts can be defined than the examples mentioned.

[0630] 2) Independent method

[0631] Context Transfer Level = 0: Context A

[0632] Context Transfer Level = 1: Context B

[0633] …

[0634] In the independent method, you can send only one Context by selecting only one Context Transfer Level, or you can transfer multiple Contexts by selecting multiple Context Transfer Levels.

[0635] If you select Context Transfer Level 1, only Context B will be transferred, and if you select Context Transfer Level 0, 1, both Context A and B will be transferred.

[0636] Examples of Context A and B may be the same as the examples in 1) Accumulation method.

[0637] 3) Bitmap

[0638] As an alternative to methods 1) and 2), you can set the level for Context Transfer with a Bitmap.

[0639] For example, if the above Bitmap is X bit, B0 can be set as Context A, B1 as Context B, etc.

[0640] Also, 2) like the Independent method, you can combine multiple bits to transfer multiple types of contexts rather than just one type of context.

[0641] As another example, you can set the Context information according to the bit value as follows:

[0642] Context Transfer LevelContext Transferred0No Context transfer1SN / PN2BA Agreement3Packet Reordering4-15Reserved

[0643] For example, if roaming is possible with only entity or UHR MLD without context transfer, set the Context Transfer Level to 0. If only SN / PN information needs to be transferred with Context Transfer, set the Context Transfer Level to 1. The context included in the value of the Context Transfer Level can be accumulated. If the Context Transfer Level is set to 3, Context Transferred items with values ​​of 1 and 2 are included. The Accumulation method is one of many methods and is not limited to the above method.

[0644] <Context transfer를 이용한 Roaming Procedure>

[0645] Figure 72 illustrates an example of a Roaming Procedure using Context transfer (only entities exist).

[0646] Figure 72 is an example of a roaming process when context transfer is present. When a non-AP MLD sends a Roaming Request, the process is the same as Figure 73. First, a non-AP STA transmits the ID information of the AP to be roamed to the UHR AP MLD or AP MLD through the Roaming Request frame to perform roaming. In addition, the contexts to be transferred can be specified using the Context Transfer Level field of the Roaming Request frame. The UHR AP MLD or AP MLD that receives the Roaming Request frame informs whether roaming to the requested AP is possible and the Context Transfer Level through the transmission of the Roaming Response frame. Upon receiving the Roaming Request frame from the non-AP MLD, the UHR AP MLD or AP MLD transmits the control contexts to be transferred, set in the Context Transfer Level, to the AP MLD to be roamed through the DS. If the Context Transfer Level is set to 0, no context transfer is performed. When the context transfer is complete, the AP MLD requests a link add to the non-AP MLD, and when a link is formed between the AP MLD to which roaming is to be performed and the non-AP MLD, in the case of DL (downlink), the packets that were queued but not transmitted by roaming are transmitted to the non-AP STA by the AP MLD after roaming based on the SN / PN information received through the context transfer to the AP MLD before roaming. After that, new packets received from the DS are received by the AP MLD after roaming.For UL, a non-AP STA transmits a packet to the AP MLD after roaming. The AP MLD requests link deletion for all links connected to the AP MLD and the non-AP STA before roaming. Once all links are deleted, the roaming process ends.

[0647] Figure 74 illustrates an example process for a case where an AP MLD sends a Roaming Request. When an AP MLD sends a Roaming Request, it can provide capability information regarding the extent to which the AP MLD can transfer context through the Context Transfer Level. In this case, when a non-AP STA sends a Roaming Response, the Context Transfer Level value is set to a value lower than the Context Transfer Level value of the Roaming Request.

[0648] Figure 73 illustrates an example of a roaming process using context transfer.

[0649] Figure 73 is an example of a process when a non-AP MLD sends a Roaming Request.

[0650] Referring to Figure 73, the AP MLD transmission and reception process is as follows.

[0651] The AP MLD receives a Roaming Request frame from the Non-AP MLD. The AP MLD transfers information about the existing AP MLD (Serving AP MLD) and the necessary context to the Target AP MLD to which the Non-AP MLD is roaming. Once the context transfer is complete, the UHR AP MLD (or entity) requests a link add to the Non-AP MLD. After a new link is established, the Target AP MLD transmits packets queued in the existing AP MLD queue using the SN (Sequence Number) / PN (Packet Number) information received through the context transfer in a DL environment. In a UL environment, the Target AP MLD receives frames only through the new link. The Target AP MLD requests a link delete for the link connected to the existing AP MLD.

[0652] Referring to Figure 73, the Non-AP MLD transmission and reception process is as follows.

[0653] The Non-AP MLD transmits a Roaming Request frame to the UHR AP MLD (or Serving AP MLD). The Non-AP MLD receives information about roaming acceptance and APs by receiving the Roaming Response frame. When the Non-AP MLD receives a link add request, it sends and receives frames on the link connected to the new AP MLD (Target AP MLD). When the Non-AP MLD receives a link delete request, it deletes the link connected to the existing AP MLD (Serving AP MLD).

[0654] Figure 74 illustrates another example of a roaming process using context transfer.

[0655] Figure 74 is an example of a process when AP MLD sends a Roaming Request.

[0656] Referring to Figure 74, the AP MLD transmission and reception process is as follows.

[0657] The AP MLD transmits a Roaming Request frame to the Non-AP MLD. The AP MLD conveys information about the existing AP MLD (Serving AP MLD) and the necessary context to the Target AP MLD to which the Non-AP MLD is roaming. When the context transfer is complete, the UHR AP MLD (or entity) requests a link add to the Non-AP MLD. After the new link is formed, the Target AP MLD transmits the packets queued in the existing AP MLD queue using the SN (Sequence Number) / PN (Packet Number) information received through the context transfer in a DL environment. In a UL environment, the Target AP MLD receives frames only through the new link. The Target AP MLD requests a link delete for the link connected to the existing AP MLD.

[0658] Referring to Figure 74, the Non-AP MLD transmission and reception process is as follows.

[0659] The Non-AP MLD receives a Roaming Request frame from the UHR AP MLD (or Serving AP MLD). The Non-AP MLD receives information about roaming acceptance and APs through the Roaming Response frame. When the Non-AP MLD receives a link add request, it sends and receives frames on the link connected to the new AP MLD (Target AP MLD). When the Non-AP MLD receives a link delete request, it deletes the link connected to the existing AP MLD (Serving AP MLD).

[0660] The examples in Figures 75 to 78 may be architectures using entities or MLD based architectures.

[0661] Figure 75 illustrates an example of Context Transfer Confirmation when a Non-AP MLD STA makes a Roaming Request first.

[0662] First, this is when a non-AP MLD STA requests roaming. The non-AP MLD STA triggers roaming by sending a Roaming Request frame to the serving AP MLD. At this time, the desired Context Transfer Level can be specified in the Roaming Request frame and the corresponding value can be reported. After receiving the Roaming Request, the serving AP MLD sends an add link request to the non-AP MLD STA. If this request is accepted and a new link with the target AP MLD is created, the non-AP MLD STA sends an add link confirmation to confirm that the newly created link has been created. If the serving AP MLD confirms that a new link has been created between the target AP MLD and the non-AP MLD STA, it performs a context transfer to the target AP MLD according to the Context Transfer Level setting. Once the context transfer is complete, the target AP MLD can notify the non-AP MLD STA of the completion of the context transfer by including context transfer confirmation information in the Roaming Response.

[0663] Figure 76 is a procedure flow diagram showing the operation of Context Transfer Confirmation when a Non-AP MLD STA makes a Roaming Request first.

[0664] Referring to Figure 76, the AP MLD transmission and reception process is as follows.

[0665] The AP MLD receives the Roaming Request frame from the non-AP MLD and checks the Context Transfer level. The AP MLD transmits an Add Link Request frame with the information about the link to be added included in the Roaming Request frame. A link is created between the AP for which Add is requested and the non-AP MLD STA. If the Serving AP MLD confirms that a new link has been created between the Target AP MLD and the non-AP MLD STA, it performs a context transfer to the Target AP MLD as set in the Context Transfer Level. When the context transfer is completed, the Target AP MLD notifies the non-AP MLD STA that the context transfer is complete by including context transfer confirmation information in the Roaming Response.

[0666] Referring to Figure 76, the non-AP MLD transmission and reception process is as follows.

[0667] The non-AP MLD transmits a Roaming Request frame containing information about the AP to which it wishes to roam to the UHR AP MLD. The Roaming Request frame includes the Context Transfer level information requested by the non-AP MLD STA. The non-AP MLD receives the Add link request frame and creates a link between the requested AP and the non-AP MLD STA. After confirming that the context transfer is complete through the Roaming Response frame, the non-AP MLD can exchange frames with the target AP MLD.

[0668] Figure 77 illustrates an example of Context Transfer Confirmation when AP MLD makes a Roaming Request first.

[0669] When the AP MLD triggers roaming first, the initial steps are different and the process is the same as in FIGS. 75 and 76. The AP MLD sends a Roaming Request to the non-AP MLD STA and informs it of the Context Transfer Level that can transfer context from the Serving AP MLD to the Target AP MLD in advance (Context Transfer Level Capability). The non-AP MLD STA selects a level lower than this Context Transfer Level and informs it of the Roaming Response.

[0670] Figure 78 is a procedure flow diagram showing the operation of Context Transfer Confirmation when AP MLD first makes a Roaming Request.

[0671] Referring to Figure 78, the AP MLD transmission and reception process is as follows.

[0672] When the AP MLD sends a Roaming Request frame to a non-AP MLD STA, it informs the Context Transfer Level that can perform context transfer from the Serving AP MLD to the Target AP MLD in advance (Context Transfer Level Capability). The AP MLD sends an Add Link Request frame with the information on the link to be added included in the Roaming Response frame. A link is created between the AP for which Add is requested and the non-AP MLD STA. If the Serving AP MLD confirms that a new link has been created between the Target AP MLD and the non-AP MLD STA, it performs context transfer to the Target AP MLD as set in the Context Transfer Level. When the context transfer is complete, the Target AP MLD notifies the non-AP MLD STA that the context transfer is complete by including context transfer confirmation information in the Roaming Response frame.

[0673] Referring to Figure 78, the non-AP MLD transmission and reception process is as follows.

[0674] The non-AP MLD transmits a Roaming Response frame containing information about the AP to which it wishes to roam to the UHR AP MLD. The Roaming Response frame selects a level lower than the Context Transfer level. The non-AP MLD receives the Add link request frame and creates a link between the requested AP and the non-AP MLD STA. After confirming that the context transfer is complete through the Roaming Response frame, the non-AP MLD can exchange frames with the target AP MLD.

[0675] Figure 79 illustrates an embodiment 1 of a Seamless Roaming process using context transfer.

[0676] Figure 79 illustrates an example of a method for sending UL / DL data intermediately before all links are transferred. The method for sending a Roaming Request is described in Figures 73 and 74. Following the process in Figure 77, UL / DL data can be sent using the newly added link. However, since the link must be deleted and other links added, only a certain amount of data is transmitted and received. At this time, the remaining links can be used to send data packets that must be transmitted quickly, such as low-latency traffic. Afterwards, the link connected to the Serving AP MLD of the non-AP STA connected to the Target AP MLD is deleted. Once the link is deleted, a confirmation message is sent indicating the deletion. The deletion process can be performed by setting a timer or using an unsolicited method. Once the link deletion is complete, the remaining non-AP STAs are added. After link creation is complete, two or more links can be connected to the Target AP MLD. Therefore, you can make requests such as delete link through one link and receive UL / DL data through the remaining links.

[0677] Figure 80 illustrates a flowchart of Embodiment 1 of a Seamless Roaming process using context transfer.

[0678] Referring to Figure 80, the AP MLD transmission and reception process is as follows.

[0679] If there are packets accumulated in the buffer received from the Serving AP MLD, the Target AP MLD transmits them to the non-AP STA. If there is low-latency traffic, it can transmit them first. After transmitting a certain amount of data, the Target AP MLD transmits a delete request for the link previously connected to the Serving AP MLD through the newly connected link. When the link deletion is complete, it notifies the non-AP MLD of the completion. The Target AP MLD requests or receives requests for new links (same as the Add link process). After transmitting confirmation that a new link has been created, transmission and reception of UL / DL data begins. The delete process is performed using a link on which no UL / DL data is transmitted.

[0680] Referring to Figure 80, the non-AP MLD transmission and reception process is as follows.

[0681] Non-AP MLD transmits data that could not be transmitted due to the inevitable delay during the roaming process. If low-latency traffic exists, it can be transmitted preferentially. After transmitting a certain amount of data, a delete request for the link previously connected to the Serving AP MLD is sent through the newly connected link. The deletion of the link is confirmed. Non-AP MLD requests or receives requests for new links (same as the Add link process). After transmitting confirmation that a new link has been created, transmission and reception of UL / DL data begins. The delete process is performed using the link on which UL / DL data is not being transmitted.

[0682] As shown in Figure 81, the following process is required for STA 1 to completely move from AP 1 to AP 4.

[0683] Figure 81 illustrates an embodiment 2 of a Seamless Roaming process using context transfer.

[0684] Figure 81 is an example of a process for transmitting UL / DL data after all links are created with the Target AP MLD. The method for sending a Roaming Request is described in Figures 73 and 74. After the process of Figure 77 is completed and the AP MLD transmits a Roaming Response, the link connected to the Serving AP MLD of the non-AP STA connected to the Target AP MLD is deleted. When the link is deleted, a confirmation that it has been deleted is sent. Once the Delete Link is completed, add links are performed with the remaining non-AP STAs. After link creation is complete, two or more links can be connected to the Target AP MLD. Unlike Figure 79, data transmission and reception are possible from this point onward, and requests such as a delete link can be made through one link, and UL / DL data can be received through the remaining links.

[0685] Figure 82 illustrates a flowchart of Embodiment 2 of a Seamless Roaming process using context transfer.

[0686] Referring to Figure 82, the AP MLD transmission and reception process is as follows.

[0687] After transmitting the Roaming Response, the Target AP MLD transmits / receives a delete request for the link previously connected to the Serving AP MLD through the newly connected link. Once the link deletion is complete, the Target AP MLD notifies the non-AP MLD of the completion. The Target AP MLD requests or receives requests for new links (same as the Add link process). After transmitting confirmation that a new link has been created, transmission and reception of UL / DL data begins. The Target AP MLD performs the delete process using a link on which no UL / DL data is transmitted.

[0688] Referring to Figure 82, the non-AP MLD transmission and reception process is as follows.

[0689] After receiving the Roaming Response, the Non-AP MLD sends / receives a delete request for the link previously connected to the Serving AP MLD through the newly connected link. The Non-AP MLD confirms that the link has been deleted. The Non-AP MLD requests or receives requests for new links (same as the Add link process). After transmitting confirmation that a new link has been created, transmission and reception of UL / DL data begins. The delete process is performed using a link on which no UL / DL data is transmitted.

[0690] Figure 83 illustrates an example of a Seamless Roaming process using context transfer (Add Link All at Once).

[0691] Figure 83 is an example of a process for requesting all links to be created simultaneously between a Target AP MLD and a non-AP MLD STA. The method for sending a Roaming Request is described in Figures 75 and 76. After the process of Figure 77 is completed and the AP MLD transmits a Roaming Response, UL / DL data transmission and reception can begin. A link that is not transmitting or receiving UL / DL data can be used to request deletion of a link connected to the Serving AP MLD.

[0692] Figure 84 illustrates a procedure diagram of an example of a Seamless Roaming process using context transfer (Add Link All at Once).

[0693] Referring to Figure 84, the AP MLD transmission and reception process is as follows.

[0694] After transmitting a Roaming Response, the AP MLD requests or receives requests for all new links. The AP MLD transmits and receives UL / DL data. It performs a delete process using links that do not transmit UL / DL data.

[0695] Referring to Figure 84, the non-AP MLD transmission and reception process is as follows.

[0696] After receiving a Roaming Response, the non-AP MLD receives requests or requests for all new links. The non-AP MLD transmits and receives UL / DL data. It performs the delete process using links where UL / DL data is not transmitted.

[0697] Figure 85 illustrates another example of a Seamless Roaming process using context transfer (Delete Link All at Once).

[0698] Figure 85 has a similar operation process to Figure 83, but deletes links all at once. Therefore, when requesting link deletion, rather than requesting deletion for each link individually, it requests deletion for all links connected to the Serving AP MLD.

[0699] Figure 86 illustrates a procedure diagram of another example of a Seamless Roaming process using context transfer (Delete Link All at Once).

[0700] Referring to Figure 86, the AP MLD transmission and reception process is as follows.

[0701] The AP MLD transmits a Roaming Response. After all links that should be connected to the Target AP MLD are connected, UL / DL data is transmitted and received. The Target AP MLD transmits and receives link delete requests for all links connected to the Serving AP MLD. The Target AP MLD transmits confirmation that all links have been deleted.

[0702] Referring to Figure 86, the non-AP MLD transmission and reception process is as follows.

[0703] The non-AP MLD receives a Roaming Response. After all links that should be connected to the Target AP MLD are connected, the non-AP MLD sends and receives UL / DL data. The non-AP MLD then sends and receives link delete requests for all links connected to the Serving AP MLD. The non-AP MLD receives confirmation that all links have been deleted.

[0704] 2.8 Channel

[0705] 2.8.1 Same Channel

[0706] During the Seamless Roaming process, when a non-AP STA is connected to two AP MLDs simultaneously, simultaneous data transmission and reception are possible if these two connections are using the same channel.

[0707] Figure 87 illustrates an example in which a link between a non-AP STA and two AP MLDs uses the same channel during a seamless roaming process.

[0708] As shown in Figure 87, when a non-AP MLD performs an add link with a new AP MLD and is connected to a new link while the connection with the existing AP MLD remains, if these two connections are on the same channel, one link can be used for UL data transmission and the other link for DL ​​data transmission. It can also be used to transmit packets that were not transmitted before roaming.

[0709] Figure 88 illustrates an example in which a link between a non-AP STA and two AP MLDs uses the same channel during a seamless roaming process.

[0710] The process in Figure 88 shows an example of how to individually add and delete links and receive a separate confirmation frame for each request. After the context transfer is completed and the link between the non-AP MLD and the target AP MLD is created, since the link connected to the Serving AP MLD and the link connected to the target AP MLD use the same channel, UL data transfer can be performed on one link and DL data transfer on the other. This process can be maintained until the non-AP MLD completely transfers all links to the target AP MLD.

[0711] Figure 89 illustrates another example where a link between a non-AP STA and two AP MLDs uses the same channel during a Seamless Roaming process.

[0712] Figure 89 simultaneously requests Add link for new links and Delete link for existing links when transmitting a Roaming Request. When the requested links are connected, an Add link response is transmitted, which involves UL / DL data transmission with the Serving AP MLD. This UL / DL transmission is stopped, the DS Mapping is changed from the serving AP MLD to the Target AP MLD, and the context transfer step is performed. At this time, the DS Mapping change can be performed first and the context transfer can be performed later, or the context transfer can be performed first and then the DS Mapping change can be performed.

[0713] 2.9. Order of the Context Transfer and DS Mapping Change

[0714] Figure 90 illustrates an example of the Context Transfer and DS Mapping Change sequence.

[0715] When a Roaming Request is transmitted and a new link is established between the Target AP MLD and a Non-AP MLD STA, the Serving AP MLD can transfer context to the Target AP MLD via Over the DS or Over the Air. Before transmitting the Roaming Response, the context transfer and DS Mapping must be transferred from the Serving AP MLD to the Target AP MLD. At this time, the DS Mapping Change can be performed first and then the context transfer, or conversely, the context transfer can be performed first and then the DS Mapping Change. If the context transfer is performed first, the context transfer can be performed for the SN or PN information queued in the Serving AP MLD that has not yet been transmitted to the Serving AP MLD since the context transfer started. When the DS Mapping change is made to the Target AP MLD, the SN and PN of new packets accumulated in the Target AP MLD via the DS are set to the values ​​after the SN and PN of the context transfer. In addition to the SN / PN information, information on all contexts to be transferred is transferred as related contexts up to the point where the Context Transfer starts. If the DS Mapping Change is performed first, the contexts up to the point right before the DS Mapping is moved from the Serving AP MLD to the Target AP MLD are transferred. In other words, if the DS mapping change is performed first, the contexts queued in the serving AP MLD before the DS mapping change are transferred.

[0716] What both cases have in common is that at the time of context transfer, the contexts are transferred up to the context information accumulated in the queue of the Serving AP MLD.

[0717] The context transferred may also include contexts related to Block Ack (BA). It can convey context related to the BA parameter set of the ADDBA frame (Buffer size, WinSize, etc.), and the context may include information such as which TID (Traffic Identifier) ​​the BA agreement / BA parameters are for, or whether they are for all TIDs.

[0718] The specific explanation for the case where Context Transfer is performed before DS mapping change is as follows.

[0719] Among the items to be context transferred, in the case of SN, the value corresponding to the last SN of the queued packet of the serving AP MLD is transferred just before the context transfer. However, since the DS mapping change has not been made yet, there is a concern that the serving AP MLD may receive a new packet from the DS even after the context transfer is performed. In this case, a duplication issue may occur because the same SN value is assigned to packets of both the serving AP MLD and the target AP MLD (i.e., because they are assigned to different packets). Therefore, when performing a context transfer for SN, if last SN + a is performed, the duplication issue can be resolved even if additional packets are queued in the serving AP MLD.

[0720] Figure 91 illustrates an example of DS Mapping Change and Update.

[0721] Referring to FIG. 91, a Non-AP MLD STA can transmit and receive a Roaming Request frame with a Serving AP MLD. If a link is formed between the Non-AP MLD STA and the Target AP MLD based on the Roaming Request frame, the DS mapping can be changed and updated from the Serving AP MLD to the Target AP MLD. Thereafter, the Non-AP MLD STA can transmit and receive a Roaming Response frame with the Serving AP MLD.

[0722] Figure 92 illustrates an example 1 of a procedure diagram for DS Mapping Change and Update.

[0723] Figure 92 illustrates the procedure when a Non-AP MLD sends a Roaming Request and when a Non-AP MLD sends a Roaming Response.

[0724] Referring to Figure 92, the Serving AP MLD transmission and reception process is as follows.

[0725] The Serving AP MLD receives a Roaming Request frame. The DS mapping changes from the Serving AP MLD to the Target AP MLD. Once a link is established between the Target AP MLD and the non-AP MLD, the Serving AP MLD receives a Roaming Response frame from the non-AP MLD.

[0726] Referring to Figure 92, the non-AP MLD transmission and reception process is as follows.

[0727] The non-AP MLD sends a Roaming Request frame to the Serving AP MLD. The DS mapping changes from the Serving AP MLD to the Target AP MLD. Once a link is established between the Target AP MLD and the non-AP MLD, the non-AP MLD sends a Roaming Response frame to the Serving AP MLD.

[0728] Figure 93 illustrates an example 2 of a procedure diagram for DS Mapping Change and Update.

[0729] Figure 93 illustrates the procedure when AP MLD sends Roaming Request and when Non-AP MLD sends Roaming Response.

[0730] Referring to Figure 93, the Serving AP MLD transmission and reception process is as follows.

[0731] The Serving AP MLD transmits a Roaming Request frame. The DS mapping changes from the Serving AP MLD to the Target AP MLD. Once a link is established between the Target AP MLD and the non-AP MLD, the Serving AP MLD receives a Roaming Response frame from the non-AP MLD.

[0732] Referring to Figure 93, the non-AP MLD transmission and reception process is as follows.

[0733] The non-AP MLD receives a Roaming Request frame from the Serving AP MLD. The DS mapping changes from the Serving AP MLD to the Target AP MLD. Once a link is established between the Target AP MLD and the non-AP MLD, the non-AP MLD sends a Roaming Response frame to the Serving AP MLD.

[0734] Figure 94 illustrates an example 3 of a procedure diagram for DS Mapping Change and Update.

[0735] Figure 94 illustrates the procedure when a non-AP MLD sends a Roaming Request and when an AP MLD sends a Roaming Response.

[0736] Referring to Figure 94, the Serving AP MLD transmission and reception process is as follows.

[0737] The Serving AP MLD receives the Roaming Request frame. The DS mapping changes from the Serving AP MLD to the Target AP MLD. Once a link is established between the Target AP MLD and the non-AP MLD, the Serving AP MLD sends a Roaming Response frame to the non-AP MLD.

[0738] Referring to Figure 94, the non-AP MLD transmission and reception process is as follows.

[0739] The non-AP MLD sends a Roaming Request frame to the Serving AP MLD. The DS mapping changes from the Serving AP MLD to the Target AP MLD. Once a link is established between the Target AP MLD and the non-AP MLD, the non-AP MLD receives a Roaming Response frame from the Serving AP MLD.

[0740] Figure 95 illustrates an example 4 of a procedure diagram for DS Mapping Change and Update.

[0741] Figure 95 illustrates the procedure when a non-AP MLD sends a Roaming Request and when an AP MLD sends a Roaming Response.

[0742] Referring to Figure 95, the Serving AP MLD transmission and reception process is as follows.

[0743] The Serving AP MLD transmits a Roaming Request frame. The DS mapping changes from the Serving AP MLD to the Target AP MLD. Once a link is established between the Target AP MLD and the non-AP MLD, the Serving AP MLD transmits a Roaming Response frame to the non-AP MLD.

[0744] Referring to Figure 95, the non-AP MLD transmission and reception process is as follows.

[0745] The non-AP MLD receives a Roaming Request frame from the Serving AP MLD. The DS mapping changes from the Serving AP MLD to the Target AP MLD. Once a link is established between the Target AP MLD and the non-AP MLD, the non-AP MLD receives a Roaming Response frame from the Serving AP MLD.

[0746] Figure 96 is a flowchart illustrating the operation of a transmitting device according to the present embodiment.

[0747] An example of FIG. 96 may be performed at a transmitting STA or transmitting device (AP and / or non-AP STA).

[0748] Some of the steps (or detailed sub-steps described below) in the example of Fig. 96 may be omitted or changed.

[0749] Through step S9610, the transmitting device (transmitting STA) can obtain information regarding the aforementioned Tone Plan. As described above, the information regarding the Tone Plan includes the size and location of the RU, control information related to the RU, information regarding the frequency band in which the RU is included, information regarding the STA receiving the RU, etc.

[0750] Through step S9620, the transmitting device can configure / generate a PPDU based on the acquired control information. The step of configuring / generating the PPDU may include a step of configuring / generating each field of the PPDU. That is, step S9620 may include a step of configuring an EHT-SIG field including control information regarding a Tone Plan. That is, step S9620 may include a step of configuring a field including control information indicating the size / position of an RU (e.g., an N bitmap) and / or a step of configuring a field including an identifier (e.g., an AID) of an STA receiving the RU.

[0751] Additionally, step S9620 may include a step of generating an STF / LTF sequence to be transmitted through a specific RU. The STF / LTF sequence may be generated based on a preset STF generation sequence / LTF generation sequence.

[0752] Additionally, step S9620 may include a step of generating a data field (i.e., MPDU) to be transmitted via a specific RU.

[0753] The transmitting device can transmit the PPDU configured through step S9620 to the receiving device based on step S9630.

[0754] While performing step S9630, the transmitting device may perform at least one of operations such as CSD, Spatial Mapping, IDFT / IFFT operation, and GI insertion.

[0755] A signal / field / sequence configured according to this specification can be transmitted in the form of FIG. 5.

[0756] Figure 97 is a flowchart illustrating the operation of a receiving device according to the present embodiment.

[0757] The above-described PPDU can be received according to an example of FIG. 97.

[0758] An example of FIG. 97 may be performed at a receiving STA or receiving device (AP and / or non-AP STA).

[0759] Some of the steps (or detailed sub-steps described below) in the example of Fig. 97 may be omitted.

[0760] A receiving device (receiving STA) may receive all or part of a PPDU through step S9710. The received signal may have the form of FIG. 5.

[0761] The sub-step of step S9710 can be determined based on step S9630 of FIG. 96. That is, step S9710 can perform an operation to restore the results of the CSD, Spatial Mapping, IDFT / IFFT operations, and GI insert operations applied in step S9630.

[0762] At step S9720, the receiving device can decode all or part of the PPDU. Additionally, the receiving device can obtain control information related to the Tone Plan (i.e., RU) from the decoded PPDU.

[0763] More specifically, the receiving device can decode the L-SIG and EHT-SIG of the PPDU based on the Legacy STF / LTF and obtain information included in the L-SIG and EHT SIG fields. Information regarding various Tone Plans (i.e., RUs) described herein can be included in the EHT-SIG, and the receiving STA can obtain information regarding the Tone Plan (i.e., RU) through the EHT-SIG.

[0764] In step S9730, the receiving device can decode the remaining portion of the PPDU based on the information about the Tone Plan (i.e., RU) acquired through step S9720. For example, the receiving STA can decode the STF / LTF field of the PPDU based on the information about one Plan (i.e., RU). In addition, the receiving STA can decode the data field of the PPDU based on the information about the Tone Plan (i.e., RU) and acquire the MPDU included in the data field.

[0765] Additionally, the receiving device may perform a processing operation to transmit the decoded data to a higher layer (e.g., MAC layer) through step S9730. Furthermore, if the generation of a signal is instructed from the higher layer to the PHY layer in response to the data transmitted to the higher layer, a subsequent operation may be performed.

[0766] Hereinafter, the above-described embodiment will be described with reference to FIGS. 1 to 97.

[0767] Figure 98 is a flowchart illustrating a procedure in which AP MLD defines the timing of context transfer and DS mapping change in MLD roaming according to the present embodiment.

[0768] An example of Fig. 98 can be performed in a network environment that supports a next-generation wireless LAN system (UHR (Ultra High Reliability) wireless LAN system or next wi-fi). The next-generation wireless LAN system is a wireless LAN system that improves on the 802.11be system and can satisfy backward compatibility with the 802.11be system.

[0769] This embodiment defines the time point at which a context is transferred from a Serving AP MLD to a Target AP MLD and the time point at which a DS mapping is changed, and proposes a method for distinguishing between context transfer according to the order of the two time points and packets buffered in the queues of the Serving AP MLD and the Target AP MLD.

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

[0771] In step S9820, after the context is transferred from the first AP MLD to the second AP MLD, the first AP transmits a roaming response frame to the non-AP STA.

[0772] Based on the fact that the context transfer is performed before the DS (Distribution System) mapping is changed from the first AP MLD to the second AP MLD, the context of the packet existing in the queue of the first AP MLD is transferred until the transfer of the context starts. After the DS mapping is changed, the context of the packet existing in the queue of the second AP MLD is set based on the context of the packet existing in the queue of the first AP MLD that has been transferred.

[0773] For example, the context of a packet existing in the queue of the first AP MLD transmitted at the time when the transfer of the context starts may be the last SN (Sequence Number) or the last PN (Packet Number) for the packet existing in the queue of the first AP MLD. After the transfer of the context starts, but before the DS mapping is changed, based on the existence of an additional packet in the queue of the first AP MLD, the context of a packet existing in the queue of the second AP MLD after the DS mapping is changed can be distinguished from the additional packet existing in the queue of the first AP MLD based on the last SN or the last PN. That is, since a new packet buffered in the queue of the second AP MLD after the DS mapping is changed is set based on the last SN or the last PN of the packet buffered in the queue of the first AP MLD, there is an effect that an overlapping problem with the additional packet buffered in the queue of the first AP MLD before the DS mapping is changed can be solved.

[0774] Conversely, based on the fact that the change of the DS mapping is performed before the forwarding of the context, the SN or PN for the packets existing in the queue of the first AP MLD until the point at which the change of the DS mapping is initiated can be forwarded to the context. After the DS mapping is changed, new packets can be buffered in the queue of the second AP MLD.

[0775] In both cases, when the context is delivered before the DS mapping change time and when the DS mapping change time is before the context delivery time, the context of the packet buffered in the queue of the first AP MLD is delivered at the time when the delivery of the context starts.

[0776] That is, the present embodiment proposes a method of setting packets buffered in the queue of the Target AP MLD after context transfer and DS mapping change to be distinguished from packets buffered in the queue of the Serving AP MLD, depending on the order of the timing of context transfer from the Serving AP MLD to the Target AP MLD and the timing of changing the DS mapping. This solves the problem of packets buffered in the queue of the Serving AP MLD and packets buffered in the queue of the Target AP MLD overlapping with each other depending on the timing of context transfer and the timing of changing the DS mapping, thereby having the effect of efficiently performing MLD roaming.

[0777] The above roaming request frame may include information about the context transfer level.

[0778] For example, based on the information about the context transfer level being set to 0, the context may not exist. Based on the information about the context transfer level being set to 1, the context may be a Sequence Number (SN) or a Packet Number (PN). Based on the information about the context transfer level being set to 2, the context may be a Block Ack (BA) Agreement (or information about a buffer size, a window size, a TID (Traffic Identifier) ​​for which BA Agreement is related or all TIDs). Based on the information about the context transfer level being set to 3, the context may be Packet Reordering. Based on the information about the context transfer level being set to 4 to 15, the context may be reserved. However, this is only one embodiment, and the information about the context transfer level may also be set to another value.

[0779] After the context is transferred from the first AP MLD to the second AP MLD, the non-AP STA can receive information that the transfer of the context has been completed from the second AP belonging to the second AP MLD (or, after the context is transferred from the first AP MLD to the second AP MLD, the second AP belonging to the second AP MLD can transmit information that the transfer of the context has been completed to the non-AP STA). The non-AP STA can perform roaming from the first AP to the second AP based on the roaming request frame and the roaming response frame.

[0780] Alternatively, the roaming request frame may include information on a link to be added. Accordingly, the non-AP STA may request the addition of a link through the roaming request frame without separately transmitting an additional link request frame. After receiving the roaming request frame, a new link may be established between the non-AP STA and the second AP MLD (or the second AP belonging to the second AP MLD). The second AP MLD may notify the non-AP STA that a link has been added by receiving an additional link confirmation frame.

[0781] The first and second AP MLDs may be included in a roaming-enabled group. A first AP may be affiliated with the first AP MLD, and a second AP may be affiliated with the second AP MLD. A non-AP STA may be affiliated with the non-AP MLD.

[0782] The first AP may be referred to as Old AP (O_AP), Serving AP, or Current AP. The second AP may be referred to as New AP (N_AP) or Target AP. The first AP MLD including the first AP may be referred to as Serving AP MLD. The second AP MLD including the second AP may be referred to as Target AP MLD. MLD roaming from the Serving AP MLD to the Target AP MLD is defined as an operation of seamlessly moving from one AP to another without any disconnection between the AP and the STA within the MLD.

[0783] The above roaming-enabled group may be referred to as a UHR AP MLD. The first and second AP MLDs are non-collocated, but are included in the same roaming-enabled group, so roaming (or movement) from an AP in the first AP MLD to an AP in the second AP MLD may be possible. The APs in the first AP MLD are collocated. The APs in the second AP MLD are also collocated.

[0784] In seamless roaming, there can be two types of architectures:

[0785] First, there is the MLD-based architecture. The MLD-based architecture refers to a case where all AP MLDs have a single medium access control (MAC) service access point (SAP) in a single domain called SMD (Single Mobility Domain). In other words, the MLD-based architecture has a common AP MLD upper MAC interfaced to all AP MLDs capable of performing seamless roaming. The UMAC of the UFT AP MLD controls all UMAC functions required for seamless roaming and has its own MAC SAP and unique MLD MAC address. Since the MLD-based architecture is a centralized architecture, contexts are not transferred through the DS (Distribution System), and context transfer may not exist.

[0786] Second, there is a context-passing-based architecture. This context-passing-based architecture is an improved roaming architecture that utilizes existing architectures (specifically, existing Fast Transition (FT)). This method requires context-passing between the serving AP MLD and the target AP MLD. Each AP MLD has its own MAC SAP. Each AP MLD is individually mapped to a DS, and non-AP MLDs are associated with an AP MLD. When a non-AP MLD roams from the serving AP MLD to the target AP MLD, it should roam without re-authentication and re-association. To share information among AP MLDs, AP MLDs within a single domain need to be associated with a logical entity. A security key (e.g., a single MAC address for SMD) must be shared among AP MLDs within the same single domain.

[0787] The MLD-based architecture offers virtually no delay, but requires architectural changes and is more complex to implement. Security keys are generated in the roaming MLD and shared with affiliated AP MLDs. In contrast, roaming with context transfer introduces some delay, which may worsen over other channels. However, it maintains the current architecture and offers simpler implementation. Security keys are shared over a secure channel. Therefore, the MLD-based architecture is the preferred scenario because it satisfies the goal of seamless roaming with virtually no delay. However, implementation can be challenging due to the architectural changes, and a context transfer-based architecture can be used for ease of implementation.

[0788] The first AP MLD, the second AP MLD, and the roaming-enabled group may be connected to a Distribution System (DS). For example, based on the fact that the first and second AP MLDs each have their own MAC SAPs, after the MLD roaming request frame is transmitted, the context may be transmitted to the second AP MLD via the DS.

[0789] The above context may be referred to as a parameter set negotiated between an AP and an STA (or between a non-AP MLD STA and a Serving AP MLD). The DS may be a backbone network for a wireless LAN that extends a wireless network by providing connectivity between different BSSs (Basic Service Sets).

[0790] The above roaming request frame may be defined based on a Reconfiguration Multi-link Information Element (IE). The above roaming response frame may be defined based on either a Reconfiguration Multi-link IE or a Basic Multi-link IE.

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

[0792] The first common information field may include first information indicating whether a roaming reason code exists. A roaming reason code may be included in the first common information field based on the first information indicating whether the roaming reason code exists. The first link information field may include second information indicating whether the roaming reason code exists. The roaming reason code may be included in the first link information field based on the second information indicating whether the roaming reason code exists.

[0793] The above 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 whether a roaming reason code exists. A roaming reason code may be included in the second common information field based on the first information indicating whether the roaming reason code exists. The second link information field may include second information indicating whether the roaming reason code exists. The roaming reason code may be included in the second link information field based on the second information indicating whether the roaming reason code exists.

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

[0795] Based on the roaming reason code being set to 0, the reason for recommending roaming to the AP may not be specified. Based on the roaming reason code being set to 1, the reason for recommending roaming to the AP may be excessive frame loss rate or poor conditions. Based on the roaming reason code being set to 2, the reason for recommending roaming to the AP may be excessive delay for the current traffic stream. Based on the roaming reason code being set to 3, the reason for recommending roaming to the AP may be insufficient Quality of Service (QoS) capacity for the current traffic stream. Based on the roaming reason code being set to 4, the reason for recommending roaming to the AP may be discovery of a better link.

[0796] Based on the roaming reason code being set to 5, the reason for recommending roaming to the AP may be the discovery of a better AP. Based on the roaming reason code being set to 6, the reason for recommending roaming to the AP may be the receipt of too many replay counter failures. Based on the roaming reason code being set to 7, the reason for recommending roaming to the AP may be the receipt of too many data MIC (Message Integrity Code) failures. Based on the roaming reason code being set to 8, the reason for recommending roaming to the AP may be the exceeding of the maximum number of retransmissions. Based on the roaming reason code being set to 9, the reason for recommending roaming to the AP may be the receipt of too many broadcast disassociations. Based on the above roaming reason code being set to 10, the reason for recommending roaming to the above AP may be that too many broadcast de-authentications are being received.

[0797] Based on the roaming reason code being set to 11, the reason for recommending roaming to the AP may be a previous roaming failure. Based on the roaming reason code being set to 12, the reason for recommending roaming to the AP may be a low Received Signal Strength Indication (RSSI). Based on the roaming reason code being set to 13, the reason for recommending roaming to the AP may be a switch due to a received roaming request frame. Based on the roaming reason code being set to 14, the reason for recommending roaming to the AP may be inclusion in a recommended roaming list. Based on the roaming reason code being set to 15 to 255, the reason for recommending roaming to the AP may be reserved.

[0798] After roaming from the first AP MLD to the second AP MLD is completed, the non-AP STA can transmit and receive DL (downlink) data or UL (uplink) data with the second AP.

[0799] Figure 99 is a flowchart illustrating a procedure for defining a time point for transfer of context and DS mapping change by a non-AP MLD in MLD roaming according to the present embodiment.

[0800] An example of Fig. 99 can be performed in a network environment that supports a next-generation wireless LAN system (UHR (Ultra High Reliability) wireless LAN system or next wi-fi). The next-generation wireless LAN system is a wireless LAN system that improves on the 802.11be system and can satisfy backward compatibility with the 802.11be system.

[0801] This embodiment defines the time point at which a context is transferred from a Serving AP MLD to a Target AP MLD and the time point at which a DS mapping is changed, and proposes a method for distinguishing between context transfer according to the order of the two time points and packets buffered in the queues of the Serving AP MLD and the Target AP MLD.

[0802] In step S9910, a non-AP STA (station) belonging to a non-AP (non-access point) MLD (multi-link device) transmits a roaming request frame to the first AP belonging to the first AP MLD.

[0803] In step S9920, after the context is transferred from the first AP MLD to the second AP MLD, the non-AP STA receives a roaming response frame from the first AP.

[0804] Based on the fact that the context transfer is performed before the DS (Distribution System) mapping is changed from the first AP MLD to the second AP MLD, the context of the packet existing in the queue of the first AP MLD is transferred until the transfer of the context starts. After the DS mapping is changed, the context of the packet existing in the queue of the second AP MLD is set based on the context of the packet existing in the queue of the first AP MLD that has been transferred.

[0805] For example, the context of a packet existing in the queue of the first AP MLD transmitted at the time when the transfer of the context starts may be the last SN (Sequence Number) or the last PN (Packet Number) for the packet existing in the queue of the first AP MLD. After the transfer of the context starts, but before the DS mapping is changed, based on the existence of an additional packet in the queue of the first AP MLD, the context of a packet existing in the queue of the second AP MLD after the DS mapping is changed can be distinguished from the additional packet existing in the queue of the first AP MLD based on the last SN or the last PN. That is, since a new packet buffered in the queue of the second AP MLD after the DS mapping is changed is set based on the last SN or the last PN of the packet buffered in the queue of the first AP MLD, there is an effect that an overlapping problem with the additional packet buffered in the queue of the first AP MLD before the DS mapping is changed can be solved.

[0806] Conversely, based on the fact that the change of the DS mapping is performed before the forwarding of the context, the SN or PN for the packets existing in the queue of the first AP MLD until the point at which the change of the DS mapping is initiated can be forwarded to the context. After the DS mapping is changed, new packets can be buffered in the queue of the second AP MLD.

[0807] In both cases, when the context is delivered before the DS mapping change time and when the DS mapping change time is before the context delivery time, the context of the packet buffered in the queue of the first AP MLD is delivered at the time when the delivery of the context starts.

[0808] That is, the present embodiment proposes a method of setting packets buffered in the queue of the Target AP MLD after context transfer and DS mapping change to be distinguished from packets buffered in the queue of the Serving AP MLD, depending on the order of the timing of context transfer from the Serving AP MLD to the Target AP MLD and the timing of changing the DS mapping. This solves the problem of packets buffered in the queue of the Serving AP MLD and packets buffered in the queue of the Target AP MLD overlapping with each other depending on the timing of context transfer and the timing of changing the DS mapping, thereby having the effect of efficiently performing MLD roaming.

[0809] The above roaming request frame may include information about the context transfer level.

[0810] For example, based on the information about the context transfer level being set to 0, the context may not exist. Based on the information about the context transfer level being set to 1, the context may be a Sequence Number (SN) or a Packet Number (PN). Based on the information about the context transfer level being set to 2, the context may be a Block Ack (BA) Agreement (or information about a buffer size, a window size, a TID (Traffic Identifier) ​​for which BA Agreement is related or all TIDs). Based on the information about the context transfer level being set to 3, the context may be Packet Reordering. Based on the information about the context transfer level being set to 4 to 15, the context may be reserved. However, this is only one embodiment, and the information about the context transfer level may also be set to another value.

[0811] After the context is transferred from the first AP MLD to the second AP MLD, the non-AP STA can receive information that the transfer of the context has been completed from the second AP belonging to the second AP MLD (or, after the context is transferred from the first AP MLD to the second AP MLD, the second AP belonging to the second AP MLD can transmit information that the transfer of the context has been completed to the non-AP STA). The non-AP STA can perform roaming from the first AP to the second AP based on the roaming request frame and the roaming response frame.

[0812] Alternatively, the roaming request frame may include information on a link to be added. Accordingly, the non-AP STA may request the addition of a link through the roaming request frame without separately transmitting an additional link request frame. After receiving the roaming request frame, a new link may be established between the non-AP STA and the second AP MLD (or the second AP belonging to the second AP MLD). The second AP MLD may notify the non-AP STA that a link has been added by receiving an additional link confirmation frame.

[0813] The first and second AP MLDs may be included in a roaming-enabled group. A first AP may be affiliated with the first AP MLD, and a second AP may be affiliated with the second AP MLD. A non-AP STA may be affiliated with the non-AP MLD.

[0814] The first AP may be referred to as Old AP (O_AP), Serving AP, or Current AP. The second AP may be referred to as New AP (N_AP) or Target AP. The first AP MLD including the first AP may be referred to as Serving AP MLD. The second AP MLD including the second AP may be referred to as Target AP MLD. MLD roaming from the Serving AP MLD to the Target AP MLD is defined as an operation of seamlessly moving from one AP to another without any disconnection between the AP and the STA within the MLD.

[0815] The above roaming-enabled group may be referred to as a UHR AP MLD. The first and second AP MLDs are non-collocated, but are included in the same roaming-enabled group, so roaming (or movement) from an AP in the first AP MLD to an AP in the second AP MLD may be possible. The APs in the first AP MLD are collocated. The APs in the second AP MLD are also collocated.

[0816] In seamless roaming, there can be two types of architectures:

[0817] First, there is the MLD-based architecture. The MLD-based architecture refers to a case where all AP MLDs have a single medium access control (MAC) service access point (SAP) in a single domain called SMD (Single Mobility Domain). In other words, the MLD-based architecture has a common AP MLD upper MAC interfaced to all AP MLDs capable of performing seamless roaming. The UMAC of the UFT AP MLD controls all UMAC functions required for seamless roaming and has its own MAC SAP and unique MLD MAC address. Since the MLD-based architecture is a centralized architecture, contexts are not transferred through the DS (Distribution System), and context transfer may not exist.

[0818] Second, there is a context-passing-based architecture. This context-passing-based architecture is an improved roaming architecture that utilizes existing architectures (specifically, existing Fast Transition (FT)). This method requires context-passing between the serving AP MLD and the target AP MLD. Each AP MLD has its own MAC SAP. Each AP MLD is individually mapped to a DS, and non-AP MLDs are associated with an AP MLD. When a non-AP MLD roams from the serving AP MLD to the target AP MLD, it should roam without re-authentication and re-association. To share information among AP MLDs, AP MLDs within a single domain need to be associated with a logical entity. A security key (e.g., a single MAC address for SMD) must be shared among AP MLDs within the same single domain.

[0819] The MLD-based architecture offers virtually no delay, but requires architectural changes and is more complex to implement. Security keys are generated in the roaming MLD and shared with affiliated AP MLDs. In contrast, roaming with context transfer introduces some delay, which may worsen over other channels. However, it maintains the current architecture and offers simpler implementation. Security keys are shared over a secure channel. Therefore, the MLD-based architecture is the preferred scenario because it satisfies the goal of seamless roaming with virtually no delay. However, implementation can be challenging due to the architectural changes, and a context transfer-based architecture can be used for ease of implementation.

[0820] The first AP MLD, the second AP MLD, and the roaming-enabled group may be connected to a Distribution System (DS). For example, based on the fact that the first and second AP MLDs each have their own MAC SAPs, after the MLD roaming request frame is transmitted, the context may be transmitted to the second AP MLD via the DS.

[0821] The above context may be referred to as a parameter set negotiated between an AP and an STA (or between a non-AP MLD STA and a Serving AP MLD). The DS may be a backbone network for a wireless LAN that extends a wireless network by providing connectivity between different BSSs (Basic Service Sets).

[0822] The above roaming request frame may be defined based on a Reconfiguration Multi-link Information Element (IE). The above roaming response frame may be defined based on either a Reconfiguration Multi-link IE or a Basic Multi-link IE.

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

[0824] The first common information field may include first information indicating whether a roaming reason code exists. A roaming reason code may be included in the first common information field based on the first information indicating whether the roaming reason code exists. The first link information field may include second information indicating whether the roaming reason code exists. The roaming reason code may be included in the first link information field based on the second information indicating whether the roaming reason code exists.

[0825] The above 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 whether a roaming reason code exists. A roaming reason code may be included in the second common information field based on the first information indicating whether the roaming reason code exists. The second link information field may include second information indicating whether the roaming reason code exists. The roaming reason code may be included in the second link information field based on the second information indicating whether the roaming reason code exists.

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

[0827] Based on the roaming reason code being set to 0, the reason for recommending roaming to the AP may not be specified. Based on the roaming reason code being set to 1, the reason for recommending roaming to the AP may be excessive frame loss rate or poor conditions. Based on the roaming reason code being set to 2, the reason for recommending roaming to the AP may be excessive delay for the current traffic stream. Based on the roaming reason code being set to 3, the reason for recommending roaming to the AP may be insufficient Quality of Service (QoS) capacity for the current traffic stream. Based on the roaming reason code being set to 4, the reason for recommending roaming to the AP may be discovery of a better link.

[0828] Based on the roaming reason code being set to 5, the reason for recommending roaming to the AP may be the discovery of a better AP. Based on the roaming reason code being set to 6, the reason for recommending roaming to the AP may be the receipt of too many replay counter failures. Based on the roaming reason code being set to 7, the reason for recommending roaming to the AP may be the receipt of too many data MIC (Message Integrity Code) failures. Based on the roaming reason code being set to 8, the reason for recommending roaming to the AP may be the exceeding of the maximum number of retransmissions. Based on the roaming reason code being set to 9, the reason for recommending roaming to the AP may be the receipt of too many broadcast disassociations. Based on the above roaming reason code being set to 10, the reason for recommending roaming to the above AP may be that too many broadcast de-authentications are being received.

[0829] Based on the roaming reason code being set to 11, the reason for recommending roaming to the AP may be a previous roaming failure. Based on the roaming reason code being set to 12, the reason for recommending roaming to the AP may be a low Received Signal Strength Indication (RSSI). Based on the roaming reason code being set to 13, the reason for recommending roaming to the AP may be a switch due to a received roaming request frame. Based on the roaming reason code being set to 14, the reason for recommending roaming to the AP may be inclusion in a recommended roaming list. Based on the roaming reason code being set to 15 to 255, the reason for recommending roaming to the AP may be reserved.

[0830] After roaming from the first AP MLD to the second AP MLD is completed, the non-AP STA can transmit and receive DL (downlink) data or UL (uplink) data with the second AP.

[0831] <Device Configuration>

[0832] The technical features of the present specification described above can be applied to various devices and methods. For example, the technical features of the present specification described above can be performed / supported by the devices of FIG. 1 and / or FIG. 14. For example, the technical features of the present specification described above can be applied only to a part of FIG. 1 and / or FIG. 14. For example, the technical features of the present specification described above can be implemented based on the processing chip (114, 124) of FIG. 1, or based on the processor (111, 121) and the memory (112, 122) of FIG. 1, or based on the processor (610) and the memory (620) of FIG. 14. For example, the device of the present specification transmits a roaming request frame to a first AP (access point) belonging to a first MLD (multi-link device); And after the context is transferred from the first AP MLD to the second AP MLD, a roaming response frame is received from the first AP.

[0833] The technical features of this specification can be implemented based on a computer-readable medium (CRM). For example, the CRM proposed by this specification is at least one computer-readable recording medium containing instructions that are executed by at least one processor.

[0834] The CRM may store instructions for performing operations including the steps of transmitting a Roaming Request frame to a first AP belonging to a first AP (access point) MLD (multi-link device); and receiving a Roaming Response frame from the first AP after context is transferred from the first AP MLD to the second AP MLD. The instructions stored in the CRM of the present specification may be executed by at least one processor. At least one processor related to the CRM of the present specification may be the processor (111, 121) or the processing chip (114, 124) of FIG. 1, or the processor (610) of FIG. 14. Meanwhile, the CRM of this specification may be the memory (112, 122) of FIG. 1, the memory (620) of FIG. 14, or a separate external memory / storage medium / disk, etc.

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

[0836] Artificial intelligence (AI) is the study of artificial intelligence or the methodologies for creating it, while machine learning (ML) defines various problems in the field of AI and studies the methodologies for solving them. Machine learning is also defined as an algorithm that improves performance on a task through consistent experience.

[0837] An artificial neural network (ANN) is a model used in machine learning. It can refer to a model with problem-solving capabilities, consisting of artificial neurons (nodes) formed by the connection of synapses to form a network. An ANN can be defined by the connection patterns between neurons in different layers, the learning process that updates model parameters, and the activation function that generates output values.

[0838] An artificial neural network may include an input layer, an output layer, and optionally one or more hidden layers. Each layer contains one or more neurons, and the artificial neural network may include synapses connecting neurons. In an artificial neural network, each neuron can output a function value of an activation function based on input signals, weights, and biases received through the synapses.

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

[0840] The goal of artificial neural network training can be seen as determining model parameters that minimize a loss function. The loss function can be used as an indicator for determining optimal model parameters during the artificial neural network training process.

[0841] Machine learning can be classified into supervised learning, unsupervised learning, and reinforcement learning depending on the learning method.

[0842] Supervised learning refers to a method for training an artificial neural network when given labels for the training data. The labels can refer to the correct answer (or output value) that the artificial neural network must infer when the training data is input to the artificial neural network. Unsupervised learning can refer to a method for training an artificial neural network when the training data is not given labels. Reinforcement learning can refer to a learning method in which an agent defined within a given environment is trained to select actions or action sequences that maximize the cumulative reward in each state.

[0843] Machine learning implemented with a deep neural network (DNN) containing multiple hidden layers among artificial neural networks is also called deep learning, and deep learning is a subset of machine learning. Hereinafter, the term "machine learning" is used to encompass deep learning.

[0844] Additionally, the above-described technical features can be applied to wireless communication of robots.

[0845] A robot can be defined as a machine that automatically performs or operates a given task based on its own capabilities. Specifically, a robot capable of perceiving its environment, making independent judgments, and performing actions can be called an intelligent robot.

[0846] Robots can be categorized into industrial, medical, household, and military applications based on their intended use or field. Robots are equipped with actuators or motors, enabling them to perform various physical actions, such as moving robot joints. Furthermore, mobile robots incorporate wheels, brakes, and propellers into their actuators, enabling them to move on the ground or fly in the air.

[0847] Additionally, the above-described technical features can be applied to devices that support extended reality.

[0848] Extended reality is a general term for virtual reality (VR), augmented reality (AR), and mixed reality (MR). VR technology presents real-world objects and backgrounds as CG images only, AR technology presents virtual CG images over images of real objects, and MR technology is a computer graphics technology that blends and combines virtual objects with the real world.

[0849] MR technology is similar to AR in that it presents both real and virtual objects simultaneously. However, while AR uses virtual objects to complement real objects, MR uses virtual and real objects on an equal footing.

[0850] XR technology can be applied to HMD (Head-Mount Display), HUD (Head-Up Display), mobile phones, tablet PCs, laptops, desktops, TVs, digital signage, etc., and devices to which XR technology is applied can be called XR devices.

[0851] The claims set forth in this specification may be combined in various ways. For example, the technical features of the method claims of this specification may be combined and implemented as a device, and the technical features of the device claims of this specification may be combined and implemented as a method. Furthermore, the technical features of the method claims and the technical features of the device claims of this specification may be combined and implemented as a device, and the technical features of the method claims and the technical features of the device claims of this specification may be combined and implemented as a method.

Claims

1. In a method performed by a non-AP (non-access point) MLD (multi-link device) in a wireless LAN system, A step in which a non-AP STA (station) belonging to the non-AP MLD transmits a roaming request frame to a first AP belonging to the first AP MLD; and After the context is transferred from the first AP MLD to the second AP MLD, the non-AP STA includes a step of receiving a roaming response frame from the first AP. Based on the fact that the transfer of the context is performed before the DS (Distribution System) mapping is changed from the first AP MLD to the second AP MLD, The context of the packet existing in the queue of the first AP MLD is transmitted until the transmission of the above context begins, and After the above DS mapping is changed, the context of the packet existing in the queue of the second AP MLD is set based on the context of the packet existing in the queue of the first AP MLD that has been transmitted. method.

2. In paragraph 1, The context of the packet existing in the queue of the first AP MLD that is transmitted at the time when the transmission of the above context starts is the last SN (Sequence Number) or last PN (Packet Number) for the packet existing in the queue of the first AP MLD, Based on the presence of additional packets in the queue of the first AP MLD before the DS mapping is changed after the transmission of the said context begins, After the above DS mapping is changed, the context of the packet existing in the queue of the second AP MLD is distinguished from the additional packet existing in the queue of the first AP MLD based on the last SN or the last PN. method.

3. In paragraph 1, Based on the fact that the change of the DS mapping is performed before the transmission of the above context, The SN or PN for the packets existing in the queue of the first AP MLD until the change of the DS mapping starts is transferred to the context, After the above DS mapping is changed, a new packet is buffered in the queue of the second AP MLD. method.

4. In paragraph 1, The above roaming request frame includes information about the context transfer level, Based on the information about the context transfer level being set to 0, the context does not exist, Based on the information about the context transfer level being set to 1, the context is a Sequence Number (SN) or a Packet Number (PN), Based on the information about the context transfer level being set to 2, the context is a BA (Block Ack) Agreement, Based on the information about the context transfer level being set to 3, the context is packet reordering, Based on the information about the context transfer level being set to 4 to 15, the context is reserved. method.

5. In paragraph 1, After the context is transferred from the first AP MLD to the second AP MLD, the non-AP STA receives information that the transfer of the context has been completed from the second AP belonging to the second AP MLD; and The non-AP STA further includes a step of performing roaming from the first AP to the second AP based on the roaming request frame and the roaming response frame, The above first and second AP MLDs are included in the group where roaming is possible. method.

6. In paragraph 5, The above first AP MLD, the above second AP MLD and the above roaming-enabled group are connected to a DS (Distribution System), Based on the fact that the first and second AP MLDs individually have MAC (medium access control) SAP (service access point), after the roaming request frame is transmitted, the context is transferred to the second AP MLD through the DS. method.

7. In paragraph 1, The above roaming request frame is defined based on the Reconfiguration Multi-link IE (Information Element), The above roaming response frame is defined based on either the Reset Multi-link IE or the Basic Multi-link IE. method.

8. In paragraph 7, The above roaming request frame includes a first common information field and a first link information field, The first common information field includes first information indicating whether a roaming reason code exists, The roaming reason code is included in the first common information field based on the first information indicating whether the roaming reason code exists, The first link information field includes second information indicating whether the roaming reason code exists, The roaming reason code is included in the first link information field based on the second information indicating whether the roaming reason code exists. method.

9. In paragraph 7, The above roaming response frame includes a second common information field and a second link information field, The second common information field includes first information indicating whether a roaming reason code exists, The second common information field includes a roaming reason code based on the first information indicating the presence or absence of the roaming reason code, The second link information field includes second information indicating whether the roaming reason code exists, The second link information field includes the roaming reason code based on the second information indicating the presence or absence of the roaming reason code. method.

10. In a wireless LAN system, a non-AP (non-access point) MLD (multi-link device) is memory; transceiver; and A processor operatively coupled to the memory and the transceiver, the processor comprising: A non-AP STA (station) belonging to the non-AP MLD transmits a roaming request frame to a first AP belonging to the first AP MLD; and After the context is transferred from the first AP MLD to the second AP MLD, the non-AP STA receives a roaming response frame from the first AP. Based on the fact that the transfer of the context is performed before the DS (Distribution System) mapping is changed from the first AP MLD to the second AP MLD, The context of the packet existing in the queue of the first AP MLD is transmitted until the transmission of the above context begins, and After the above DS mapping is changed, the context of the packet existing in the queue of the second AP MLD is set based on the context of the packet existing in the queue of the first AP MLD that has been transmitted. Non-AP MLD.

11. In a method performed on a first AP (access point) MLD (multi-link device) in a wireless LAN system, A step in which a first AP belonging to the first AP MLD receives a roaming request frame from a non-AP STA (station) belonging to a non-AP MLD; and After the context is transferred from the first AP MLD to the second AP MLD, the first AP includes a step of transmitting a roaming response frame to the non-AP STA. Based on the fact that the transfer of the context is performed before the DS (Distribution System) mapping is changed from the first AP MLD to the second AP MLD, The context of the packet existing in the queue of the first AP MLD is transmitted until the transmission of the above context begins, and After the above DS mapping is changed, the context of the packet existing in the queue of the second AP MLD is set based on the context of the packet existing in the queue of the first AP MLD that has been transmitted. method.

12. In paragraph 11, The context of the packet existing in the queue of the first AP MLD that is transmitted at the time when the transmission of the above context starts is the last SN (Sequence Number) or last PN (Packet Number) for the packet existing in the queue of the first AP MLD, Based on the presence of additional packets in the queue of the first AP MLD before the DS mapping is changed after the transmission of the said context begins, After the above DS mapping is changed, the context of the packet existing in the queue of the second AP MLD is distinguished from the additional packet existing in the queue of the first AP MLD based on the last SN or the last PN. method.

13. In paragraph 11, Based on the fact that the change of the DS mapping is performed before the transmission of the above context, The SN or PN for the packets existing in the queue of the first AP MLD until the change of the DS mapping starts is transferred to the context, After the above DS mapping is changed, a new packet is buffered in the queue of the second AP MLD. method.

14. In paragraph 11, The above roaming request frame includes information about the context transfer level, Based on the information about the context transfer level being set to 0, the context does not exist, Based on the information about the context transfer level being set to 1, the context is a Sequence Number (SN) or a Packet Number (PN), Based on the information about the context transfer level being set to 2, the context is a BA (Block Ack) Agreement, Based on the information about the context transfer level being set to 3, the context is packet reordering, Based on the information about the context transfer level being set to 4 to 15, the context is reserved. method.

15. In paragraph 11, After the context is transferred from the first AP MLD to the second AP MLD, the second AP belonging to the second AP MLD further includes a step of transmitting information to the non-AP STA that the transfer of the context has been completed. Roaming from the first AP to the second AP is performed based on the roaming request frame and the roaming response frame, The above first and second AP MLDs are included in the group where roaming is possible. method.

16. In paragraph 15, The above first AP MLD, the above second AP MLD and the above roaming-enabled group are connected to a DS (Distribution System), Based on the fact that the first and second AP MLDs individually have MAC (medium access control) SAP (service access point), after the roaming request frame is transmitted, the context is transferred to the second AP MLD through the DS. method.

17. In paragraph 11, The above roaming request frame is defined based on the Reconfiguration Multi-link IE (Information Element), The above roaming response frame is defined based on either the Reset Multi-link IE or the Basic Multi-link IE. method.

18. In a wireless LAN system, the first AP (access point) MLD (multi-link device) memory; transceiver; and A processor operatively coupled to the memory and the transceiver, the processor comprising: The first AP belonging to the first AP MLD receives a roaming request frame from a non-AP STA (station) belonging to the non-AP MLD; and After the context is transferred from the first AP MLD to the second AP MLD, the first AP transmits a roaming response frame to the non-AP STA. Based on the fact that the transfer of the context is performed before the DS (Distribution System) mapping is changed from the first AP MLD to the second AP MLD, The context of the packet existing in the queue of the first AP MLD is transmitted until the transmission of the above context begins, and After the above DS mapping is changed, the context of the packet existing in the queue of the second AP MLD is set based on the context of the packet existing in the queue of the first AP MLD that has been transmitted. 1st AP MLD.

19. At least one computer-readable medium containing instructions based on being executed by at least one processor, A step of transmitting a roaming request frame to a first AP belonging to a first AP (access point) MLD (multi-link device); and A step of receiving a roaming response frame from the first AP after the context is transferred from the first AP MLD to the second AP MLD, Based on the fact that the transfer of the context is performed before the DS (Distribution System) mapping is changed from the first AP MLD to the second AP MLD, The context of the packet existing in the queue of the first AP MLD is transmitted until the transmission of the above context begins, and After the above DS mapping is changed, the context of the packet existing in the queue of the second AP MLD is set based on the context of the packet existing in the queue of the first AP MLD that has been transmitted. Recording medium.

20. In a wireless LAN system, in the device, memory; and A processor operatively coupled to the memory, the processor comprising: Transmit a roaming request frame to the first AP belonging to the first AP (access point) MLD (multi-link device); and After the context is transferred from the first AP MLD to the second AP MLD, a roaming response frame is received from the first AP. Based on the fact that the transfer of the context is performed before the DS (Distribution System) mapping is changed from the first AP MLD to the second AP MLD, The context of the packet existing in the queue of the first AP MLD is transmitted until the transmission of the above context begins, and After the above DS mapping is changed, the context of the packet existing in the queue of the second AP MLD is set based on the context of the packet existing in the queue of the first AP MLD that has been transmitted. device.

Images