Handling of transmission failure in wireless LAN system

Abstract

The present disclosure relates to a method for handling a transmission failure in a wireless LAN system, the method being performed by a first AP MLD and comprising the steps in which: a first AP affiliated with the first AP MLD receives, from an STA affiliated with a non-AP MLD, a request frame for continuous switching from the first AP MLD to a second AP MLD; the first AP transmits a response frame to the STA in response to the request frame; the first AP transmits first data queued in a buffer to the STA after the request frame is received; and on the basis of detecting a transmission failure of the first data, the first AP delivers the first data to a second AP affiliated with the second AP MLD.

Description

Handling transmission failures in wireless LAN systems

[0001] This disclosure relates to the handling of transmission failure in a wireless LAN system.

[0002] Next-generation Wi-Fi (e.g., IEEE 802.11be and / or later) aims to support ultra-high reliability when transmitting signals to STAs, and to this end, various technologies are being considered to support high throughput, low latency, and extended range.

[0003] For example, in WiFi systems, transmission failures can occur due to various causes when transmitting data frames. These transmission failures are primarily attributed to interference, channel congestion, signal attenuation, or temporary reception failure at the receiving end.

[0004] WiFi standards define a retransmission procedure to handle transmission failures. For example, if a transmitting STA does not receive an acknowledgment (ACK) from a receiving STA within a certain period after transmitting a data frame, it determines that the transmission has failed and may retransmit the same frame. In this case, the number of transmission failures is managed as a retry count, and if the retry limit is exceeded, the frame is dropped.

[0005] However, these conventional transmission failure handling methods are implemented by simply increasing the number of retransmissions, which raises concerns about intensified network congestion or increased transmission latency.

[0006] The present disclosure provides a method and apparatus for handling transmission failures in a wireless LAN system.

[0007] According to an embodiment of the present disclosure, a method performed at a first access point (AP) multi-link device (MLD) comprises: receiving a request frame for a continuous transition from the first AP MLD to a second AP MLD from a station (STA) associated with a non-AP MLD, whereby the first AP affiliated with the first AP MLD receives the request frame; transmitting a response frame for the request frame to the STA, whereby the first AP transmits first data that is queued in a buffer after the request frame is received to the STA; and, based on detecting a transmission failure for the transmission of the first data, the first AP transmits the first data to a second AP affiliated with the second AP MLD.

[0008] According to an embodiment of the present disclosure, a method performed in a non-AP (access point) MLD (multi-link device) comprises the steps of: a STA (station) affiliated with the non-AP MLD transmitting a request frame for a sequential transition from the first AP MLD to the second AP MLD to the first AP MLD; the STA receiving a response frame for the request frame from the first AP; and the STA receiving a transmission of first data that is queued in a buffer after the request frame has been transmitted from the first AP, and, based on the occurrence of a transmission failure for the transmission of the first data, the first data is transferred from the first AP to the second AP affiliated with the second AP MLD.

[0009] In various embodiments, devices for implementing the methods described above are provided.

[0010] The present disclosure may have various advantageous effects.

[0011] For example, roaming delays caused by transmission failures can be reduced.

[0012] The advantageous effects obtainable through specific embodiments of the present disclosure are not limited to those listed above. For example, there may be various technical effects that a person skilled in the art can understand and / or derive from the present disclosure. Accordingly, the specific effects of the present disclosure are not limited to those explicitly described herein and may include various effects that can be understood or derived from the technical features of the present disclosure.

[0013] FIG. 1 shows an example of a transmitting device and / or receiving device of the present disclosure.

[0014] Figure 2 is a conceptual diagram showing the structure of a wireless LAN (WLAN).

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

[0016] Figure 4 illustrates an example of multiple links.

[0017] FIG. 5 shows a modified example of a transmitting device and / or receiving device of the present disclosure.

[0018] FIG. 6 illustrates an example of a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted / received in an STA of the present disclosure.

[0019] Figure 7 shows an example of a MAC frame header.

[0020] Figure 8 shows the Over-the-air (OTA) FT protocol in the Robust Security Network (RSN).

[0021] Figure 9 shows the upper-level architecture of the AP MLD.

[0022] Figure 10 shows an example of a high-level architecture for UHR AP MLD.

[0023] Figure 11 shows an example of a high-level architecture for a UHR AP MLD including separate entities.

[0024] Figure 12 shows another example of a top-layer architecture for UHR AP MLD.

[0025] Figure 13 shows a first example of an architecture with only entities and not based on MLD.

[0026] Figure 14 shows a second example of an architecture in which there are only entities and not based on MLD.

[0027] Figure 15 shows the arrangement of AP MLDs for roaming.

[0028] Figure 16 shows an example for RNR IE.

[0029] Figure 17 shows another example for RNR IE.

[0030] Figure 18 shows another example of RNR IE.

[0031] FIG. 19 shows an example of the structure of an ML probe request frame when the common information field includes a roaming proposal possible field according to an embodiment of the present disclosure.

[0032] FIG. 20 shows an example of the structure of an ML probe request frame when the link information field includes a roaming proposal possible field according to an embodiment of the present disclosure.

[0033] Figure 21 shows a baseline continuous roaming procedure.

[0034] FIG. 22 shows a first example of operations performed by AP MLD / non-AP MLD in a basic continuous roaming procedure.

[0035] FIG. 23 shows a second example of operations performed by AP MLD / non-AP MLD in a basic continuous roaming procedure.

[0036] FIG. 24 shows a third example of operations performed by AP MLD / non-AP MLD in a basic continuous roaming procedure.

[0037] FIG. 25 shows a fourth example of operations performed by AP MLD / non-AP MLD in a basic continuous roaming procedure.

[0038] FIG. 26 shows an example of a common information field of a reset multi-link IE according to an embodiment of the present disclosure.

[0039] FIG. 27 shows an example of a link information field of a reset multi-link IE according to an embodiment of the present disclosure.

[0040] FIG. 28 illustrates an example in which a common information field of a reset multi-link IE includes a UHR MLD MAC address, a UHR AP MLD ID, and an AP MLD ID according to an embodiment of the present disclosure.

[0041] FIG. 29 illustrates an example in which a UHR MLD MAC address and an AP MLD ID are included in the common information field of a reset multi-link ID according to an embodiment of the present disclosure.

[0042] FIG. 30 illustrates an example in which a UHR MLD MAC address, a UHR AP MLD ID, and an AP MLD ID are included in the link information field of a reset multi-link IE according to an embodiment of the present disclosure.

[0043] FIG. 31 shows an example in which an AP MLD ID is included in the link information field of a reset multi-link IE according to an embodiment of the present disclosure.

[0044] FIG. 32 shows another example in which the UHR AP MLD ID and the AP MLD ID are included in the link information field of a reset multi-link IE according to an embodiment of the present disclosure.

[0045] FIG. 33 shows another example in which an AP MLD ID is included in the link information field of a reset multi-link IE according to an embodiment of the present disclosure.

[0046] FIG. 34 illustrates an example in which fields related to adding / deleting / switching links are included in the common information fields of a reset ML IE according to an embodiment of the present disclosure.

[0047] FIG. 35 illustrates an example in which fields related to adding / deleting / switching links are included in the link information field of a reset ML IE according to an embodiment of the present disclosure.

[0048] FIG. 36 illustrates another example in which fields related to adding / deleting / switching links are included in the link information fields of a reset ML IE according to an embodiment of the present disclosure.

[0049] Figure 37 shows an example where the AP removal timer is included in the common information field of the reset ML IE.

[0050] Figure 38 shows an example of the common information field structure of the basic ML IE.

[0051] Figure 39 shows an example of the link information field structure of the basic ML IE.

[0052] Figure 40 shows an example of a group key information field.

[0053] Figure 41 shows a first example of a procedure for transmitting DL data in the queue of a serving AP MLD.

[0054] Figure 42 shows an example of a procedure that notifies the completion of transmission of DL data in the queue of the serving AP MLD via a DL timer.

[0055] Figure 43 shows an example of transmitting a context-transfer frame.

[0056] Figure 44 shows an example of a data transfer procedure.

[0057] Figure 45 illustrates the data transfer procedure when the serving AP MLD performs data transfer while performing DL transfer.

[0058] Figure 46 shows a flowchart of the case where the serving AP MLD performs data delivery while performing DL transmission.

[0059] Figure 47 illustrates the data delivery procedure when the serving AP MLD performs data delivery after performing DL transmission.

[0060] Figure 48 shows a flowchart of the case where the serving AP MLD performs data delivery after performing DL transmission.

[0061] Figure 49 shows an example of a method performed in the AP MLD for processing data where transmission failure occurred.

[0062] Figure 50 shows an example of signal flow between an AP MLD and a non-AP MLD for processing data where transmission failure occurred.

[0063] Figure 51 shows a procedure for checking whether N_AP is roaming enabled using the Collocation Enabled field.

[0064] Figure 52 illustrates a procedure for determining whether N_AP is roaming possible using a Collocation ID.

[0065] Figure 53 shows an example of a collocated AP set.

[0066] Figure 54 illustrates the MLD roaming procedure when the UHR AP MLD ID is included in the reset element.

[0067] Figure 55 shows the MLD roaming procedure when the UHR AP MLD ID is not included in the reset element.

[0068] Figure 56 shows Example 1 of an MLD roaming procedure.

[0069] Figure 57 illustrates the operation process of Example 1 for the MLD roaming procedure.

[0070] Figure 58 shows Example 2 of an MLD roaming procedure.

[0071] Figure 59 shows the operation process of Example 2 for the MLD roaming procedure.

[0072] Figure 60 shows Example 4 of an MLD roaming procedure.

[0073] Figure 61 shows the operation process of Examples 3 and 4 for the MLD roaming procedure.

[0074] Figure 62 shows an example of how to set the type field of an MLD roaming request frame when sending requests for link addition and deletion simultaneously.

[0075] Figure 63 shows another example of how to set the type field of an MLD roaming request frame when sending requests for link addition and deletion simultaneously.

[0076] Figure 64 shows an example of MLD roaming using TIM.

[0077] Figure 65 shows the operation process of an MLD roaming procedure using TIM.

[0078] Figure 66 shows an example of a roaming process including context transfer.

[0079] Figure 67 shows an example of a roaming process including context passing when a non-AP MLD transmits a roaming request frame.

[0080] Figure 68 shows an example of a roaming process including context passing when the AP MLD transmits a roaming request frame.

[0081] In the present disclosure, “A or B” may mean “only A,” “only B,” or “both A and B.” Alternatively, in the present disclosure, “A or B” may be interpreted as “A and / or B.” For example, in the present disclosure, “A, B or C” may mean “only A,” “only B,” “only C,” or “any combination of A, B and C.”

[0082] A slash ( / ) or a comma used in the present disclosure may mean “and / or.” For example, “A / B” may mean “A and / or B.” Accordingly, “A / B” may mean “only A,” “only B,” or “both A and B.” For example, “A, B, C” may mean “A, B or C.”

[0083] In the present disclosure, “at least one of A and B” may mean “only A,” “only B,” or “both A and B.” Additionally, in the present disclosure, the expressions “at least one of A or B” or “at least one of A and / or B” may be interpreted as synonymous with “at least one of A and B.”

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

[0085] Additionally, “a / an” as used in this disclosure may mean “at least one” or “one or more.” Also, terms ending in “(s)” may mean “at least one” or “one or more.”

[0086] Additionally, the expressions “based on,” “on the basis of,” or “according to” as used in this disclosure mean “based at least in part on,” and do not mean “based only on one.”

[0087] Technical features described individually within one drawing in this disclosure may be implemented individually or simultaneously.

[0088] The following examples of the present disclosure may be applied to various wireless communication systems. For example, the following examples of the present disclosure may be applied to wireless local area network (WLAN) systems. For example, the present disclosure may be applied to IEEE 802.11a / g / n / ac / ax / be / bn standards. Additionally, the examples of the present disclosure may be applied to Ultra High Reliability (UHR) standards or next-generation wireless LAN standards that enhance IEEE 802.11bn. Furthermore, the examples of the present disclosure may be applied to mobile communication systems. For example, they may be applied to mobile communication systems based on Long Term Evolution (LTE) and its evolution based on 3GPP (3rd Generation Partnership Project) standards.

[0089] To explain the technical features of the present disclosure, the technical features to which the present disclosure can be applied are described below.

[0090] FIG. 1 shows an example of a transmitting device and / or receiving device of the present disclosure.

[0091] 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 disclosure may also be referred to by various names such as mobile terminal, wireless device, Wireless Transmit / Receive Unit (WTRU), User Equipment (UE), Mobile Station (MS), Mobile Subscriber Unit, or simply user. The STA (110, 120) of the present disclosure may also be referred to by various names such as network, base station, Node-B, Access Point (AP), repeater, router, relay, etc. The STA (110, 120) of the present disclosure may also be referred to by various names such as receiving apparatus, transmitting device, receiving STA, transmitting STA, receiving device, transmitting device, etc.

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

[0093] The STA (110, 120) of the present disclosure may support various communication standards other than the IEEE 802.11 standard. For example, it may support communication standards according to 3GPP standards (e.g., LTE, LTE-A, 5G NR standards). In addition, the STA of the present disclosure may be implemented in various devices such as mobile phones, vehicles, and personal computers. Furthermore, the STA of the present disclosure may support communication for various communication services such as voice calls, video calls, data communication, and self-driving.

[0094] In the present disclosure, the STA (110, 120) may include a medium access control (MAC) that complies with the specifications of the IEEE 802.11 standard and a physical layer interface for the wireless medium.

[0095] Based on side drawing (a) of Fig. 1, STA (110, 120) is described as follows.

[0096] The first STA (110) may include a processor (111), 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.

[0097] The transceiver (113) of the first STA performs the operation of transmitting and receiving signals. Specifically, it can transmit and receive IEEE 802.11 packets (e.g., IEEE 802.11a / b / g / n / ac / ax / be, etc.).

[0098] 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 transmitted signal, and perform control for transmitting the signal. The memory (112) of the AP can store the signal received through the transceiver (113) (i.e., the received signal) and the signal to be transmitted through the transceiver (i.e., the transmitted signal).

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

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

[0101] For example, the operation of the device designated as AP in the following disclosure may be performed in the first STA (110) or the second STA (120). For example, if the first STA (110) is the AP, the operation of the device designated as 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 (110). Additionally, control information related to the operation of the AP or the transmission / reception signal of the AP may be stored in the memory (112) of the first STA (110). Additionally, if the second STA (110) is the AP, the operation of the device designated as AP is 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 AP or the transmission / reception signals of the AP can be stored in the memory (122) of the second STA (110).

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

[0103] In the following disclosure, a device referred to as (transmission / reception) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmission / reception) Terminal, (transmission / reception) device, (transmission / reception) apparatus, network, etc. may refer to the STA (110, 120) of FIG. 1. For example, a device indicated without specific drawing symbols as (transmission / reception) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmission / reception) Terminal, (transmission / reception) device, (transmission / reception) apparatus, network, etc. may also refer to the STA (110, 120) of FIG. 1. For example, in the following example, the operation of various STAs transmitting and receiving signals (e.g., PPDU) may be performed by the transceiver (113, 123) of FIG. 1. Additionally, in the following example, 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 processor (111, 121) of FIG. 1.For example, an example of an operation to generate a transmission / reception signal or to perform data processing or operations in advance for a transmission / reception signal may include: 1) an operation to determine / acquire / configure / operate / decode / encode bit information of sub-fields (SIG, STF, LTF, Data) included in the PPDU; 2) an operation to determine / configure / acquire time resources or frequency resources (e.g., subcarrier resources) used for sub-fields (SIG, STF, LTF, Data) included in the PPDU; 3) an operation to determine / configure / acquire specific sequences (e.g., pilot sequence, STF / LTF sequence, extra sequence applied to SIG) used for sub-fields (SIG, STF, LTF, Data) included in the PPDU; 4) a power control operation and / or power saving operation applied to the STA; and 5) an operation related to determining / acquiring / configuring / operating / decoding / encoding of an ACK signal. In addition, in the following example, various information (e.g., information related to fields, subfields, control fields, parameters, power, etc.) used by various STAs for determining / acquiring / configuring / calculating / decoding / encoding of transmission and reception signals can be stored in the memory (112, 122) of FIG. 1.

[0104] The device / STA of the aforementioned supplementary drawing (a) of FIG. 1 can be modified as shown in supplementary drawing (b) of FIG. 1. Below, the STA (110, 120) of the present disclosure will be described based on supplementary drawing (b) of FIG. 1.

[0105] For example, the transceiver (113, 123) shown in side drawing (b) of FIG. 1 can perform the same function as the transceiver shown in side drawing (a) of FIG. 1 described above. For example, the processing chip (114, 124) shown in side 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) shown in side drawing (b) of FIG. 1 can perform the same function as the processor (111, 121) and the memory (112, 122) shown in side drawing (a) of FIG. 1 described above.

[0106] 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, AP (Access Point), 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) shown in side drawings (a) / (b) of FIG. 1, or the processing chip (114, 124) shown in side drawing (b) of FIG. 1. That is, the technical features of the present disclosure may be performed in the STA (110, 120) shown in side drawings (a) / (b) of FIG. 1, or only in the processing chip (114, 124) shown in side drawing (b) of FIG. 1. For example, the technical feature of the transmitting STA transmitting a control signal may be understood as a technical feature in which a control signal generated in the processor (111, 121) shown in side drawings (a) / (b) of FIG. 1 is transmitted through the transceiver (113, 123) shown in side drawings (a) / (b) of FIG. 1. Alternatively, the technical feature of the transmitting STA transmitting a control signal may be understood as a technical feature in which a control signal to be transmitted from the processing chip (114, 124) shown in side drawing (b) of FIG. 1 is generated to the transceiver (113, 123).

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

[0108] Referring to side view (b) of FIG. 1, software code (115, 125) may be included in 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.

[0109] The processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include an application-specific integrated circuit (ASIC), other chipsets, logic circuits, and / or data processing devices. 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 EXYNOS® 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 a processor enhanced therefrom.

[0110] In the present disclosure, an uplink may refer to a link for communication from a non-AP STA to an AP STA, and uplink PPDUs / packets / signals, etc. may be transmitted through the uplink. Additionally, in the present disclosure, a downlink may refer to a link for communication from an AP STA to a non-AP STA, and downlink PPDUs / packets / signals, etc. may be transmitted through the downlink.

[0111] Figure 2 is a conceptual diagram showing the structure of a wireless LAN (WLAN).

[0112] The top of Figure 2 shows the structure of the IEEE (Institute of Electrical and Electronic Engineers) 802.11 infrastructure BSS (basic service set).

[0113] Referring to the top of FIG. 2, the wireless LAN system may include one or more infrastructure BSSs (200, 205) (hereinafter BSS). The BSS (200, 205) is a set of APs and STAs, such as an AP (access point, 225) and STA1 (Station, 200-1), that can communicate with each other by successfully synchronizing, and is not a concept referring to a specific area. The BSS (205) may include one or more STAs (205-1, 205-2) that can be combined with one AP (230).

[0114] The BSS may include at least one STA, an AP (225, 230) that provides a distribution service, and a distribution system (DS, 210) that connects multiple APs.

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

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

[0117] In a BSS like the one at the top 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 between STAs and perform communication without APs (225, 230). A network that establishes a network between STAs and performs communication without APs (225, 230) is defined as an ad-hoc network or an independent basic service set (IBSS).

[0118] The bottom of Fig. 2 is a conceptual diagram showing IBSS.

[0119] 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 performs management functions centrally. 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 since access to the distributed system is not allowed, they form a self-contained network.

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

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

[0122] Figure 3 illustrates a network discovery operation that includes an active scanning process as an example. In active scanning, the STA performing the scanning moves between channels and transmits a probe request frame to search for nearby APs, and waits for a response. The responder transmits a probe response frame as a response to the probe request frame to the STA that transmitted the probe request frame. Here, the responder may be the STA that last transmitted a beacon frame from the BSS of the channel being scanned. In a BSS, the AP becomes the responder because it transmits the beacon frame, whereas in an IBSS, the responder is not constant because STAs within the IBSS take turns transmitting the beacon frame. 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 in the same way (i.e., transmit and receive probe request / response on channel 2).

[0123] Although not shown in the example of Fig. 3, scanning operations may also be performed using a passive scanning method. An STA performing scanning based on passive scanning can wait for a beacon frame while switching between channels. A beacon frame is one of the management frames in IEEE 802.11, which announces the presence of a wireless network and is periodically transmitted to allow a scanning STA to find the wireless network and join it. In a BSS, the AP performs the role of periodically transmitting beacon frames, while in an IBSS, STAs within the IBSS take turns transmitting beacon frames. When a scanning STA receives a beacon frame, it stores the information about the BSS included in the beacon frame and records the beacon frame information in each channel while moving to another channel. An STA that has received a beacon frame can store the BSS-related information included in the received beacon frame, move to the next channel, and perform scanning in the next channel in the same manner.

[0124] The STA that discovered the 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 later. The authentication process of S320 may include the STA sending an authentication request frame to the AP, and the AP sending an authentication response frame to the STA in response. The authentication frame used in the authentication request / response corresponds to a management frame.

[0125] The authentication frame may include information regarding the authentication algorithm number, authentication transaction sequence number, status code, challenge text, RSN (Robust Security Network), Finite Cyclic Group, etc.

[0126] The STA can send an authentication request frame to the AP. Based on the information contained in the received authentication request frame, the AP can determine whether to allow authentication for the STA. The AP can provide the result of the authentication process to the STA through an authentication response frame.

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

[0128] Subsequently, 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 4-way handshake via an EAPOL (Extensible Authentication Protocol over LAN) frame.

[0129] The following describes multi-link (ML).

[0130] Terms related to multiple links can be defined as follows:

[0131] - An MLD (multi-link device) may refer to a logical entity that can support multiple affiliated STAs, can operate using one or more affiliated STAs, and provides one MAC data service and a single MAC service access point (SAP) to a logical link control (LLC) sublayer;

[0132] - Multi-link operation (MLO) can refer to operations such as discovery, authentication, multi-link establishment, and frame switching between two MLDs;

[0133] - An associated STA is a STA that provides link-specific downstream MAC and PHY services within an MLD, and may be an AP (Access Point) STA or a non-AP (Non-Access Point) STA;

[0134] - An AP MLD is an MLD where each STA associated with it is an AP;

[0135] - A non-AP MLD is an MLD in which each STA associated with it is a non-AP STA;

[0136] - The linked AP is the AP STA linked to the AP MLD;

[0137] - The linked non-AP STA is the non-AP STA linked to the non-AP MLD.

[0138] Figure 4 illustrates an example of multiple links.

[0139] As illustrated in FIG. 4, multiple multi-link devices (MLDs) can communicate through multiple links. The MLDs can be classified into an AP MLD containing multiple AP STAs and a non-AP MLD containing multiple non-AP STAs. That is, the AP MLD may include affiliated APs (i.e., AP STAs), and the non-AP MLD may include affiliated STAs (i.e., non-AP STAs, or user-STAs).

[0140] A multilink may include a first link and a second link, and different channels / subchannels / frequency resources may be assigned to the first and second links. The first and second multilinks may be identified by 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 link may be configured in different bands.

[0141] The AP MLD of FIG. 4 includes three affiliated APs. In one 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 one 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. Additionally, in one 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. Additionally, in one 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.

[0142] In an example of FIG. 4, AP1 may initiate a multilink setup procedure (ML setup procedure) by transmitting an Association Request frame to non-AP STA1. In an 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) shown in FIG. 4 may be identical to the AP shown in FIG. 1 and / or FIG. 2, and each non-AP (e.g., non-AP1 / 2 / 3) shown in FIG. 4 may be identical to the STA shown in FIG. 1 and / or FIG. 2 (i.e., user-STA or non-AP STA). Once the ML setup is complete, an enabled link for ML communication may be determined. The STA may perform frame exchange through at least one of the multiple links determined as the enabled link. For example, the enabled link may be used for at least one of a management frame, a control frame, and a data frame.

[0143] When a single STA supports multiple links, the transmitting and receiving devices supporting each link can operate as a single logical STA. For example, a single STA supporting two links can be represented as a single Multi-Link Device (MLD) comprising a first STA for the first link and a second STA for the second link. For example, a single AP supporting two links can be represented as a single AP MLD comprising a first AP for the first link and a second AP for the second link. Additionally, a single non-AP supporting two links can be represented as a single non-AP MLD comprising a first STA for the first link and a second STA for the second link.

[0144] Below, more specific features regarding the ML setup are explained.

[0145] An MLD (AP MLD and / or non-AP MLD) may transmit information regarding links that the MLD can support through an ML setup. Information regarding links may be configured in various ways. For example, information regarding links may include at least one of: 1) information regarding whether the MLD (or STA) supports simultaneous RX / TX operation; 2) information regarding the number / upper limit of uplink / downlink links supported by the MLD (or STA); 3) information regarding the location / band / resource of uplink / downlink links supported by the MLD (or STA); 4) information regarding the type of frame (management, control, data, etc.) available or preferred on at least one uplink / downlink link; 5) information regarding the ACK policy available or preferred on at least one uplink / downlink link; and 6) information regarding the TID (traffic identifier) ​​available or preferred on at least one uplink / downlink link. TID is related to the priority of traffic data and is expressed as 8 types of values ​​according to conventional wireless LAN standards. That is, 8 TID values ​​can be defined corresponding to the 4 access categories (AC) (AC_BK (background), AC_BE (best effort), AC_VI (video), AC_VO (voice)) according to conventional wireless LAN standards.

[0146] For example, all TIDs can be pre-configured to be mapped to the uplink / downlink Link. Specifically, if no negotiation is made through the ML setup, all TIDs are used for ML communication, and if a mapping between the uplink / downlink Link and the TID is negotiated through additional ML setup, the negotiated TID can be used for ML communication.

[0147] Through ML setup, multiple links that can be used by the transmitting MLD and receiving MLD related to ML communication can be established, and these can be called “enabled links.” “Enabled links” can be referred to by various other expressions. For example, they can be referred to by various expressions such as the first link, the second link, the transmitting link, and the receiving link.

[0148] After the ML setup is completed, the MLD can update the ML setup. For example, if the MLD needs to update information about a link, it can transmit information about a new link. Information about a new link may be transmitted based on at least one of a management frame, a control frame, and a data frame.

[0149] The specific features of the present disclosure are not limited to the specific features of FIG. 4. That is, the number of links can be defined in various ways, and a plurality of links can be defined in various ways within at least one band.

[0150] FIG. 5 shows a modified example of a transmitting device and / or receiving device of the present disclosure.

[0151] The device illustrated in FIGS. 1 to 4 (e.g., AP STA, non-AP STA) can be modified as in FIG. 5. The transceiver (530) of FIG. 5 may be identical to the transceiver (113, 123) of FIG. 1. The transceiver (530) of FIG. 5 may include a receiver and a transmitter.

[0152] The processor (510) of FIG. 5 may be the same as the processor (111, 121) of FIG. 1. Alternatively, the processor (510) of FIG. 5 may be the same as the processing chip (114, 124) of FIG. 1.

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

[0154] Referring to FIG. 5, a power management module (511) manages power for a processor (510) and / or a transceiver (530). A battery (512) supplies power to the power management module (511). A display (513) outputs results processed by the processor (510). A keypad (514) receives input to be used by the processor (510). The keypad (514) may be displayed on the display (513). A SIM card (515) may be an integrated circuit used to securely store an international mobile subscriber identity (IMSI) and associated keys used to identify and authenticate a subscriber in a mobile device such as a mobile phone and a computer.

[0155] Referring to FIG. 5, the speaker (540) can output sound-related results processed by the processor (510). The microphone (541) can receive sound-related inputs to be used by the processor (510).

[0156] FIG. 6 illustrates an example of a PPDU (physical protocol data unit or physical layer (PHY) protocol data unit) transmitted / received in an STA of the present disclosure.

[0157] The STA of the present disclosure (e.g., AP STA, non-AP STA, AP MLD, non-AP MLD) can transmit and / or receive the PPDU of FIG. 6. The PPDU described in the present disclosure may have the structure of FIG. 6, for example. Additionally, the PPDU described in the present disclosure may be referred to by various names such as Ultra High Reliability (UHR) PPDU, Transmit PPDU, Receive PPDU, Type 1, or Type N PPDU. The PPDU described in the present disclosure may be used in WLAN systems defined according to IEEE 802.11bn and / or next-generation WLAN systems that improve upon IEEE 802.11bn.

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

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

[0160] Each block shown in FIG. 6 can be referred to as a field / subfield / signal, etc. As shown in FIG. 6, the names of these fields / subfields / signals may be 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.

[0161] The subcarrier spacing of the L-STF, L-LTF, L-SIG, RL-SIG, U-SIG, and UHR-SIG fields in Fig. 6 can be set to 312.5 kHz, and the subcarrier spacing of the UHR-STF, UHR-LTF, and Data fields can 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 can be displayed in units of 312.5 kHz, and the tone index (or subcarrier index) of the UHR-STF, UHR-LTF, and Data fields can be displayed in units of 78.125 kHz.

[0162] The PPDU of Fig. 6, L-LTF and L-STF, may be the same as conventional fields (e.g., non-HT LTF and non-HT STF defined in conventional WLAN standards).

[0163] The L-SIG field of FIG. 6 may contain, 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 contain information regarding 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 a UHR PPDU, the value of the Length field may be determined as a multiple of 3. For example, if the PPDU is an 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, or 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 a UHR PPDU is set to a value satisfying the condition that the remainder is zero when LENGTH is divided by 3.

[0164] For example, a (non-AP and AP) STA can apply BCC encoding based on a code rate of 1 / 2 to 24 bits of information in the L-SIG field. Subsequently, the transmitting STA can obtain 48 bits of BCC encoding. BPSK modulation can be applied to the 48 bits of encoding to generate 48 BPSK symbols. The transmitting STA can map the 48 BPSK symbols to positions excluding the pilot subcarrier {subcarrier indices -21, -7, +7, +21} and the DC subcarrier {subcarrier index 0}. Consequently, 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 of {-1, -1, -1, 1} to the subcarrier index {-28, -27, +27, +28}. The above signal can be used for channel estimation for the frequency domain corresponding to {-28, -27, +27, +28}.

[0165] For example, the (non-AP and AP) STA can generate an RL-SIG that is identical to the L-SIG. BPSK modulation may be applied to the RL-SIG. The receiving (non-AP and AP) STA can determine that the received PPDU is a HE PPDU, EHT PPDU, or UHR PPDU based on the presence of the RL-SIG. In other words, the receiving (non-AP and AP) STA can determine that the received PPDU is one of the HE PPDU, EHT PPDU, or UHR PPDU if the RL-SIG is present. In other words, the receiving (non-AP and AP) STA can determine that the received PPDU is one of the non-HT PPDU, HT PPDU, or VHT PPDU if the RL-SIG is not present. 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.

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

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

[0168] For example, A bit information (e.g., 52 un-coded bits) can be transmitted through U-SIG, and the first symbol of U-SIG can transmit the first X bit information (e.g., 26 un-coded bits) of the total A bit information, and the second symbol of U-SIG can transmit the remaining Y bit information (e.g., 26 un-coded bits) of the total A bit information. For example, the transmitting STA can obtain the 26 un-coded bits included in each U-SIG symbol. The transmitting STA can generate 52-coded bits by performing convolutional encoding (i.e., BCC encoding) based on a rate of R=1 / 2 and can perform interleaving on the 52-coded bits. The transmitting STA can generate 52 BPSK symbols assigned to each U-SIG symbol by performing BPSK modulation on the interleaved 52-coded bits. 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. 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.

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

[0170] A bit information (e.g., 52 un-coded bits) transmitted by 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 may be assigned only to the first symbol of U-SIG, or the version-independent bits may be assigned to both the first and second symbols of U-SIG. For example, the version-independent bits and the version-dependent bits may be referred to by various names, such as the first control bit and the second control bit.

[0171] For example, the version-independent bits of 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 of the 3-bit PHY version identifier (e.g., a value of 000) may indicate that the transmitted and received PPDU is an EHT PPDU. Additionally, a second value of the 3-bit PHY version identifier (e.g., a value of 001) may indicate that the transmitted and received PPDU is a UHR PPDU.

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

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

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

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

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

[0177] Preamble puncturing may be applied to the PPDU of Fig. 6. Preamble puncturing means applying puncturing to a portion of the total band of the PPDU (e.g., a 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.

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

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

[0180] 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 configured individually in 80 MHz units. 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 regarding a 160 MHz bandwidth, and the second field of the second U-SIG may include information regarding preamble puncturing applied to the second 80 MHz band (i.e., information regarding a preamble puncturing pattern). Meanwhile, the UHR-SIG following the first U-SIG may include information regarding preamble puncturing applied to the second 80 MHz band (i.e., information regarding a preamble puncturing pattern), and the UHR-SIG following the second U-SIG may include information regarding preamble puncturing applied to the first 80 MHz band (i.e., information regarding a preamble puncturing pattern).

[0181] Additionally or generally, U-SIG and UHR-SIG may include information regarding preamble puncturing based on the following method. 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).

[0182] 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 may contain different U-SIGs.

[0183] The UHR-SIG of FIG. 6 may include control information for a receiving STA. The UHR-SIG may be transmitted through at least one symbol, and one 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.

[0184] UHR-SIG provides additional signals to the U-SIG field, enabling the STA to interpret / decode the UHR PPDU. The UHR-SIG field may include U-SIG overflow bits that apply commonly to all users. Additionally, the UHR-SIG field contains resource allocation information, making it possible for the STA to look up resources used in fields containing data fields / UHR-STF / UHR-LTF (i.e., UHR modulated fields of an UHR PPDU).

[0185] The frequency resources of the UHR-LTF, UHR-STF, and data fields illustrated in FIG. 6 can be determined based on a RU (resource unit) defined by a plurality of subcarriers / tones. That is, the UHR-LTF, UHR-STF, and data fields of the present disclosure can be transmitted / received through a RU (resource unit) defined by a plurality of subcarriers / tones.

[0186] The structure and types / subtypes of MAC frames are described below.

[0187] FIG. 7 illustrates an example of a MAC frame header. As illustrated, the MAC frame may include a frame control field / information of 2 octets, a duration field / information of 2 octets, a Receiver Address (RA) field / information of 6 octets, and a Transmitter Address (TA) field / information of 6 octets. As illustrated in FIG. 7, the four fields may be consecutive. The MAC header of FIG. 7 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.

[0188] The MAC header shown in FIG. 7 may be located at the very beginning of the MAC frame. That is, the MAC frame may include a MAC header such as that in FIG. 7 and a MAC body field / information following the MAC header. The MAC frame containing the MAC header of FIG. 7 is inserted / included in the data field of a PPDU (e.g., UHR PPDU).

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

[0190] For example, a 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 WLANs. For the management frame, the value of the type field (B3 and B2) of the MAC header is set to 00. Additionally, the value of the subtype field (B7, B6, B5, B4) of the MAC header is 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).

[0191] For example, the control frame includes the 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 WLANs. For the control frame, the values ​​of the type fields (B3 and B2) of the MAC header are set to 01. Also, the values ​​of the subtype fields (B7, B6, B5, B4) of the MAC header 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).

[0192] For example, the data frame includes (QoS) Data, (QoS) Null, etc., defined in conventional WLANs. For the data frame, the value of the type field (B3 and B2) of the MAC header is set to 10.

[0193] The MAC frames / signals used in this disclosure can be identified through the type field / information and subtype field / information described above. The various MAC frames described in this disclosure are inserted / included in the data fields of various PPDUs (e.g., HE / VHT / HE / EHT / UHR PPDUs).

[0194] Figure 8 shows the Over-the-air (OTA) FT protocol in the Robust Security Network (RSN).

[0195] Currently, in 802.11, for a non-AP STA to move from an AP (Old AP) to another AP (New AP), that is, to transition to a Basic Service Set (BSS), it must undergo a reassociation process within the same mobility domain. A representative example is Fast BSS Transition (FT) technology. In FT, as shown in Figure 8, the process involves several steps such as authentication and reassociation with the FT Originator (FTO) and the Target FT Responder (FTR) (i.e., the New AP).

[0196] After this process, many operational parameters, such as Agreements related to BlockAck (BA) and Stream Classification Service (SCS), Sequence Numbers (SN), and EDCAF Parameters, are reset. Consequently, there is overhead in that negotiations and configurations must be performed again 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 movement is not easy. Therefore, to address this, the present disclosure proposes a continuous roaming method utilizing an AP Multi-Link Device (MLD). Unlike FT, the authentication and association processes are not performed again during roaming.

[0197] In the present disclosure, a non-AP MLD / STA may perform roaming from a serving / source AP MLD to another AP MLD (i.e., a target AP MLD). Alternatively, a non-AP MLD / STA may perform roaming from at least one AP of the serving / source AP MLD to at least one AP of the other AP MLD (i.e., a target AP MLD). In this case, the non-AP MLD / STA may maintain a connected and authenticated state during and after roaming to the other AP MLD. Roaming may include the action of establishing a link with at least one AP of the target AP MLD and / or the action of disconnecting a link with at least one AP of the serving / source AP MLD. For example, the non-AP MLD / STA may establish a link with at least one AP of the target AP MLD and then disconnect the link with at least one AP of the serving / source AP MLD. As another example, a non-AP MLD / STA can establish a link with at least one AP of the target AP MLD after releasing the link with at least one AP of the serving / source AP MLD.

[0198] In the present disclosure, a STA performing a BSS transition (e.g., roaming) is referred to as an RSTA, and when the STA roams, the currently connected AP is referred to as an Old AP (O_AP), and the AP to be roamed is referred to as a New AP (N_AP). Additionally, the roaming method proposed in the present disclosure is referred to as MLD roaming. Designations (names) in the present disclosure may be changed, and a STA may include an AP STA and / or a non-AP STA.

[0199] Terms related to roaming used in this disclosure are as follows:

[0200] - SMD (Seamless Mobility Domain): A mobility domain (or group / roaming group) composed of multiple AP-MLDs, referring to a domain where non-AP MLDs can perform SMD BSS transitions between each AP MLD while maintaining a connection with the SMD-ME (Management Entity).

[0201] - SMD-ME: An entity that manages the association, authentication, and security association of non-AP MLDs within SMD.

[0202] - SMD BSS transition (or, roaming / seamless transition (ST): refers to a form of BSS transition performed to minimize the time the data connection between the non-AP MLD and the DS is disconnected when a non-AP MLD moves between AP MLDs belonging to the same SMD.

[0203] Figure 9 shows the upper-level architecture of the AP MLD.

[0204] Referring to FIG. 9, the AP MLD may include at least one AP. The MLD can control various procedures / parameters that are common to multiple APs using an upper MAC layer / sublayer. For example, the MLD can perform / control authentication, connection, SN (sequence number) / PN (packet number) allocation, and power-saving buffering of individually addressed frames.

[0205] Therefore, when the AP MLD function is used, when a non-AP MLD / STA moves / roams between APs associated with the AP MLD, the parameters of the MLD level can be maintained without being reset. In this disclosure, a roaming method utilizing the functionality of the AP MLD is proposed.

[0206] Figure 10 shows an example of a high-level architecture for UHR AP MLD.

[0207] In Fig. 10, APs can support continuous roaming. To support continuous roaming, they must be compatible with devices of previous standard versions and capable of continuous roaming among many devices. First, to ensure legacy compatibility with previous devices, non-UHR non-AP STAs must be able to recognize non-UHR APs. To achieve this, the existing architecture must not be altered without infringing upon the defined specifications for the MLD. Therefore, as shown in Fig. 10, a UHR AP MLD can be defined that links MLDs capable of continuous roaming hierarchically while maintaining the architecture of the existing MLD. In this case, each LMAC of the AP MLDs has an interface with the UHR UMAC, and the functions of the UMAC of the AP MLD performing continuous roaming can be managed by the UHR UMAC.

[0208] Figure 11 shows an example of a high-level architecture for a UHR AP MLD including separate entities.

[0209] Referring to FIG. 11, a separate entity can manage various functionalities for roaming between AP MLDs (e.g., multi-link authentication such as PTK, multi-link discovery / setup, multi-link reconfiguration). That is, the present disclosure does not limit the targets supporting roaming to UMAC, and a separate entity can also support roaming. The entity can manage control plane contexts and, if necessary, manage targets other than control plane contexts. AP MLDs and UHR AP MLDs may each be individually connected to a DS.

[0210] The architectures described above (e.g., the architectures exemplified in FIG. 10 and / or FIG. 11) can also resolve the scalability issue caused by the bit size limitation of the link ID. Basically, the link ID is 4 bits and can only support a maximum of 16 link IDs. This link ID is required to move from one link to another during roaming, but the number of roaming APs is limited to 16 under the existing method. To solve this, the scalability issue is resolved by grouping link IDs into AP MLD IDs.

[0211] Figure 12 shows another example of a top-layer architecture for UHR AP MLD.

[0212] Figure 12 shows an example having an architecture similar to Figure 10 but with different interfacing. Figure 12 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 among the functions of the UMAC. In this architecture, TID-to-Link mapping can be performed individually by the UMAC of the AP MLD or by the UHR UMAC. The AP MLD and the UHR AP MLD may each be individually connected to the DS. The method of utilizing this architecture and the types and number of functions interfaced with the UHR UMAC are not limited.

[0213] Figure 13 shows a first example of an architecture with only entities and not based on MLD.

[0214] Referring to Fig. 13, in an architecture like Fig. 11, entities can exist independently without being included in the UHR AP MLD.

[0215] Figure 14 shows a second example of an architecture in which there are only entities and not based on MLD.

[0216] Referring to Fig. 14, in an architecture like Fig. 12, the entity can replace the UHR UMAC and exist independently without being included in the UHR AP MLD.

[0217] The entities in FIGS. 11, 12, and 14 have functions for roaming. Roaming AP MLDs are connected to a single entity and can perform operations such as association, authentication, and link setup with this entity. The entity can also manage control plane contexts. Roaming AP MLDs can form groups based on the concept of a domain (e.g., SMD), where one or more entities (e.g., SMD-ME) may exist within a single domain. The entity can manage contexts that must be shared between APs for Non-AP STAs to perform seamless roaming.

[0218] The deployment of AP MLDs for roaming is shown in Fig. 15.

[0219] Figure 15 shows the arrangement of AP MLDs for roaming.

[0220] Referring to Fig. 15, each AP MLD is located in a different location, i.e., non-collocated, and the APs belonging to or associated with each AP MLD are located in the same or similar location, i.e., collocated. The collocation of APs may mean that the APs belong to the exact same physical device, or that they are in logically similar locations even if they do not belong to the exact same physical device. Basically, since an AP MLD is a logical entity, it may be a single physical device, but it can operate as an MLD that covers associated APs regardless of location and applies MLOs. Ultimately, all APs belonging to each AP MLD may be associated APs of a group-managing AP MLD (e.g., UHR AP MLD / SMD-ME). For example, AP MLD 1 in Fig. 15 may include associated APs 1, AP2, and AP3.

[0221] In the present disclosure, AP MLDs including APs associated with a group-managed AP MLD may be included in a roaming group (or SMD), and roaming may be performed between AP MLDs / APs included in the roaming group. In other words, roaming between AP MLDs included in the roaming group is possible, but roaming between an AP MLD included in the roaming group and an AP MLD not included in the roaming group may not be possible. An AP MLD included in the roaming group may be referred to as a group member AP MLD. For example, in FIG. 15, AP MLD 1, AP MLD 2, and AP MLD 3 may be group member AP MLDs.

[0222] When a non-AP MLD / STA moves, the non-AP MLD / STA can perform roaming from one AP MLD to another. For example, when a non-AP MLD has a multi-link configuration with an AP MLD and each 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 can be connected to AP 4 and STA 2 can be connected to AP 5. In this case, during the roaming process, each STA may temporarily establish a connection with AP 4 and AP 5 so that AP 4 and AP 5 can transmit frames to each STA.

[0223] In Fig. 15, a non-AP MLD with multiple linked STAs is illustrated, but this architecture can also be applied to a non-AP MLD with a single linked STA or to a non-AP STA that is not an MLD.

[0224] In the present disclosure, movement between different AP MLDs is not necessarily considered roaming. For example, a non-AP MLD / STA can change APs through roaming even within one AP MLD.

[0225] A UHR AP MLD (or, group-managed AP MLD / SMD-ME) is associated with at least one (EHT) AP MLD, each AP MLD is non-collocated, and the APs belonging to each AP MLD are collocated. A non-AP MLD (or STA) can roam from one AP MLD to another AP MLD. A STA can change APs through roaming within a specific AP MLD.

[0226] When changing APs within an AP MLD, roaming may be considered by changing links while maintaining the multi-link settings without disabling the existing multi-link settings.

[0227] For roaming, a) broadcasting procedures and b) frame exchange may be performed.

[0228] a) Broadcasting procedure: Broadcasts information related to roaming APs within the AP MLD to the STAs, including information indicating whether each AP of the AP MLD can perform the MLD roaming proposed in the present disclosure.

[0229] b) Frame exchange procedure: A procedure for exchanging frames that can trigger MLD roaming. Once the frame exchange is complete, MLD roaming is completed based on the exchanged / negotiated information, and operations are no longer performed with O_AP, but with N_AP.

[0230] In the present disclosure, the following methods may be used for MLD roaming:

[0231] - One or more STAs belonging to a non-AP MLD can establish multiple links. Therefore, methods for adding and deleting links for a single STA can be used. Thus, two or more links can be established for a single STA.

[0232] However, since frame switching is performed on only one link and cannot be done on the remaining links, the remaining links may be in a doze or disabled state.

[0233] - A non-AP MLD can indicate whether it possesses the capabilities described above when transmitting a connection request frame during ML setup, or a management frame containing the basic multi-link ML IE. This information may be included in the "Capabilities and Operations" subfield of the common information field if applicable to all STAs, or in the link information field if applicable to only some STAs. For example, "Single-radio ML setup enabled" may be included. "Single-radio ML setup enabled" indicates that a STA of a non-AP MLD can establish multiple links, each with one radio transceiver. Therefore, it implies that two or more links can be connected to a single STA.

[0234] Broadcasting for MLD roaming

[0235] Each AP of each AP MLD may announce information regarding whether roaming proposed in this disclosure is possible (e.g., whether “b) frame switching procedure” is possible). Information broadcast in common to all APs may include information regarding whether the AP belongs to a UHR AP MLD and / or entity, information regarding which UHR AP MLD / entity the AP belongs to, and / or collocation information. If an architecture in which the AP MLD is affiliated with a UHR AP MLD is used, information regarding whether the AP MLD is affiliated with a UHR AP MLD and / or UHR AP MLD ID information may be broadcast. If an entity-based architecture is used, information regarding whether the AP MLD is affiliated with an entity and / or information identifying the entity (e.g., entity ID) may be broadcast.

[0236] For example, at least one of the following may be broadcast:

[0237] - UHR MLD MAC address (or MAC address for the roaming group): The MAC address commonly used by AP MLDs included in the roaming group.

[0238] - MLD roaming enabled: Indicates whether roaming is possible. For example, if AP MLDs / APs are connected to the same UHR AP MLD or to the same entity, roaming is possible between those AP MLDs / APs. If AP MLDs / APs are connected to different UHR AP MLDs or to different entities (i.e., if AP MLDs / APs belong to different mobility domains), roaming may not be possible between those AP MLDs / APs. As such, roaming availability can be indicated by the MLD roaming enabled bit (e.g., 1 bit).

[0239] - UHR AP MLD ID: An ID that identifies the AP group. The settings for this group ID can be as follows:

[0240] A. Setting ID for Roaming in AP MLD

[0241] Basically, an ID can be assigned to a UHR AP MLD (or, group-managed AP MLD) that links the collocated AP MLDs. In this disclosure, this is referred to as a UHR AP MLD ID (or, group-managed AP MLD ID / roaming group ID / group ID). Such a UHR AP MLD ID may be unique within the UHR AP MLD / roaming group or unique to the UHR AP MLD / roaming group within the entire network. By defining a UHR AP MLD ID / group ID to distinguish UHR AP MLD / roaming groups, it is possible to resolve scalability issues caused by the limited number of links and help identify more APs.

[0242] A-1) Setting a unique ID within the UHR AP MLD in the network

[0243] This section proposes a method for UHR AP MLD IDs to be unique within a network. By default, UHR AP MLD IDs can have values ​​such as 0, 1, 2, etc. For example, if a UHR AP MLD ID has 4 bits, it can have values ​​from 0 to 15, and if it has 8 bits, it can have values ​​from 0 to 127; these bit sizes may change. The following explains the meaning of each UHR AP MLD ID / Group ID:

[0244] 1) When the UHR AP MLD ID / Group ID is 0: In this case, it can be determined that the APs with this UHR AP MLD ID / Group ID belong to the AP MLD within the same UHR AP MLD / Roaming Group. That is, if a non-AP MLD (or STA) recognizes this, it can recognize that the APs currently belong to the same UHR AP MLD / Roaming Group. Therefore, roaming is possible only when the UHR AP MLD ID / Group ID is 0. Additionally, this UHR AP MLD ID / Group ID is assigned to other APs (transmitted BSSID (TxBSSID) or nontransmitted BSSID (NonTxBSSID)) within the multi-BSSID set to which each AP in this UHR AP MLD / Roaming Group belongs, because they also use the same physical resources. However, the AP MLD ID of the AP MLD to which these APs belong (transmitted BSSID (TxBSSID) or nontransmitted BSSID (NonTxBSSID)) may be different.

[0245] Different UHR AP MLD IDs / group IDs are mapped so that each UHR AP MLD / roaming group can be uniquely recognized.

[0246] A-2) Setting a unique ID within AP MLD

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

[0248] - Temporary Link Add / Remove: Indicates whether links can be temporarily added or removed for a STA. In other words, it means that a STA is supported to have two or more links for a certain period of time (e.g., indicated by 1 bit).

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

[0250] For example, if Collocation enabled = 1, it means that the AP and the reporting AP are physically close. Therefore, since communication with the existing connected AP is possible without moving to the AP set to 1, roaming may not occur if a neighboring AP has Collocation enabled = 1. In other words, MLD roaming requests / responses are not sent to or received by the AP with Collocation enabled = 1.

[0251] - Collocation ID: An ID that distinguishes collocated AP MLDs. The settings for this Collocation ID are as follows:

[0252] B. Setting Collocation ID for Roaming in UHR AP MLD / Group

[0253] Basically, IDs can be assigned to collocated AP MLDs. In this disclosure, this is referred to as a Collocation ID. Such a Collocation ID may be unique within a set of collocated AP MLDs, or may be unique to a collocated AP MLD within a UHR AP MLD / roaming group.

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

[0255] This section proposes a method for ensuring that Collocation IDs are unique within a collocated set of AP MLDs. By default, Collocation IDs can have values ​​such as 0, 1, 2, etc. For example, if a Collocation ID has 4 bits, it can have values ​​from 0 to 15, and if it has 8 bits, it can have values ​​from 0 to 127; these bit sizes can be changed. The following explains the meaning of each Collocation ID:

[0256] When the Collocation ID is 0: In this case, the APs with this Collocation ID can be considered as belonging to the same set of collocated AP MLDs. That is, if the MLD (or STA) recognizes this, the APs can be recognized as currently collocated. Additionally, this Collocation ID is assigned because other APs (transmitted BSSID (TxBSSID) or nontransmitted BSSID (NonTxBSSID)) in the multi-BSSID set to which each AP in this set belongs also use the same physical resources. However, the AP MLD ID of the AP MLD (transmitted BSSID (TxBSSID) or nontransmitted BSSID (NonTxBSSID)) to which these APs belong may be different.

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

[0258] Other Collocation IDs can be mapped so that they can be uniquely recognized for each collocated AP MLD set.

[0259] B-2) Setting a unique Collocation ID within a UHR AP MLD / Roaming Group

[0260] This section proposes a method for assigning a unique Collocation ID to a set of AP MLDs collocated within a UHR AP MLD / roaming group. By default, the Collocation ID can be assigned values ​​such as 0, 1, 2, ... For example, if the Collocation ID has 4 bits, it can have values ​​from 0 to 15, and if it has 8 bits, it can have values ​​from 0 to 127, and the bit size can be changed.

[0261] The above information (e.g., UHR MLD MAC address (or MAC address for a roaming group), MLD roaming enabled, UHR AP MLD ID / group ID, Collocation enabled, Collocation ID, temporary link addition / deletion) may be referred to as MLD roaming parameters or / or may be included in MLD roaming parameters. MLD roaming parameters may be included in management (MGMT) frames, such as beacon frames and / or probe response frames, and may be included in an MLD roaming IE containing new MLD roaming information or an existing Reduced Neighbor Report (RNR) IE (Information Element).

[0262] The following is an example of a case where MLD roaming parameters are included in the RNR IE. Basically, for each AP, MLD roaming parameters may be included within the TBTT information field. The MLD roaming parameters may include at least one of the fields shown in FIGS. 16 and 17, and the arrangement of the fields may be as shown in FIGS. 16 and 17. In addition, in addition to the fields shown in FIGS. 16 and 17, at least one of the fields defined in the present disclosure may be included.

[0263] Figure 16 shows an example for RNR IE.

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

[0265] Figure 17 shows another example for RNR IE.

[0266] Non-AP STAs send and receive MLD roaming requests / responses only to APs with non-zero Collocation IDs via RNR IE.

[0267] As shown in FIGS. 16 and 17, if the size of the existing MLD parameter subfield is insufficient, a new MLD roaming parameter subfield can be created in the RNR IE to include information. Although the size of the existing MLD parameter subfield can be changed, this has the problem of potentially causing decoding issues for 802.11be STAs. In this case, since including the MLD roaming parameter itself may imply that MLD roaming is possible, the MLD roaming parameter subfield may not include MLD roaming Enabled.

[0268] As shown in FIG. 16, the RNR IE includes a Collocation Enabled field to indicate only whether another AP is collocated or non-collocated with the AP currently sending the beacon or probe response, thereby reducing overhead. Additionally, as shown in FIG. 17, it can indicate which AP is included in which collocation set by providing the AP's Collocation ID. The RNR IE may include at least one of the Collocation Enabled field or the Collocation ID.

[0269] Figure 18 shows another example of RNR IE.

[0270] As shown in FIG. 18, if only whether MLD roaming is possible (i.e., MLD roaming enabled) is included, MLD roaming Enabled can be indicated using the existing MLD parameter subfield. Other information may be included in a separate parameter (e.g., MLD roaming parameter) as shown in FIG. 16 or FIG. 17.

[0271] In some implementations, APs for continuous roaming may be recommended. Below, a method for recommending AP(s) to roam for continuous roaming and a method for signaling related information are described.

[0272] Based on the MLD roaming enabled in the RNR IE received via a management frame, the non-AP MLD / STA may request information from the AP MLD / STA regarding the APs to which it wishes to roam (or APs to which it can propose roaming) via an ML probe request frame, regarding the APs that are enabled (or capable of roaming). In response to the ML probe request frame, the AP MLD / STA may notify the non-AP MLD / STA of information regarding whether the AP is suitable for roaming (or a list of APs to which roaming is proposed) via an ML probe response frame and / or a link reconfiguration notify frame. When sending an ML probe request frame to roam to the corresponding AP, ML roaming enabled=1 may be set.

[0273] (1) ML probe request frame format for AP proposal

[0274] In order to reduce the overhead that may occur when an AP makes unnecessary AP proposals for probe requests that are not related to roaming, an AP roaming proposal enabled field (or, simply roaming proposal enabled field) may be added to the ML probe request frame.

[0275] 1) If the roaming suggestion possible field is included in the common information field

[0276] FIG. 19 shows an example of the structure of an ML probe request frame when the common information field includes a roaming proposal possible field according to an embodiment of the present disclosure.

[0277] Referring to FIG. 19, the presence bitmap subfield of the probe request ML IE can indicate whether the AP roaming proposal possible field is included in the common information field of the probe request ML IE. If the AP roaming proposal possible field is included in the common information field, information about all APs to which the probe request frame is transmitted can be requested for roaming. That is, if at least one AP is included in the ML probe request frame for other operations such as connection rather than roaming, the AP roaming proposal possible field is not added to the common information field.

[0278] When an STA requests a recommendation for one or more AP MLDs, it may request recommendations for APs of one or more AP MLDs associated with the same SMD and / or UHR AP MLD by transmitting a request frame (e.g., an ML probe request frame) that does not include an AP MLD ID field.

[0279] Additionally, to reduce overhead, the AP roaming offer enabled presence field may be omitted from the presence field, and the AP roaming offer enabled field may be added only to the common information field.

[0280] 2) If the roaming suggestion available field is included in the link information field

[0281] FIG. 20 shows an example of the structure of an ML probe request frame when the link information field includes a roaming proposal possible field according to an embodiment of the present disclosure.

[0282] Referring to FIG. 20, if a roaming proposal possible field is included in the link information field, information about the APs can be requested individually for roaming. If at least one AP is included in the ML probe request frame to perform an action such as a connection rather than roaming, an AP roaming proposal possible field can be added to the link information field.

[0283] In cases where proposals are made individually to one or more AP MLDs rather than commonly to all AP MLDs belonging to a single UHR AP MLD and / or entity, the AP MLDs to be proposed may be indicated using the UHR AP MLD and / or AP MLD IDs in the STA control field instead of using the AP MLD IDs in the common information field.

[0284] When making proposals for one or more AP MLDs, the link information field may be repeatedly included for the proposal. In this case, there may be at least two methods to read the last field of the Per-STA profile and identify that another Per-STA profile for another AP MLD exists thereafter.

[0285] For example, based on the value indicated in the Number of Per-STA profile(s) field in the common information field, AP / STA can identify the total number of Per-STA profiles that exist, i.e., the number of proposed AP MLDs, and can identify that the corresponding number of Per-STA profiles exist. Therefore, AP / STA can decode the corresponding number of Per-STA profiles.

[0286] For example, the More STA control field of a Per-STA profile can be utilized. If the More STA control field is set to 1, it may indicate that another Per-STA profile exists after the Per-STA profile currently being decoded. A Per-STA profile with the More STA control field set to 0 may indicate that the Per-STA profile is for the last AP MLD among the proposed AP MLDs.

[0287] If the link information field is not included, this may indicate that a proposal is being requested for all STAs associated with the non-AP MLD.

[0288] (2) ML probe response frame format for AP proposal

[0289] Based on MLD roaming enabled, the non-AP MLD / STA can request information from the AP MLD / STA regarding APs that are enabled (or capable of roaming) through an ML probe request frame regarding APs that the non-AP MLD / STA wishes to roam (or APs that can propose roaming). In response to the ML probe request frame, the AP MLD / STA can inform the non-AP MLD / STA through an ML probe response frame of information regarding whether the AP is suitable for roaming (or a list of APs for which roaming is proposed).

[0290] For example, an ML probe response frame may include a list of APs suitable for roaming (or APs suggested for roaming) (e.g., Recommended AP list). The list of APs suitable for roaming (or APs suggested for roaming) may include a list of link IDs associated with the APs suitable for roaming (or APs suggested for roaming).

[0291] Frame exchange for MLD roaming

[0292] For MLD roaming to be triggered, frame exchange is required between a Non-AP MLD (or STA) and an AP MLD. Here, MGMT frames can be utilized, specifically Action frames, which are a type of MGMT frame. Frames related to roaming can be referred to as follows:

[0293] A frame in which an STA requests MLD roaming from an AP can be called an MLD roaming request frame (or, a roaming request frame). A roaming request frame can also be referred to as an ST preparation request, and as a frame transmitted by a non-AP MLD to an AP MLD to prepare a target AP MLD, it can refer to a UHR Link Reconfiguration Request frame in which the Type field of the frame is set to 0.

[0294] A frame in which an AP requests MLD roaming from a STA can be called an MLD roaming response frame (or, roaming response frame). A roaming response frame can also be referred to as an ST preparation response, and as a frame transmitted by an AP MLD to a non-AP MLD in response to a ST preparation request, it can refer to a UHR Link Reconfiguration Response frame in which the Type field of the frame is set to 1.

[0295] Examples of roaming procedures based on the exchange of roaming request frames and roaming response frames (and broadcasting for roaming) are described below.

[0296] Figure 21 shows a baseline continuous roaming procedure.

[0297] Referring to FIG. 21, a non-AP MLD or an AP MLD can transmit a roaming request frame. After the roaming request frame is transmitted, a link can be established between the target AP MLD and the non-AP MLD. Once a link is established between the target AP MLD and the non-AP MLD, the non-AP MLD or the AP MLD can transmit a roaming response frame. The roaming response frame may contain information regarding the success or failure of the link establishment. The roaming request frame and / or roaming response frame can be transmitted by the non-AP MLD or the AP MLD, and since the serving AP MLD and the target AP MLD are connected via backhaul, they can share the information contained in the roaming request / response frames with each other.

[0298] FIG. 22 illustrates a first example of operations performed by an AP MLD / non-AP MLD in a basic continuous roaming procedure. FIG. 22 illustrates an example where a non-AP MLD transmits a roaming request frame and a roaming response frame.

[0299] The transmission and reception process of the AP MLD in Fig. 22 is as follows.

[0300] The AP MLD can receive a roaming request frame from the non-AP MLD. When a link is established between the target AP MLD and the non-AP MLD, the AP MLD can receive a roaming response frame from the non-AP MLD.

[0301] The transmission and reception process of the non-AP MLD in Fig. 22 is as follows.

[0302] A non-AP MLD can send a roaming request frame to an AP MLD. When a link is established between the target AP MLD and the non-AP MLD, the non-AP MLD can send a roaming response frame to the AP MLD.

[0303] FIG. 23 illustrates a second example of operations performed by an AP MLD / non-AP MLD in a basic continuous roaming procedure. FIG. 23 illustrates an example where the AP MLD transmits a roaming request frame and the non-AP MLD transmits a roaming response frame.

[0304] The transmission and reception process of the AP MLD in Fig. 23 is as follows.

[0305] The AP MLD can send a roaming request frame to the non-AP MLD. When a link is established between the target AP MLD and the non-AP MLD, the AP MLD can receive a roaming response frame from the non-AP MLD.

[0306] The transmission and reception process of the non-AP MLD in Fig. 23 is as follows.

[0307] A non-AP MLD can receive a roaming request frame from an AP MLD. When a link is established between the target AP MLD and the non-AP MLD, the non-AP MLD can send a roaming response frame to the AP MLD.

[0308] FIG. 24 illustrates a third example of operations performed by an AP MLD / non-AP MLD in a basic continuous roaming procedure. FIG. 24 illustrates an example where a non-AP MLD transmits a roaming request frame and an AP MLD transmits a roaming response frame.

[0309] The transmission and reception process of the AP MLD in Fig. 24 is as follows.

[0310] The AP MLD can receive a roaming request frame from the non-AP MLD. When a link is established between the target AP MLD and the non-AP MLD, the AP MLD can send a roaming response frame to the non-AP MLD.

[0311] The transmission and reception process of the non-AP MLD in Fig. 24 is as follows.

[0312] A non-AP MLD can send a roaming request frame to an AP MLD. When a link is established between the target AP MLD and the non-AP MLD, the non-AP MLD can receive a roaming response frame from the AP MLD.

[0313] FIG. 25 illustrates a fourth example of operations performed by an AP MLD / non-AP MLD in a basic continuous roaming procedure. FIG. 25 illustrates an example where an AP MLD transmits a roaming request frame and a roaming response frame.

[0314] The transmission and reception process of the AP MLD in Fig. 25 is as follows.

[0315] The AP MLD can send a roaming request frame to the non-AP MLD. When a link is established between the target AP MLD and the non-AP MLD, the AP MLD can send a roaming response frame to the non-AP MLD.

[0316] The transmission and reception process of the non-AP MLD in Fig. 25 is as follows.

[0317] A non-AP MLD can receive a roaming request frame from an AP MLD. When a link is established between the target AP MLD and the non-AP MLD, the non-AP MLD can receive a roaming response frame from the AP MLD.

[0318] The roaming request / response frame format is described below.

[0319] (1) MLD roaming request frame format

[0320] An MLD roaming request frame may include information such as that shown in below:

[0321] Order Information 1 Category 2 UHR Action or Protected UHR Action 3 Dialog Token 4 Reconfiguration Multi-Link element 5 Context transfer level 6 Data transfer enabled

[0322] Order 1: Basically, categories may be included in the new UHR Action or Protected UHR Action, but are not limited thereto. Order 4: For information required for MLD roaming requests, the reset multi-link IE defined in the existing 802.11be may be utilized.

[0323] Order 5: When making an MLD roaming request, the extent to which context transfer is required or possible can be indicated by setting the bit value of the context transfer level.

[0324] Order 6: This field can indicate whether data transfer between AP MLDs is supported.

[0325] The common information fields and link information fields for the reset multi-link IE are as follows:

[0326] 1) Common Information Fields

[0327] FIG. 26 shows an example of a common information field of a reset multi-link IE according to an embodiment of the present disclosure.

[0328] If one or more STAs simultaneously perform MLD roaming from the perspective of STAs, particularly non-AP MLD, while moving to a new AP, MLD capabilities, behaviors, or EML capabilities may change, so this information can be additionally included in the common information field. As before, the existence of subfields in the common information field can be determined from the Presence bitmap.

[0329] 2) Link Information Field

[0330] When one or more STAs perform MLD roaming simultaneously, one or more Per-STA profile subelements may be required.

[0331] FIG. 27 shows an example of a link information field of a reset multi-link IE according to an embodiment of the present disclosure.

[0332] Basically, when moving to a different AP, since information regarding whether each link is STR (Simultaneous transmission and receive) or NSTR (non-STR) may change from the perspective of Non-AP MLD, an NSTR indication bitmap may be included in the STA information field. Similarly, as before, the existence of subfields of STA information can be determined by the Present subfields of the STA control field.

[0333] The link ID can indicate the link ID corresponding to N_AP.

[0334] The Complete Profile, as before, refers to the STA's Complete information—that is, all information included when a connection request frame is transmitted. However, since this involves the movement of an existing STA rather than a new one, the STA's capabilities or operational parameters may not change. Because the AP MLD is aware of this, it can be used as an instruction to include only the changed information instead of the Complete Profile. For example, if the Complete Profile = 0 (as in the existing Partial Profile), the STA Profile includes only the information that will change (i.e., fields / IE) when moving to N_AP. Alternatively, if the Complete Profile is designated as the Changed Profile and this value is 1, the STA Profile includes only the information that will change (i.e., fields / IE) when moving to N_AP.

[0335] The MLD roaming timer refers to the time when MLD roaming is complete, meaning it no longer operates with O_AP and operates with N_AP. In other words, it represents the remaining time until the expected time of switching to the roaming AP. This is related to the TIM field described later. If the MLD roaming timer is applied commonly to all APs, it can be included in the common information field, unlike in FIG. 27. In this case, the presence or absence of the MLD roaming timer within the common information field can be indicated through the Presence bitmap. Since this is information transmitted by the STA, it may be interpreted as a reference by the AP MLD.

[0336] The UHR AP MLD ID (or, Group ID), AP MLD ID, Collocation ID, and / or UHR MLD MAC address (or, MAC address for the roaming group) may be included in the reset multi-link IE as follows, in addition to the information described above. 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 (or, Group ID) is the ID of the UHR AP MLD (or, Roaming Group) to which the AP MLDs to which the non-AP MLD (or, STA) will roam belong belong. In situations where the AP MLD identifies the UHR AP MLD ID (or, Group ID) in advance through the beacon or probe request / response process and sends a roaming request only to APs / AP MLDs associated with the same UHR AP MLD (or belonging to the same roaming group), the UHR AP MLD ID (or, Group ID) field may not exist in the reset multi-link element. Such cases are described in more detail below. That is, describe the format depending on whether to always include the UHR AP MLD ID (or, group ID), AP MLD ID, Collocation ID, and / or UHR MLD MAC address (or, MAC address for the roaming group) in the reset multi-link IE.

[0337] Case 1-1) When included in common information fields

[0338] FIG. 28 illustrates an example in which a common information field of a reset multi-link IE includes a UHR MLD MAC address, a UHR AP MLD ID, and an AP MLD ID according to an embodiment of the present disclosure.

[0339] The Presence bitmap may indicate whether to include at least one of the following: a UHR MLD MAC address (or, MAC address for the roaming group), a UHR AP MLD ID, an AP MLD ID, a Collocation ID, a roaming offer list (i.e., a list of APs for which roaming is proposed / a list of links for which link modification for roaming is proposed), or a roaming cause code. If included only in the common information field, roaming requests may be made only to APs with the same UHR AP MLD ID (or, group ID), AP MLD ID, Collocation ID, and / or UHR MLD MAC address (or, MAC address for the roaming group). That is, requests cannot be made for multiple AP MLD IDs, multiple Collocation IDs, or multiple UHR MLD MAC addresses (or, MAC addresses for the roaming group), even within the same UHR AP MLD (or, roaming group). For example, a reset request cannot be made to an AP belonging to a different AP MLD than the AP currently in the AP MLD. However, in cases where roaming within the same AP MLD is common, overhead can be reduced compared to including each link information field as shown below.

[0340] Case 1-2) When included in common information fields

[0341] FIG. 29 illustrates an example in which a UHR MLD MAC address and an AP MLD ID are included in the common information field of a reset multi-link ID according to an embodiment of the present disclosure.

[0342] If the STA and AP confirm and recognize through the previous connection process that the UHR AP MLD (or roaming group) to which N_AP and O_AP are linked is the same, there is no need to transmit the UHR AP MLD ID (or group ID), so overhead can be reduced without adding a separate UHR AP MLD ID (or group ID) field as shown in FIG. 29.

[0343] Case 2-1) When included in the link information field - When always present

[0344] FIG. 30 illustrates an example in which a UHR MLD MAC address, a UHR AP MLD ID, and an AP MLD ID are included in the link information field of a reset multi-link IE according to an embodiment of the present disclosure.

[0345] The link information field can include multiple Per-STA profile sub-elements, each capable of directing a roaming request to a specific AP via its link ID. The AP MLD ID and UHR AP MLD ID (or group ID) in the STA control field of the Per-STA profile sub-element allow the STA to identify the AP it intends to roam to. While this enables roaming requests to multiple APs corresponding to different AP MLD IDs, the overhead is greater when making requests for the same AP MLD ID compared to the method indicated in the common information field.

[0346] Case 2-2) When included in the link information field - When always present

[0347] FIG. 31 shows an example in which an AP MLD ID is included in the link information field of a reset multi-link IE according to an embodiment of the present disclosure.

[0348] If the STA and AP confirm and recognize through the previous connection process that the UHR AP MLD (or roaming group) to which N_AP and O_AP are linked is the same, there is no need to transmit the UHR AP MLD ID (or group ID), so overhead can be reduced without adding a separate UHR AP MLD ID (or group ID) field as shown in Fig. 31.

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

[0350] FIG. 32 shows another example in which the UHR AP MLD ID and the AP MLD ID are included in the link information field of a reset multi-link IE according to an embodiment of the present disclosure.

[0351] The inclusion of the AP MLD ID for the AP corresponding to the link ID can be indicated through the UHR AP MLD ID (or Group ID) Present and AP MLD ID Present fields of the STA control field of the Per-STA profile sub-element. The UHR AP MLD ID and AP MLD ID can be included in the STA information field or the STA profile field. Similarly, this allows for requesting information for multiple APs corresponding to multiple AP MLD IDs. In particular, when combined with the aforementioned indication method in the common information field, overhead can be reduced compared to the indication method in the link information field by omitting the AP MLD ID when requesting roaming for APs corresponding to the same AP MLD ID.

[0352] Meanwhile, if the UHR AP MLD ID (or, Group ID) and AP MLD ID are indicated in the common information in another way, the UHR AP MLD ID (or, Group ID) and AP MLD ID may not be included, implicitly recognizing that this is a roaming request for APs corresponding to the same UHR AP MLD ID (or, Group ID) and / or AP MLD ID. That is, the UHR AP MLD ID (or, Group ID) Present field and the AP MLD ID Present field may not be included.

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

[0354] FIG. 33 shows another example in which an AP MLD ID is included in the link information field of a reset multi-link IE according to an embodiment of the present disclosure.

[0355] If the STA and AP confirm and recognize through the previous connection process that the UHR AP MLD (or roaming group) to which N_AP and O_AP are linked is 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 (or group ID) field as shown in Fig. 35.

[0356] Referring to FIG. 35, the UHR MLD MAC address (or, MAC address for the roaming group) may be included in the STA information field of the Per-STA profile sub-element. The STA control field of the STA profile sub-element may further include a sub-field (e.g., UHR MAC address Present) indicating whether the MAC address for the roaming group is included in the STA information field.

[0357] In addition, since the present disclosure includes a function to temporarily add and delete links for MLD roaming, a method to instruct this is required, and the following method may be used.

[0358] Basically, 2 bits or more can be used to indicate the (link) type, and it can be Type 0: Add / Type 1: Delete / Type 2: Temporary Add / Type 3: Temporary Delete. Temporary Delete may be substituted for Type 1. Add refers to a request by a STA in a non-AP MLD to establish an additional link connection with an AP in an AP MLD. Delete refers to disconnecting (removing) a currently connected link. Temporary Add refers to a request by a STA in a non-AP MLD to establish multiple links with an additional AP other than the currently connected AP.

[0359] A separate field may be configured within the Type field to indicate something “temporary.” For example, the Type field may indicate a link addition / modification, and a Temporary field may be configured to indicate something temporary. A temporary addition can be configured using the values ​​of both fields (e.g., the first field = Add, the second field = 1 (Temporary)).

[0360] When requesting simultaneous deletion and addition during MLD roaming, you can set the (link) type of the common information field to 4 or 5. Here, Type 4 allows you to instruct add then delete, and Type 5 allows you to instruct delete then add. In the case of Type 4, you can add the links corresponding to the add condition first, and then delete the links corresponding to the delete condition. Conversely, in the case of Type 5, you can delete the links corresponding to the delete condition first, and then add the links corresponding to the add condition.

[0361] Type 6 can instruct a Link Switch. Unlike addition and deletion, a Link Switch means switching a link to another link at once.

[0362] The Add / Delete Link ID list field is an optional field that can be included when the Type field is set to 4 or 5. The link IDs in this Add / Delete Link ID list may include a list of link IDs of links requesting both addition and deletion simultaneously. For the link information (field) with a link ID included in the Add / Delete Link ID list, if the Type field indicates addition, it can be identified as the link being added among the links requesting both addition and deletion simultaneously, and if it indicates deletion, it can be identified as the link being deleted.

[0363] If the type value of the common information field is 6, the add / delete link ID list may not exist.

[0364] The value of the Type field in the Link Information field is required not only for simple addition or deletion but also for requests for simultaneous addition and deletion. The Type value of the Link Information field can be configured as follows, but the values ​​and settings of the Type field are not limited to the mentioned values:

[0365] - Type 0: Add

[0366] - Type 1: Delete

[0367] - Type 2: Temporary addition

[0368] - Type 3: Temporary deletion

[0369] - Type 4: Add and delete (add)

[0370] - Type 5: Add and delete (delete)

[0371] - Type 6: Delete and Add (Add)

[0372] - Type 7: Delete and Add (Delete)

[0373] - Type 8: Link Switching

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

[0375] Type 6 is the case of a link being added in the action of deleting and adding links, and Type 7 is the case of a link being deleted.

[0376] The fields related to adding / deleting / switching links as described above may be included as follows, and at least one additional field may be included:

[0377] In some implementations, fields related to adding / deleting / switching links may be included in the MLD roaming request frame body or in the common information fields of the reset IE.

[0378] FIG. 34 illustrates an example in which fields related to adding / deleting / switching links are included in the common information fields of a reset ML IE according to an embodiment of the present disclosure.

[0379] In this case, only one action can be instructed for all APs. That is, when instructing an addition, only a request to add a link can be made for the APs indicated by the link information field.

[0380] In some implementations, fields related to adding / deleting / switching links may be included in the MLD roaming request frame body or in the link information fields of the reset IE.

[0381] FIG. 35 illustrates an example in which fields related to adding / deleting / switching links are included in the link information field of a reset ML IE according to an embodiment of the present disclosure.

[0382] In this case, different actions can be requested for each AP. For example, a temporary addition can be requested for one AP, and a deletion for another.

[0383] FIG. 36 illustrates another example in which fields related to adding / deleting / switching links are included in the link information fields of a reset ML IE according to an embodiment of the present disclosure.

[0384] Referring to Fig. 36, for a link information field where the UHR AP MLD ID (or group ID) field is omitted, the type field is included in the link information field.

[0385] In some implementations, the addition and deletion of links can be requested together. For example, a new link may be added first, and then an existing link may be deleted. The request method in this case is as follows:

[0386] - When the common information field includes both the type field and the add / delete link ID list field

[0387] Set the type of the Common Information field to 4, and add the link IDs of newly added links and links to be deleted to the Add / Delete Link ID list. At this time, the link ID of the added link can be listed before the link ID of the deleted link in the order of the list. For example, if the link ID of the added link is 5 and the link ID of the deleted link is 2, the Add / Delete Link ID list can be set as 5, 2. While determining the order in this way allows one to identify which links are to be added and which are to be deleted from the Common Information field, this can also be determined through the Type field of the Link Information field, so the action of setting the order may not be necessary.

[0388] Since the type field of the link information field already indicates whether the frame requests addition or deletion individually or simultaneously through the common information field, it is possible to indicate whether the link is being added or deleted using only types 0 and 1. Alternatively, if the link IDs in the add / delete link ID list in the common information are ordered sequentially, overhead can be reduced by omitting the type field in the link information field.

[0389] - When the common information field contains only the type field

[0390] You can set the type field of the common information field to 4 and use type 0 or 1 in the link information field to indicate whether it is a link to be added or deleted.

[0391] - If the common information field does not include both the type field and the add / delete link ID list field

[0392] In this case, you can request to add or delete using a Type field value of 4 or 5 in the Link Information field. At this time, the link being added is set to Type 4, and Type 5 can be set for the link being deleted. Add the link set to Type 4 first, and then delete the link set to Type 5.

[0393] In some implementations, when the addition and deletion of links are requested together, the existing link can be deleted first and the new link added. The request method in this case is as follows:

[0394] - When the common information field includes both the type field and the add / delete link ID list field

[0395] Set the type of the Common Information field to 5, and add the link IDs of newly added links and links to be deleted to the Add / Delete Link ID list. At this time, the link ID of the deleted link can be listed before the link ID of the added link in the order of the list. For example, if the link ID of the deleted link is 5 and the link ID of the added link is 2, the Add / Delete Link ID list can be set as 5, 2. While determining the order in this way allows one to identify which links are to be added and which are to be deleted from the Common Information field, this can also be determined through the Type field of the Link Information field, so the action of setting the order may not be necessary.

[0396] - When the common information field contains only the type field

[0397] You can set the type of the common information field to 5 and use types 0 and 1 in the link information field to indicate whether it is a link to be added or deleted.

[0398] - If the common information field does not include both the type field and the add / delete link ID list field

[0399] In this case, you can request deletion after adding by using a value of 6 or 7 for the Type field of the Link Information field. At this time, the link being added is set to Type 6, and Type 7 is set to the link being deleted. Add the link set to Type 6 first, and then delete the link set to Type 7.

[0400] In some implementations, a type field can be used to instruct a link switch. When changing a link, if the link change is instructed using Type 6 of the common information field instead of instructing the addition or deletion of a link, the link can be switched from the link transmitting the MLD roaming request frame to the link corresponding to the link ID in the link information field. In the case of a link switch, overhead can be reduced by omitting the type field in the link information field. When performing a link switch, the AP and the STA must know by when the link switch must be completed. This can be determined by the AP and communicated to the STA, or determined by the STA and communicated to the AP. If the AP communicates to the STA, a Channel Switch Count field can be added and indicated in the MLD roaming response frame, as shown in Figure 38 or Figure 39 below. If the STA determines and communicates to the AP, the Delete Timer field in the reset ML IE can be used to communicate via the MLD roaming request frame.

[0401] In various embodiments, the channel switch count indicates / counts the period during which operation (e.g., DL forwarding) is allowed with the AP MLDs connected while the previous link is added, and when the period expires, the existing link is deleted and the non-AP MLD can operate with the roaming AP MLDs based on the newly added link. That is, the channel switch count may indicate / count the time until the non-AP MLD switches to a completely new link. The value may indicate the number of TBTTs and / or the actual time taken in units of X (e.g., us).

[0402] Through the Channel Switch Count field, the AP can inform the STA by when to perform the link switch to the new link. If the time required for each link to complete the switch differs, the Channel Switch Count field can be added to the Link Information field to individually indicate when the switch must be completed for each link. If a link switch is requested for only one link in an MLD roaming request, the Channel Switch Count field can be included in the Common Information field or the Link Information field. The Channel Switch Count indicates by what point the link switch is performed based on a specified count or time when switching from an old AP (O_AP, or current AP) to a new AP (N_AP, or target AP), and when the channels of the two links differ, making it impossible to exchange information such as when the switch to the other link occurred.

[0403] Figure 37 shows an example where the AP removal timer is included in the common information field of the reset ML IE.

[0404] Referring to Fig. 37, when the completion time of a link switch is indicated using the remove timer field of the reset ML IE, if all links that requested a link switch through the MLD roaming request frame have the same remove timer value, the AP remove timer (or remove timer) field may be added to a common information field rather than a link information field to reduce overhead. In this case, the AP remove timer (or remove timer) field may not be used based on the AP remove timer present (or remove timer present) field included in the link information field or the present bitmap subfield of the reset ML IE.

[0405] If the removal timer values ​​of the links for which link switching is requested are different, an AP removal timer (or, removal timer) field may be added to the link information field rather than the common information field. If there is only one link to be switched, an AP removal timer (or, removal timer) field may be added to the common information field, or an AP removal timer (or, removal timer) field may be added to the user information field / link information field.

[0406] (2) MLD roaming response frame format

[0407] In MLD roaming response frames, since links must be changed while maintaining multiple link settings, it is necessary to consider link-level parameters that must be provided.

[0408] An MLD roaming request frame may include information such as that shown in below:

[0409] Order Information 1 Category 2 UHR Action or Protected UHR Action 3 Dialog Token 4 Status Code 5 Basic Multi-Link element 6 Group Key Information 7 AID 8 Channel Switching Broadcast element (Optional) 9 Extended Channel Switching Broadcast element (Optional) 10 TID-to-link Mapping element (Optional) 11 Context Transfer Level 12 Context Transfer Contents Feedback 13 Queued Packets

[0410] Order 1: By default, categories can be included in new UHR Actions or Protected UHR Actions, but are not limited to these. Order 4: Status codes can utilize existing status code fields.

[0411] - When responding to an MLD roaming request, the basic multi-link IE defined in the existing 802.11be can be utilized for the necessary information regarding AP MLD and N_AP.

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

[0413] 1) Common Information Fields

[0414] Figure 38 shows an example of the common information field structure of the basic ML IE.

[0415] Referring to FIG. 38, the common information is common information corresponding to N_APs in which one or more STAs perform MLD roaming. The UHR MLD MAC address (or, MAC address for the roaming group) may be included in the common information field in the basic ML IE.

[0416] When transmitting a beacon or ML probe response frame, if the basic ML IE is included, the channel switch count field may not be included by using the channel switch count Present field.

[0417] In the resetting ML IE of the MLD roaming request frame, if the Type field of the Common Information field is set to Type 6, or if the Type field of the User Information field / Link Information field is set to Type 8, the Common Information field of the default ML IE may include a Channel Switch Count field. If the Common Information field includes a Channel Switch Count field, and if one or more link(s) simultaneously requesting a link switch in a single MLD roaming request have the same time to complete the switch to the new link(s), the Channel Switch Count field of the Common Information field can be used to inform the AP / STA by when the link switch will be performed. The Link Switch Count / Channel 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. Through the Channel Switch Count field, the AP can inform the STA by when the link switch to the new link will be performed.

[0418] 2) Link Information Field

[0419] When one or more STAs perform MLD roaming simultaneously, one or more Per-STA profile sub-elements (profile sub-elements) may be required for the corresponding APs.

[0420] A link information field reflecting information that changes to the STA control field, STA information field, and STA profile field of the existing basic multi-link element IE is exemplified in FIG. 39.

[0421] Figure 39 shows an example of the link information field structure of the basic ML IE.

[0422] Referring to Fig. 39:

[0423] - Basically, the link ID in the STA information field indicates the link ID corresponding to N_AP.

[0424] - The Complete profile refers to the AP's Complete information, that is, all information included when a connection response frame is transmitted, as before. However, since the AP's capabilities or operational parameters may not change because the STA performs MLD roaming, the Complete profile is set to 0 in this case.

[0425] - Additionally, it includes information regarding the MLD roaming timer. To this end, the STA control field includes the MLD roaming timer Present field, and the STA information field includes the MLD roaming timer field. This refers to the time when MLD roaming is complete, meaning it no longer operates with O_AP and operates with N_AP. This may utilize the MLD roaming timer information transmitted by the STA, or it may not be included if the STA has transmitted it and the response status code is SUCCESS.

[0426] When a basic ML IE is included in a connection request / response frame, roaming-related information is not required, so the basic ML IE can be configured without adding the UHR MLD MAC address (or MAC address for the roaming group), UHR AP MLD ID (or group ID), and / or Collocation ID shown in FIG. 38 using the Presence field.

[0427] If the time required for each link to complete the link switch varies, a channel switch count field can be added to the link information field to indicate individually when each link must complete the link switch. If a link switch is requested for only one link via an MLD roaming request, the channel switch count field can be included in the common information field or the link information field.

[0428] - The UHR AP MLD ID (or Group ID) and AP MLD ID may be included in addition to the above information 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 (or Group ID) is the ID of the UHR AP MLD (or Roaming Group) to which the AP MLDs to which the APs to which the non-AP MLD (or STA) will roam belong belong. If the UHR AP MLD ID (or Group ID) is not included in the MLD roaming request frame, it is known that they are linked to / included in the same UHR AP MLD (or Roaming Group), so the UHR AP MLD ID (or Group ID) field may be omitted. Detailed cases regarding this are as follows:

[0429] Case 1-1) When included in common information fields

[0430] This can be utilized when the above-described multi-link (ML) IE is requested as a method corresponding to case 1-1).

[0431] Similarly, the Presence bitmap indicates whether to include the UHR AP MLD ID (or, Group ID) and the AP MLD ID, and accordingly, the UHR AP MLD ID (or, Group ID) and the AP MLD ID are included in the common information field. This can provide information only for APs of AP MLDs where UHR AP MLD ID (or, Group ID) = 0 and Collocation ID ≠ 0.

[0432] Case 1-2) When included in common information fields

[0433] This can be utilized when the above-described reset ML IE is requested as a method corresponding to case 1-2).

[0434] Similarly, the Presence bitmap indicates whether the AP MLD ID is included, and accordingly, the AP MLD ID is included in the common information field.

[0435] Case 2-1) When included in the link information field - When always present

[0436] This can be utilized when the above-described reset ML IE is requested as a method corresponding to case 2-1).

[0437] Include the UHR AP MLD ID (or Group ID) and AP MLD ID for the AP corresponding to the Link ID of each Per-STA profile sub-element in the STA control field. This can provide information for multiple APs corresponding to multiple AP MLD IDs, but the overhead is greater than the method of indicating it in the common information field when providing information for the same AP MLD ID.

[0438] Case 2-2) When included in the link information field - When always present

[0439] This can be utilized when the above-described reset ML IE is requested as a method corresponding to case 2-2).

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

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

[0442] This can be utilized when the above-described reset ML IE is requested as a method corresponding to case 3-1).

[0443] The inclusion of the AP MLD ID for the AP corresponding to the link ID can be indicated through UHR AP MLD ID (or, Group ID) Present and AP MLD ID Present in the STA control field of the Per-STA profile sub-element. The UHR AP MLD ID (or, Group ID) and AP MLD ID can be included in the STA information field or the STA profile field. Likewise, this can provide information for multiple APs corresponding to multiple AP MLD IDs. In particular, when combined with the indication method in the common information field, overhead can be reduced compared to the method of including them in the link information field by not including the UHR AP MLD ID (or, Group ID) and AP MLD ID when providing information only for APs corresponding to the same AP MLD ID.

[0444] Meanwhile, regarding the AP MLD ID setting described above, in the case of setting a unique ID within the collocation set of an AP MLD, if the AP MLD ID is 0, the AP MLD ID may be omitted. That is, if the AP MLD ID does not exist, the AP receiving the request can implicitly recognize that it is a request for information from other APs regarding the AP MLD to which it belongs.

[0445] Meanwhile, if the UHR AP MLD ID and / or AP MLD ID is indicated in the common information field as another method, it is implicitly recognized that this is information about APs corresponding to the same AP MLD ID, and thus the UHR AP MLD ID (or, Group ID) and / or AP MLD ID may not be included. That is, the UHR AP MLD ID (or, Group ID) Present and AP MLD ID Present fields may not be included.

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

[0447] This can be utilized when the above-described reset ML IE is requested as a method corresponding to case 3-2).

[0448] The inclusion of the AP MLD ID for the AP corresponding to the link ID can be indicated through the AP MLD ID Present in the STA control field of the Per-STA profile sub-element. The AP MLD ID can be included in the STA information field or the STA profile field. Likewise, this can provide information for multiple APs corresponding to multiple AP MLD IDs. In particular, when combined with the indication method in the common information field, overhead can be reduced compared to the method of including it in the link information field by not including the AP MLD ID when providing information only for APs corresponding to the same AP MLD ID.

[0449] Meanwhile, regarding the AP MLD ID setting described above, in the case of setting a unique ID within the collocation set of an AP MLD, 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 receiving the request can implicitly recognize that it is a request for information from other APs regarding the AP MLD to which it belongs.

[0450] On the other hand, if a Collocation ID is indicated in the common information field as another method, it is implicitly recognized that this refers to information about APs belonging to the same collocation set, so the AP MLD ID and Collocation ID may not be included. In other words, the AP MLD ID Present field may not be included.

[0451] Order 6: Group key information. Basically, since the group key is different for each link, it is necessary to provide group key information for N_APs.

[0452] Figure 40 shows an example of a group key information field.

[0453] Referring to FIG. 40, the Length field indicates the length of the group key information. The group key information for each N_AP includes MLO GTK KDE, MLO IGTK KDE, and MLO BIGTK KDE formats containing the link ID of each N_AP as defined in 802.11be.

[0454] Order 7: Since the total AID (Association Identifier) ​​space is limited, each AP MLD can manage AIDs. This means that an AID can be assigned when roaming to a different AP MLD. However, an AID may not be included in the following cases:

[0455] - In the case of roaming to a different AP MLD and being assigned the same AID

[0456] - When the entire AID space is managed by the UHR AP MLD (or roaming group) as before

[0457] Orders 8 and 9: If included, the channels of each roaming AP are identical but differ from the channels of previously connected APs. However, in the following cases, Orders 8 and 9 may be included or excluded differently:

[0458] - Assuming that all APs enabling MLD roaming are always on the same channel, these IEs are not included.

[0459] - The channel of a roaming AP may be the same as or different from the channel of the previously connected AP. In this case, the Channel Switching Broadcast IE or the Extended Channel Switching Broadcast IE may each be included in the link information of the Basic Multi-Link IE in Order 5. This is to perform channel switching for each roaming AP.

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

[0461] In addition, MLD roaming timers can be added to both the MLD roaming request and response frames.

[0462] Additionally, the AP MLD can include the MLD roaming timer of the above-mentioned reset ML IE. Since the AP MLD can control current roaming, it can similarly specify a set MLD roaming timer. For example, if the STA has not included an MLD roaming timer or if it is inappropriate, the AP MLD can set and notify it. Furthermore, if the STA has not transmitted an MLD roaming timer, the AP MLD can set and notify it. The meaning of the MLD roaming timer is the same. That is, it refers to the time when MLD roaming is complete, meaning that it no longer operates with O_AP and operates with N_AP.

[0463] When a temporary add request is received, after the MLD roaming timer expires, the STA completely disconnects from O_AP (i.e., temporary deletion or deletion) and allows it to connect with N_AP.

[0464] If the MLD roaming timer is applied commonly to all APs, it can be included in the common information field. In this case, the presence bitmap can be used to indicate whether the MLD roaming timer exists in the common information field.

[0465] - Additionally, information regarding the MLD roaming timer may be included in the MLD roaming response frame. To this end, the STA control field includes an MLD roaming timer Present field, and the STA information field includes an MLD roaming timer field. This may represent the time remaining until the STA can receive data from the AP to which it is roaming. This may also utilize the MLD roaming timer information transmitted by the STA. This is basically related to the TIM field described above.

[0466] If the MLD roaming timer is applied commonly to all APs, it can be included in the common information field. In this case, the presence or absence of the common information field can be indicated through the Presence bitmap. Alternatively, it can be included in the body of the MLD roaming probe request frame.

[0467] Order 11: When transmitting an MLD roaming response, the degree to which context passing is required can be indicated by setting the bit value of the context passing level.

[0468] Order 12: Context passing is complete and the content actually transmitted through context passing is reported. At this time, the context passing level can be used.

[0469] Bitmap and / or indexing methods may be used to provide the relevant information.

[0470] - Bitmap method: Each context delivery level is indicated by a 0 or 1 bit; if the context corresponding to that level has actually been transmitted, it is set to 1, and if it has not been transmitted, it is set to 0. Based on the context actually transmitted, the STA can determine the targets to re-negotiate and / or establish after roaming. Alternatively, the presence or absence of a bit corresponding to the context delivery level can be indicated without using 0s and 1s. For example, if “Bit 1: BA consensus” and that bit does not exist, it can indicate that the context related to the BA consensus has not been transmitted.

[0471] - Indexing method:

[0472] a. Accumulation method: Accumulated in the order of context delivery levels, so that if bit 2 is indicated, it indicates that all contexts associated with bits 0, 1, and 2 have been transmitted.

[0473] b. Grouping method: Specific bits can be indicated by grouping bits. For example, bit 3 may be associated with a group including BA consensus and SN / PN, and bit 4 may be associated with a group including SN / PN and packet reordering. In this case, if the field indicating context delivery in the roaming response is set to bit 3, it may indicate that context related to SN / PN and BA consensus has been delivered. Grouping can be varied in many ways and is not limited to this example.

[0474] As shown above, you can indicate the presence or absence of items for which context has been passed, or you can indicate only the items for which context has been passed and / or the items for which context has not been passed.

[0475] Order 13: When roaming, the non-AP STA can use this field to indicate whether there are packets in the queue of the AP MLD (e.g., the current AP MLD) receiving the roaming response frame. For example, if Queued Packets is set to 1 (or 0), it may indicate that there are packets remaining in the queue. If Queued Packets is set to 0 (or 1), it may indicate that there are no packets remaining in the queue.

[0476] When roaming, the non-AP STA can read the corresponding field and determine whether to switch to the new roaming target AP MLD. When the non-AP MLD receives a roaming response and reads the corresponding field, if the field is set to 1, it can identify when and how to receive DL data from the serving AP MLD before roaming to the target AP MLD based on the information described below. Conversely, if the field is set to 0, the non-AP MLD can receive the roaming response and immediately start DL / UL transmission with the target AP MLD.

[0477] If Queued Packets is set to 1, additional information may be signaled. For example, the following information may be signaled:

[0478] -DL data size: Actual amount of DL data;

[0479] - Number of pending MSDUs: Number of MSDUs that have not yet been transmitted;

[0480] - SN and / or PN related information (e.g., Last SN / PN among MSDUs or Range); and / or

[0481] - TIDs for pending MSDUs: TIDs can be indicated as bitmaps or values.

[0482] AP MLD can provide at least one of the above information.

[0483] Figure 41 shows a first example of a procedure for transmitting DL data in the queue of a serving AP MLD.

[0484] Referring to FIG. 41, if Queued Packets is set to 1 and / or related information is provided, the serving AP MLD can transmit DL data remaining in the serving AP MLD's queue after the transmission of a roaming response frame. The serving AP MLD (or, non-AP MLD STA) can measure the amount of DL data based on the size of the DL data and / or the number of pending MSDUs, identify where the end of the DL data transmission is, and / or indicate where the last DL data is by using information from the Last SN / PN or the last DL data bit of the last DL data.

[0485] The operation when packets remain in the queue of the serving AP MLD and a link is established with the target AP MLD before transmitting the data in the serving AP MLD's queue is as follows: When a roaming response is received and DL data packets remain in the queue of the serving AP MLD, the serving AP MLD can transmit DL data to the non-AP MLD STA. DL data can be transmitted while the pending DL transmission timer is running, and when the timer expires, data transmission from the serving AP MLD is terminated and the non-AP MLD STA can perform UL / DL data transmission and reception with the target AP MLD. If DL data transmission is completed before the timer expires, the non-AP MLD STA can immediately switch to the target AP MLD.

[0486] Figure 42 shows an example of a procedure that notifies the completion of transmission of DL data in the queue of the serving AP MLD via a DL timer.

[0487] Referring to Fig. 42, the serving AP MLD / non-AP MLD STA can determine when the transmission of DL data is completed by calculating the time required to transmit DL data based on the MSDU DL data size and / or the number of pending MSDUs in advance and setting a DL timer.

[0488] Additionally, if Queued Packets included in the roaming response frame is set to 1 and the non-AP STA does not know at what time the packets in the queue of the serving AP MLD are completed to be transmitted, the serving AP MLD can notify the non-AP MLD of the time to switch to the target AP MLD by retransmitting a roaming response frame with the value of the Queued Packets field set to 0 when all packets in the queue have been transmitted.

[0489] The following describes context transfer.

[0490] Context passing

[0491] (1) Context-transferring frame

[0492] When context delivery is performed Over-the-Air rather than Over-the-DS, a separate frame is required for the serving AP MLD to deliver the context to the target AP MLD. The context delivery frame has the action frame format and may also be referred to by other names.

[0493] The information included in the context passing frame is exemplified in :

[0494] OrderContext1SN / PN2Block Ack Agreement3Stream classification service (SCS)4Target Wake Time (TWT)

[0495] In addition to the contexts exemplified in , other information may be included in the context-transfer frame, and the order of the included information is not limited to the order exemplified in . The context-transfer frame can be transmitted from the serving AP MLD to the target AP MLD when a non-AP MLD STA roams from the serving AP MLD to the target AP MLD.

[0496] Figure 43 shows an example of transmitting a context-transfer frame.

[0497] Referring to FIG. 43, the context delivery frame can be transmitted over-the-air. When a roaming request is transmitted, the serving AP MLD can transmit the context delivery frame to the target AP MLD, and the context delivery frame may include at least one of the information exemplified in .

[0498] (2) Context passing level

[0499] To prevent data discontinuity caused by issues such as packet loss when a Non-AP STA roams to a new AP MLD, context forwarding can be used to pre-transmit necessary information from the previously connected AP MLD to the new AP MLD before the Non-AP STA begins roaming. In this case, the Non-AP STA requests roaming, waits for the time required for context forwarding, and then performs roaming; however, the greater the amount of information transmitted via context forwarding, the greater the delay caused by the context forwarding. In situations where context forwarding is not required, a context forwarding level is defined to transmit only the necessary information in order to avoid delays caused by unnecessary context forwarding. Table 4 shows examples of context information transmitted for each context forwarding level bit value. The bit values ​​and corresponding context information shown in Table 4 are exemplary and are not limited thereto.

[0500] Context Transfer Level Context Transferred 0 No context transfer 1 SN / PN 2 BA consensus 3 Packet reordering 4 - 1 5 Reserved

[0501] For example, if roaming is possible using only entities or UHR MLDs without context passing, the context passing level may be set to 0. If only SN / PN information needs to be passed via context passing, the context passing level may be set to 1. Methods for using context passing levels may include accumulation methods and / or methods for selecting only the necessary levels. The two methods above are exemplary and are not limited thereto. In some implementations, a method in which contexts associated with the value of the context passing level are accumulated may be used. If the context passing level is set to 3, context information with a value of 1 and context information with a value of 2 may be included.

[0502] In some implementations, a method of selecting the required level may be used. According to this, context passing can be performed by selecting only the individually required functions. For example, if only SN / PN exists for context passing, the context passing level can be set to 1, and if SN / PN and packet reordering exist for context passing, the context passing level can be set to 1, 3.

[0503] The following describes data transfer.

[0504] Data transfer

[0505] (1) Data transfer between AP MLDs

[0506] DL data in the queue of the serving AP MLD up to the point when a roaming request is transmitted may be lost if the non-AP MLD STA receives the transmission before switching to the target AP MLD and does not switch. However, if the amount of buffered data is large and / or if channel conditions are poor, making it difficult to finish the transmission before the pending DL data transmission timer expires, the serving AP MLD may transmit some or all of the buffered data to the target AP MLD.

[0507] Figure 44 shows an example of a data transfer procedure.

[0508] Referring to FIG. 44, a non-AP MLD STA transmits a roaming request, and data delivery can be performed. The process of transmitting DL data from the serving AP MLD is not illustrated, and a baseline data delivery procedure is illustrated. Information required in advance for data delivery may be included in the roaming request frame and / or roaming response frame. Data delivery may be performed based on Over-the-DS and / or Over-the-Air.

[0509] In the case where the channels connected between the Non-AP MLD STA, the serving AP MLD, and the target AP MLD are the same, the Non-AP MLD STA can receive data transmitted to the target AP MLD without switching to the target AP MLD, but if the channels are different, the non-AP MLD STA can receive data transmitted according to the data transmission after switching to the target AP MLD.

[0510] Figure 45 illustrates the data transfer procedure when the serving AP MLD performs data transfer while performing DL transfer.

[0511] Referring to FIG. 45, when the serving AP MLD transmits DL data in the buffer to the non-AP MLD STA, it can transfer the remaining data that is not transmitted to the target AP MLD (i.e., perform data transfer). In this case, negotiation on which data to transmit may be required prior to data transfer and the transmission of pending DL data. In some implementations, the serving AP MLD may determine which data to transmit prior to data transfer and the transmission of pending DL data without negotiation. According to one example of negotiation, the serving AP MLD may allocate an amount of data that can be transmitted from the pending DL data as data to transmit before the pending DL data timer expires, and transfer the remaining data to the target AP MLD through data transfer.

[0512] Figure 46 shows a flowchart of the case where the serving AP MLD performs data delivery while performing DL transmission.

[0513] Referring to FIG. 46, if the AP MLD determines that it cannot transmit all the data in the buffer after the roaming request frame and roaming response frame have been transmitted / received until the pending DL data timer expires, the AP MLD can transfer the data that could not be transmitted during that time to the target AP MLD (i.e., data transfer). When the pending DL data timer expires, the AP MLD determines whether there are any packets that could not be transmitted, and if there are no packets that could not be transmitted, transmission and reception between the target AP MLD and the non-AP MLD STA can begin. The non-AP MLD receives data from the serving AP MLD while the pending DL data timer is running, and when the timer expires, it can switch to the target AP MLD.

[0514] Figure 47 illustrates the data delivery procedure when the serving AP MLD performs data delivery after performing DL transmission.

[0515] Referring to FIG. 47, the serving AP MLD can perform data transfer to the target AP MLD after transmitting the data remaining in the buffer. If the serving AP MLD fails to complete the transmission of the waiting DL data before the waiting DL data timer expires, the remaining data can be transferred to the target AP MLD through data transfer. If the last data to be transmitted among the packets in the buffer of the serving AP MLD is not transmitted and the waiting DL data timer becomes 0 (i.e., the waiting DL data timer expires), the serving AP MLD can transfer the remaining data to the target AP MLD through data transfer as shown in FIG. 47.

[0516] The examples of FIGS. 45 and FIGS. 47 can be combined. For example, even if the serving AP MLD performs the pending DL data transmission and data transmission separately according to prior negotiation and / or the decision of the serving AP MLD as in FIG. 45, the transmission of the pending DL data may not be completed until the pending DL data timer expires. In this case, as in FIG. 47, the serving AP MLD may transmit the untransmitted data to the target AP MLD via data delivery after the expiration of the pending DL data timer.

[0517] Figure 48 shows a flowchart of the case where the serving AP MLD performs data delivery after performing DL transmission.

[0518] Referring to FIG. 48, the AP MLD can transmit data in the buffer after the roaming request frame and roaming response frame are transmitted / received until the pending DL data timer expires. If there is untransmitted data when the pending DL data timer expires, the AP MLD can transmit the untransmitted data to the target AP MLD through data transfer. The Non-AP MLD receives data from the serving AP MLD while the pending DL data timer is running, and can switch to the target AP MLD when the timer expires.

[0519] (2) Data delivery of failed transmission

[0520] Transmission failures may occur during the transmission of pending DL data from a serving AP MLD to a non-AP MLD STA. In this case, the serving AP MLD may retransmit the failed packet to the non-AP MLD STA, but if channel conditions are poor and / or there is too much data to retransmit, the serving AP MLD may forward the data to be retransmitted to the target AP MLD (i.e., data forwarding) so that the non-AP MLD receives the retransmission of the failed data / packets from the target AP MLD after roaming to the target AP MLD. However, if the lifetime of the packets to be retransmitted is short and it is expected that the packets will expire after being forwarded to the target AP MLD (i.e., data forwarding) before the target AP MLD transmits them, the serving AP MLD may not forward those packets to the target AP MLD (i.e., data forwarding).

[0521] For the transmission of failed data, for example, the serving AP MLD can transmit / transmit only the failed packets to the target AP MLD. As another example, the serving AP MLD can transmit all data from the time the failure occurred to the target AP MLD. Since the SN value of the packet is transmitted along with the data, the target AP MLD can sort the data transmitted through data transmission and the newly received data from the DS in order of smallest SN value and transmit them to the non-AP MLD.

[0522] When data delivery is performed for packets that need to be retransmitted, as shown in FIG. 47, data delivery can be performed after the waiting DL data transmission is completed.

[0523] FIG. 49 illustrates an example of a method performed in an AP MLD for processing data that has failed to transmit. The AP MLD may be a serving AP MLD and may be referred to as the first AP MLD. The target AP MLD may be referred to as the second AP MLD.

[0524] Referring to FIG. 49, in step S4901, the first AP affiliated with the first AP MLD can receive a request frame (e.g., a roaming request frame) for a continuous transition (or, roaming) from the first AP MLD to the second AP MLD from a STA affiliated with a non-AP MLD.

[0525] In step S4903, the first AP can send a response frame (e.g., a roaming response frame) to the STA for the request frame.

[0526] In step S4905, the first AP can transmit the first data that is queued in the buffer to the STA after the request frame is received.

[0527] In step S4907, based on detecting a transmission failure for the transmission of the first data, the first AP can transmit the first data to the second AP associated with the second AP MLD.

[0528] According to various embodiments, the response frame may include at least one of information about the presence of data waiting in a buffer (e.g., Queued Packets=1), information about the amount of data waiting in a buffer (e.g., DL data size), information about the number of one or more packets related to the data waiting in the buffer (e.g., Number of pending MSDUs), information about the sequence number (SN) or packet number (PN) of one or more packets (e.g., Last SN / PN among MSDUs or Range), or information about the traffic identifier (TID) of one or more packets (e.g., TIDs for pending MSDU).

[0529] According to various embodiments, after a transmission failure for the transmission of the first data is detected, the first AP can transmit the second data waiting after the first data in the buffer to the STA.

[0530] According to various embodiments, when the first AP initiates the transmission of data waiting in the buffer to the STA, the first AP may start a timer (e.g., a waiting DL data / transmission timer). Upon the expiration of the timer, the first AP stops the transmission of data waiting in the buffer to the STA, and the first AP may transfer or discard the data remaining in the buffer to the second AP. While the timer is operating, the first AP may transmit the first data waiting in the buffer to the STA.

[0531] According to various embodiments, the first AP can transmit the first data to the second AP before the expiration of the timer based on detecting a transmission failure for the transmission of the first data.

[0532] According to various embodiments, the value of the timer may be related to the period during which the timer operates. The period during which the timer operates may be determined based on at least one of the size of the data waiting in the buffer (e.g., (MSDU) DL data size) or the number of one or more packets related to the data waiting in the buffer (e.g., Number of pending MSDUs).

[0533] According to various embodiments, the response frame may include information about the value of the timer related to the period during which the timer operates.

[0534] According to various embodiments, the first AP can transmit to the second AP all data waiting in the buffer, including the first data and the second data waiting after the first data in the buffer, based on detecting a transmission failure for the transmission of the first data.

[0535] According to various embodiments, the first AP can transmit all data waiting in the buffer to the second AP, and then transmit information about the absence of data waiting in the buffer (e.g., Queued Packets=0) to the STA.

[0536] According to various embodiments, the first AP can transmit the first data to the second AP based on at least one of the channel state, the amount of the first data, or the lifetime of the first data.

[0537] According to various embodiments, the first AP can transmit information about the sequence number (SN) of one or more packets associated with the first data to the second AP.

[0538] According to various embodiments, the retransmission of the first data may be performed from the second AP to the STA after a successive switching of the STA from the first AP MLD to the second AP MLD has been performed.

[0539] According to various embodiments, the first AP can monitor the reception of an ACK (acknowledgement) for the transmission of the first data from the STA. The first AP can detect a transmission failure for the transmission of the first data based on the fact that an ACK for the transmission of the first data is not received.

[0540] FIG. 50 illustrates an example of signal flow between an AP MLD and a non-AP MLD for processing data in which a transmission failure has occurred. The AP MLD may be a serving AP MLD and may be referred to as the first AP MLD. The target AP MLD may be referred to as the second AP MLD.

[0541] Referring to FIG. 50, in step S5001, the STA associated with the non-AP MLD can transmit a request frame (e.g., a roaming request frame) for continuous switching (or roaming) from the first AP MLD to the second AP MLD to the first AP associated with the first AP MLD.

[0542] In step S5003, the STA can receive a response frame (e.g., a roaming response frame) for a request frame from the first AP.

[0543] In step S5005, the STA can receive transmission of the first data that is queued in the buffer after the request frame is transmitted from the first AP.

[0544] In step S5007, based on detecting a transmission failure for the transmission of the first data, the first AP can transmit the first data to the second AP associated with the second AP MLD.

[0545] According to various embodiments, after a transmission failure occurs for the transmission of the first data, the STA can receive the second data waiting after the first data in the buffer from the first AP.

[0546] According to various embodiments, based on the occurrence of a transmission failure for the transmission of the first data, all data waiting in the buffer, including the first data and the second data waiting after the first data in the buffer, can be transferred from the first AP to the second AP.

[0547] Below, various examples regarding the operation process of APs and STAs performing MLD roaming are explained.

[0548] Figure 51 shows a procedure for checking whether N_AP is roaming enabled using the Collocation Enabled field.

[0549] Referring to Fig. 51, the transmission and reception process of the AP is as follows:

[0550] O_AP sends an RNR IE to the STA via a beacon. When O_AP receives an MLD roaming request frame from the STA, it verifies the link ID, AP MLD ID, and UHR AP MLD ID (or group ID) (optional) of the AP the STA wishes to roam to. O_AP sends the acceptance or rejection of this request and the information described in the roaming response frame format to the STA via an MLD roaming response frame.

[0551] Referring to Fig. 51, the transmission and reception process of the STA is as follows:

[0552] When the STA receives a beacon, it checks for the existence of the MLD roaming parameter field in the TBTT information field. The STA checks for the MLD roaming Enabled, UHR AP MLD ID (or, Group ID), and Collocation Enabled fields within the MLD roaming parameter field. At this time, MLD roaming Enabled is set to 1, UHR AP MLD ID (or, Group ID) to 0, and Collocation Enabled to 0. The STA sends an MLD roaming request frame to O_AP. The STA receives an MLD roaming response frame from O_AP, and if accepted, roams to N_AP.

[0553] Figure 52 illustrates a procedure for determining whether N_AP is roaming possible using a Collocation ID.

[0554] Referring to Fig. 52, the transmission and reception process of the AP is as follows:

[0555] O_AP sends an RNR IE to the STA via a beacon. When O_AP receives an MLD roaming request frame from the STA, it verifies the link ID, AP MLD ID, and UHR AP MLD ID (or group ID) (optional) of the AP the STA wishes to roam to. O_AP sends the acceptance or rejection of this request and the information described in the roaming response frame format to the STA via an MLD roaming response frame.

[0556] Referring to Fig. 52, the transmission and reception process of the STA is as follows:

[0557] When the STA receives a beacon, it checks the TBTT information field for the existence of the MLD roaming parameter field. The STA checks for MLD roaming Enabled, UHR AP MLD ID (or, Group ID), and Collocation IDs within the MLD roaming parameter field. At this time, MLD roaming Enabled is set to 1, UHR AP MLD ID (or, Group ID) to 0, and Collocation ID to 0. The STA sends an MLD roaming request frame to O_AP. The STA receives an MLD roaming response frame from O_AP, and if accepted, roams to N_AP.

[0558] Figure 53 shows an example of a collocated AP set.

[0559] Figure 53 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 the Collocation ID field of the RNR IE. Although AP 4 and AP 5, which are connected to AP MLD 2, exist near the non-AP MLD, the non-AP MLD does not make roaming requests to AP 4 and AP 5 because they are included in the same set of collocated APs as the currently connected AP 2. On the other hand, the non-AP MLD can make roaming requests to AP 6, AP 7, and AP 8, which are included in a different set of collocated APs than AP 2. By defining the set of collocated APs in this way and providing information about APs that are physically close and do not need to roam, unnecessary roaming can be prevented.

[0560] Figure 54 illustrates the MLD roaming procedure when the UHR AP MLD ID is included in the reset element.

[0561] Referring to Fig. 54, the transmission and reception process of the AP is as follows:

[0562] O_AP transmits information about other APs to STA via beacons. Upon receiving an MLD roaming request frame from STA, STA identifies the ID of the AP it wishes to roam to using the link ID and AP MLD ID. Additionally, if the MLD roaming request frame includes the UHR AP MLD ID (or group ID), STA also identifies the UHR AP MLD ID (or group ID). O_AP transmits information regarding acceptance and response information (e.g., information exemplified in ) to STA via an MLD roaming response frame.

[0563] Referring to Fig. 54, the transmission and reception process of the STA is as follows.

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

[0565] Figure 55 shows the MLD roaming procedure when the UHR AP MLD ID is not included in the reset element.

[0566] Referring to Fig. 55, the transmission and reception process of the AP is as follows:

[0567] O_AP transmits information about other APs to STA via beacons. When O_AP receives an MLD roaming request frame from STA, it identifies the ID of the AP it wants to roam to through the link ID and AP MLD ID. O_AP transmits information regarding acceptance and MLD response information (e.g., information exemplified in ) to STA via an MLD roaming response frame.

[0568] Referring to Fig. 55, the transmission and reception process of the STA is as follows:

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

[0570] FIG. 56 shows Example 1 of an MLD roaming procedure. Example 1 corresponds to the case where only some STAs roam to the AP first.

[0571] Referring to Fig. 56, rather than all STAs moving to the AP of another AP MLD at once, only some STAs roam to the AP first. For example, STA 1 roams from AP 1 to AP 3 first, and then STA 2 roams from AP 3 to AP 5.

[0572] In this example, there are 2 STAs in the non-AP MLD, but even if there are 3 STAs, only 2 STAs can roam first and the remaining STAs can roam next.

[0573] In this example, the STA 1 and AP 1 presented above can first exchange MLD roaming requests / responses. In the MLD roaming request, STA 1 will specify the (optional) UHR AP MLD ID (or, group ID), AP MLD ID, and link ID for AP 4, and AP 1 will include the information about AP 4 in the default multilink IE along with an acceptance or rejection. Next, STA 2 and AP 3 also go through the same procedure for AP 5. At this time, the procedure may also be performed on AP 4, to which STA 1 is connected, instead of STA 2.

[0574] This example can be effective for receiving data. AP 2 and STA 3 can exchange data while AP 1 and STA 1 are undergoing the roaming process, and AP 4 and STA 1 can exchange data while AP 3 and STA 2 are undergoing the roaming process. In this case, all TIDs must be mapped to the links exchanging data. However, this example is difficult to apply when there is a STA rather than an MLD or when there is only one STA in an MLD, and relatively high frame switching overhead may occur.

[0575] Figure 57 illustrates the operation process of Example 1 for the MLD roaming procedure.

[0576] Referring to Fig. 57, the transmission and reception process of the AP is as follows:

[0577] AP 1 receives a roaming request frame from STA 1. STA identifies the ID of the AP it wants to roam to through the link ID, AP MLD ID, and UHR AP MLD ID (or, group ID) (optional). AP 1 sends an MLD roaming response frame to STA 1 indicating whether it accepts the request and providing response information regarding APs 4 and 5 (e.g., information exemplified in ).

[0578] Referring to Fig. 57, the transmission and reception process of the STA is as follows:

[0579] STA 1 sends an MLD roaming request frame for AP 4 and 5 to AP 1. When STA 1 receives roaming acceptance from AP 1 by receiving an MLD roaming response frame, it roams to AP 4 based on the received information about AP 4. When STA 1's roaming ends, STA 2 also roams to AP 4 based on the acceptance status for AP 5 received through STA 1 and the information about AP 4 and 5.

[0580] FIG. 58 shows Example 2 of an MLD roaming procedure. Example 2 can handle the case where all STAs move to an AP of a different group at once.

[0581] Referring to Fig. 58, all STAs can move to APs of different groups at once. For example, STA 1 roams from AP 1 to AP 3, and STA 2 roams from AP 3 to AP 5 at once.

[0582] In this example, STA 1 and AP 1 or STA 2 and AP 3 presented above can exchange MLD roaming requests / responses. In this case, the MLD roaming request will specify the UHR AP MLD ID (or, group 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 default multi-link IE along with whether to accept this.

[0583] By utilizing this example, frame overhead can be reduced compared to Example 1, and data latency can be reduced depending on the AP MLD roaming domain structure. However, data reception may be interrupted if the channels are different. To prevent data reception from being interrupted, the UHR AP MLD (or group-managed AP MLD) manages data reception and MLD roaming; if it accepts an MLD roaming request, the data path can be pre-configured for roaming. This example illustrates the case where only two links are switched, but if multiple links are switched, a roaming request can be sent for multiple links at once to request a link switch. In this case, a link switch can be requested by setting the type field of the reconfigured multi-link element, or if the frame is not a frame requesting addition or deletion, it may refer to a frame requesting a link switch. When an MLD roaming request / response frame is transmitted or received between an AP MLD and a non-AP MLD, if a number of beacons equal to the value of the delete timer in the reset ML IE or the channel switch count in the default ML IE is received from the previous AP MLD, a link switch is performed to the new AP MLD to roam.

[0584] Figure 59 shows the operation process of Example 2 for the MLD roaming procedure.

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

[0586] AP 1 receives a roaming request frame from STA 1. STA identifies the ID of the AP it wants to roam to through the link ID, AP MLD ID, and UHR AP MLD ID (or, group ID) (optional). AP 1 sends to STA 1 whether it accepts the request and roaming response information for APs 4 and 5 (e.g., information exemplified in ) via an MLD roaming response frame.

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

[0588] STA 1 sends an MLD roaming request frame for AP 4 and 5 to AP 1. When STA 1 receives roaming acceptance from AP 1 by receiving an MLD roaming response frame, it roams to AP 4 based on the received information about AP 4. When STA 1's roaming ends, STA 2 also roams to AP 4 based on the acceptance status for AP 5 received through STA 1 and the information about AP 4 and 5.

[0589] Figure 60 shows Example 4 of an MLD roaming procedure.

[0590] Referring to Fig. 60, first STA 1 deletes (or temporarily deletes) AP 4 and STA 2 deletes (or temporarily deletes) AP 5, and then each adds (or temporarily adds) AP 1 and AP 2.

[0591] In this example, to perform the deletion mentioned above, STA 1 and AP 1, or STA 2 and AP 2, can first exchange MLD Roaming Request / Response. At this time, the MLD Roaming Request will specify the (Optional) UHR AP MLD, AP MLD ID, and Link ID for AP 4 and AP 5, and AP 1 or AP 2 will include the information regarding AP 4 and AP 5 in the Basic Multi-link IE along with a response regarding acceptance. After this process is completed, STA 1 or STA 2 can disconnect the connection between AP 1 and AP 3. Even if one link has been 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 forward it to the AP to be roamed, allowing it to be sent after roaming. Next, STA 1 performs an add operation on AP 4, and STA 2 performs an add operation on AP 5. Through this procedure, STA 1 is roamed to AP 4 and STA 2 to AP 5.

[0592] The example above describes the procedure for performing temporary add and delete operations separately. However, if a Timer is utilized, this procedure can be performed simultaneously. For instance, STA 1 and AP 1, or STA 2 and AP 2, can exchange MLD Roaming Requests / Responses. In this case, the MLD Roaming Request may simultaneously request a Delete (or Temporary Delete) for AP 1 and AP 2, and an Add (or Temporary Add) for AP 4 and AP 5, or they may be transmitted individually. At this point, the MLD Roaming Timer presented above is configured. As mentioned earlier, this can be set by a non-AP MLD or an AP MLD via the MLD Roaming Response. The Timer operates after the MLD Roaming Response is successfully transmitted; upon expiration, the AP 1 link from STA 1 is deleted and fully connected to AP 4, while the AP 3 link from STA 2 is deleted and fully connected to AP 5.

[0593] Figure 61 shows the operation process of Examples 3 and 4 for the MLD roaming procedure.

[0594] Referring to Fig. 61, the transmission and reception process of the AP is as follows.

[0595] AP 1 receives a roaming request frame from STA 1. STA identifies the ID of the AP it wishes to roam to via the Link ID, AP MLD ID, and UHR AP MLD ID (or Group ID) (optional). AP 1 sends an MLD roaming response frame to STA 1 indicating acceptance and roaming response information for APs 4 and 5 (e.g., information exemplified in ). AP 1 sets the MLD roaming timer. At this time, when the MLD roaming timer times out or expires, the existing connection is completely deleted, and a full connection is established with the roaming AP.

[0596] Referring to Fig. 61, the transmission and reception process of the STA is as follows.

[0597] STA 1 transmits an MLD roaming request frame for APs 4 and 5 to AP 1. Upon receiving roaming acceptance via an MLD roaming response frame from AP 1, STA 1 roams to AP 4 based on the received information regarding AP 4. Once STA 1's roaming ends, STA 2 also roams to AP 4 based on the acceptance status for AP 5 received via STA 1 and the information regarding APs 4 and 5. STA 1 sets an MLD roaming timer. At this time, if the MLD roaming timer times out or expires, the existing connection is completely deleted, and a full connection is established with the roaming AP.

[0598] Figure 62 shows an example of how to set the type field of an MLD roaming request frame when sending requests for link addition and deletion simultaneously.

[0599] Referring to Fig. 62, in order for a non-AP MLD to roam to a new AP MLD (AP MLD 2), it first requests the addition of a link, and after a connection is established between STA 1 and AP 4, it requests the deletion of the connection with AP 1 that was previously connected to STA 1. When requesting the addition and deletion of links, it can use the link ID and AP MLD ID to make a request to the AP to which it is sending the request. When the deletion request is sent and the connection between STA 1 and AP 1 is completely deleted, STA 1 cannot transmit or receive data with AP MLD 1; however, since STA 2 of the non-AP MLD is connected to AP 3 of AP MLD 1, data transmission and reception between the non-AP MLD and AP MLD 1 is possible. Therefore, data discontinuity can be reduced during the roaming process. After the link change of STA 1 is completed, STA 2 can also request to add a link to AP 5 in the same way, disconnect from AP 3, and fully roam to the new AP MLD 2. At this time, since AP MLD 1 and AP MLD 2 are connected to the same UHR AP MLD (or AP MLD for continuous roaming) (or included in the same roaming group), data accumulated in the queue of AP MLD 1 can be transferred to AP MLD 2.

[0600] Figure 63 shows another example of how to set the type field of an MLD roaming request frame when sending requests for link addition and deletion simultaneously.

[0601] The roaming procedure in Fig. 63 is generally the same as the roaming procedure in Fig. 62, but differs in that the link is deleted first and then the link with AP MLD 2 is added.

[0602] When adding and deleting links (e.g., FIG. 62), or deleting and adding links (e.g., FIG. 63), two requests may be made by transmitting MLD roaming request frames separately, or both operations may be requested simultaneously through the transmission of a single frame. When requesting addition and deletion simultaneously, if the intention is to add a new link first and delete an existing link later (e.g., FIG. 62), the MLD roaming request frame may be configured in the corresponding method described above. When requesting addition and deletion simultaneously, if the intention is to delete an existing link first and add a new link later (e.g., FIG. 63), the MLD roaming request frame may be configured in the corresponding method described above. That is, the link information field may include two Per-STA profiles (one Per-STA profile for addition and the other Per-STA profile for deletion). When requesting addition and deletion individually, the MLD roaming request frame sending the addition / deletion request first can be configured such that the type field is 1) included in the body of the MLD roaming request frame or the common information field of the reset ML IE, or 2) included in the body of the MLD roaming request frame or the link information field of the reset ML IE, as described above. Subsequently, the response to the request is received as an MLD roaming response frame, and the acceptance or rejection of the MLD roaming request frame can be determined through the status code.

[0603] In addition, for STA 1 to completely transition from AP 1 to AP 4, a process such as that shown in FIGS. 64 and FIGS. 65 is required.

[0604] Figure 64 shows an example of MLD roaming using TIM.

[0605] AP 1 can notify STA 1 via TIM whether there is DL data to transmit via a beacon. At this time, STA 1 sends an MLD roaming request to add AP 4 in order to perform roaming. Although this example describes only STA 1, a request to add a link between STA 2 and AP 5 can also be made, as shown in FIG. 48. AP 1 confirms this and responds with acceptance to AP 4. However, STA 1 may have received information from AP 1's recent beacon that it is not currently buffering DL data, or even if it is buffering it, it may not have received it yet. Therefore, AP 1 can inform STA 1 that AP 4 or the UHR AP MLD has the corresponding DL data. That is, when switching to AP 4, STA 1 can immediately receive DL data from AP 4 via PS-poll transmission without waiting until a beacon is received. To achieve this, additional information needs to be specified in the MLD roaming response frame, and such information is as follows:

[0606] - 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 requested STA.

[0607] From an MLD-level perspective, if the UHR AP MLD indicates that it is buffering DL data for the requesting STA, the above TIM field may be included in the body of the MLD roaming response frame or in the common information field.

[0608] From the perspective of the relevant AP, for example, if it is indicated that AP 4 has DL data before switching to AP 4, the above TIM field may be included in the link information field.

[0609] Meanwhile, additionally, the STA (e.g., STA 1) can determine the time to switch by utilizing the MLD roaming timer in the MLD roaming response frame. For example, if there is a significant amount of time remaining before it can receive data from the AP to be roamed (e.g., AP 4) before switching, STA 1 can first receive DL data via PS-Poll (if necessary) to the currently connected AP (e.g., AP 1) and then switch. Alternatively, if there is enough time to receive data from AP 4 even if it switches immediately, STA 1 can switch immediately.

[0610] Figure 65 shows the operation process of an MLD roaming procedure using TIM.

[0611] Referring to Fig. 65, the transmission and reception process of the AP is as follows:

[0612] AP 1 informs STA 1 via TIM through a beacon whether there is DL data to transmit. Upon receiving the roaming request, AP 1 responds with acceptance to AP 4 (+AP 5). AP 1 informs who holds the DL data. The AP or UHR AP MLD holding the DL data transmits the DL data to STA 1 (+STA 2). Upon receiving a request to delete the connection from the STA, AP 1 (+AP 3) deletes the existing connection.

[0613] Referring to Fig. 65, the transmission and reception process of the STA is as follows:

[0614] STA 1 performs roaming and sends an MLD roaming request to add AP 4. At this time, it may also request the addition of AP 5's link to STA 2. STA 1 receives information regarding the DL data. STA 1 (+STA 2) performs roaming to AP 4 (+AP 5). STA 1 (+STA 2) sends a PS-Poll to AP 4 (+AP 5) and receives the corresponding DL data. STA 1 (+STA 2) requests AP 1 (+AP 3) to remove the link.

[0615] Figure 66 shows an example of a roaming process including context transfer.

[0616] Referring to FIG. 66, a non-AP MLD can transmit a roaming request frame. To perform roaming, the non-AP STA can transmit ID information of the AP to be roamed to the UHR AP MLD and / or AP MLD via the roaming request frame. The context forwarding level field of the roaming request frame may indicate the contexts to be forwarded. Upon receiving the roaming request frame, the UHR AP MLD and / or AP MLD can transmit a roaming response frame containing information on whether roaming to the requested AP is possible and / or the context forwarding level.

[0617] When a roaming request frame is received from a Non-AP MLD, the UHR AP MLD and / or AP MLD that received the roaming request frame may transmit control contexts to be transmitted to the roaming AP MLD via DS based on the setting of the context transmission level. If the context transmission level is set to 0, context transmission may not be performed.

[0618] Once context delivery is complete, the AP MLD requests the non-AP MLD to add a link. When a link is established between the AP MLD intending to roam and the non-AP MLD, in the case of DL, the AP MLD after roaming can transmit packets that were in the queue but could not be transmitted due to roaming to the non-AP STA, based on the SN / PN information received from the AP MLD prior to roaming via context delivery. Subsequently, new packets transmitted from the DS can be sent to the non-AP MLD through the AP MLD after roaming. In the case of UL, the non-AP STA can transmit packets to the AP MLD after roaming. The AP MLD requests the deletion of all links connected between the AP MLD prior to roaming and the non-AP STA, and once the deletion of all links is completed, the roaming process can be completed.

[0619] Figure 67 shows an example of a roaming process including context passing when a non-AP MLD transmits a roaming request frame.

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

[0621] An AP MLD (e.g., the existing AP MLD) may receive a roaming request frame from a non-AP MLD. The AP MLD may send a roaming response frame to the non-AP MLD and transmit information about the existing AP MLD and / or necessary context to the AP MLD that the non-AP MLD intends to roam to (e.g., the target AP MLD). Once context delivery is complete, the AP MLD and / or UHR AP MLD may request the non-AP MLD to add a link. After the new link is established, in the case of DL, the target AP MLD may transmit packets in the existing AP MLD's queue based on the SN / PN information received through context delivery. In the case of UL, the target AP MLD may receive frames over the new link. The target AP MLD may request the deletion of the link connected to the existing AP MLD.

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

[0623] A Non-AP MLD can send a roaming request frame to a UHR AP MLD. The Non-AP MLD can receive information regarding whether roaming is accepted and / or about APs through a roaming response frame. Upon receiving a link addition request, the non-AP MLD can add / connect / establish a link with the new AP MLD (e.g., target AP MLD) and transmit and receive frames through the established link. Upon receiving a link deletion request, the non-AP MLD can delete the link connected to the existing AP MLD.

[0624] Figure 68 shows an example of a roaming process including context passing when the AP MLD transmits a roaming request frame.

[0625] When an AP MLD sends a roaming request, the context forwarding level can provide information about the capability of the AP MLD to forward context. In this case, when a non-AP STA sends a roaming response, the context forwarding level value can be set to a value less than or equal to the context forwarding level value of the roaming request.

[0626] Referring to Fig. 68, the transmission and reception process of the AP MLD is as follows.

[0627] An AP MLD (e.g., the existing AP MLD) can send a roaming request frame to a non-AP MLD. The AP MLD receives a roaming response frame from the non-AP MLD and can send information about the existing AP MLD and / or the necessary context to the AP MLD that the non-AP MLD intends to roam to (e.g., the target AP MLD). Once context delivery is complete, the AP MLD and / or UHR AP MLD can request the non-AP MLD to add a link. After the new link is established, in the case of DL, the target AP MLD can transmit packets in the existing AP MLD's queue based on the SN / PN information received via context delivery. In the case of UL, the target AP MLD can receive frames over the new link. The target AP MLD can request the deletion of the link connected to the existing AP MLD.

[0628] Referring to Fig. 68, the transmission and reception process of the non-AP MLD is as follows.

[0629] A Non-AP MLD can receive a roaming request frame from a UHR AP MLD. The Non-AP MLD can notify whether it accepts roaming and / or the AP to roam to via a roaming response frame. Upon receiving a link addition request, the non-AP MLD can add / connect / establish a link with the new AP MLD (e.g., target AP MLD) and transmit and receive frames over the established link. Upon receiving a link deletion request, the non-AP MLD can delete the link connected to the existing AP MLD.

[0630] The technical features of the present disclosure described above may be applied to various devices and methods. For example, the technical features of the present disclosure described above may be performed or supported through the device of FIG. 1 and / or FIG. 5. For example, the technical features of the present disclosure described above may be applied only to parts of FIG. 1 and / or FIG. 5. For example, the technical features of the present disclosure described above may be implemented based on the processing chip (114, 124) of FIG. 1, or based on the processor (111, 121) and memory (112, 122) of FIG. 1, or based on the processor (510) and memory (520) of FIG. 5.

[0631] For example, the processor (121) and / or processing chip (124) of FIG. 1 may be configured to perform operations performed in the first AP MLD in the present disclosure by executing instructions stored in memory (122). The operations include: the first AP affiliated with the first AP MLD receiving a request frame for a sequential transition from the first AP MLD to the second AP MLD from a STA (station) affiliated with a non-AP MLD; the first AP transmitting a response frame for the request frame to the STA; the first AP transmitting first data that is queued in a buffer after the request frame is received to the STA; and, based on detecting a transmission failure for the transmission of the first data, the first AP transmitting the first data to the second AP affiliated with the second AP MLD.

[0632] For example, the processor (111), processing chip (114) of FIG. 1 and / or the processor (510) of FIG. 5 may be configured to perform operations performed in a non-AP MLD in the present disclosure by executing instructions stored in memory (112, 520). The operations include: an operation in which a STA (station) affiliated with the non-AP MLD transmits a request frame for a sequential transition from the first AP MLD to the first AP MLD to the first AP MLD; an operation in which the STA receives a response frame for the request frame from the first AP; and an operation in which the STA receives a transmission of a first data queued in a buffer after the request frame has been transmitted from the first AP, and, upon a transmission failure for the transmission of the first data, the first data is transferred from the first AP to the second AP affiliated with the second AP MLD.

[0633] The technical features of the present disclosure may be implemented based on a computer-readable medium (CRM). For example, the CRM proposed by the present disclosure is at least one computer-readable medium comprising instructions based on execution by at least one processor.

[0634] For example, the CRM may be the memory (122) of FIG. 1 and / or a separate external memory / storage medium / disk. The CRM may store instructions for performing operations performed in the first AP MLD in the present disclosure based on execution by a processor (e.g., the processor (121) and / or processing chip (124) of FIG. 1). The operations include: an operation in which a first AP affiliated with the first AP MLD receives a request frame for a sequential transition from the first AP MLD to the second AP MLD from a STA (station) affiliated with a non-AP MLD; an operation in which the first AP transmits a response frame for the request frame to the STA; an operation in which the first AP transmits first data queued in a buffer to the STA after the request frame has been received. and based on detecting a transmission failure for the transmission of the first data, the operation includes the first AP transmitting the first data to the second AP associated with the second AP MLD.

[0635] For example, the CRM may be the memory (112) of FIG. 1, the memory (520) of FIG. 5, and / or a separate external memory / storage medium / disk. The CRM may store instructions for performing operations performed in a non-AP MLD in the present disclosure, based on execution by a processor (e.g., the processor (111) of FIG. 1, the processing chip (114), and / or the processor (510) of FIG. 5). The operations include: an operation in which a STA (station) affiliated with the non-AP MLD transmits a request frame for a sequential transition from the first AP MLD to the second AP MLD to a first AP affiliated with the first AP MLD; an operation in which the STA receives a response frame for the request frame from the first AP; and the STA includes the operation of receiving the transmission of the first data that is queued in the buffer after the request frame is transmitted from the first AP, and based on the occurrence of a transmission failure for the transmission of the first data, the first data is transferred from the first AP to the second AP associated with the second AP MLD.

[0636] The technical features of the present disclosure described above are applicable to various applications or business models. For example, the technical features described above may be applied for wireless communication in devices supporting Artificial Intelligence (AI).

[0637] Artificial intelligence refers to the field of researching artificial intelligence or the methodologies to create it, while machine learning refers to the field of researching methodologies to define and solve various problems addressed within the field of artificial intelligence. Machine learning is also defined as an algorithm that improves performance on a task through continuous experience.

[0638] An Artificial Neural Network (ANN) is a model used in machine learning that can refer to any model capable of problem-solving, composed of artificial neurons (nodes) that form a network through the connection of synapses. An artificial neural network can be defined by connection patterns between neurons in different layers, a learning process that updates model parameters, and an activation function that generates output values.

[0639] An artificial neural network may include an input layer, an output layer, and optionally one or more hidden layers. Each layer may include one or more neurons, and the artificial neural network may include synapses connecting the neurons. In an artificial neural network, each neuron may output a function value of an activation function for input signals, weights, and biases input through the synapses.

[0640] Model parameters refer to parameters determined through learning, including synaptic connection weights and neuron biases. Hyperparameters, on the other hand, refer to parameters that must be set prior to training in a machine learning algorithm, including the learning rate, number of iterations, mini-batch size, and initialization function.

[0641] The objective of training an artificial neural network can be viewed as determining model parameters that minimize the loss function. The loss function can be used as an indicator to determine optimal model parameters during the training process of an artificial neural network.

[0642] Machine learning can be classified into supervised learning, unsupervised learning, and reinforcement learning depending on the learning method.

[0643] Supervised learning refers to a method of training an artificial neural network with labels provided for the training data; a label can refer to the correct answer (or result) that the neural network must infer when the training data is input. Unsupervised learning refers to a method of training an artificial neural network without labels provided for the training data. Reinforcement learning refers to a learning method in which an agent defined within an environment is trained to select an action or sequence of actions that maximizes the cumulative reward in each state.

[0644] Machine learning implemented using a Deep Neural Network (DNN) that includes multiple hidden layers among artificial neural networks is also called Deep Learning, and Deep Learning is a part of Machine Learning. Hereinafter, Machine Learning is used in a sense that includes Deep Learning.

[0645] In addition, the aforementioned technical features can be applied to the wireless communication of robots.

[0646] A robot can refer to a machine that automatically processes or operates a given task based on its own capabilities. In particular, a robot that has the ability to perceive its environment, make decisions on its own, and perform actions can be called an intelligent robot.

[0647] Robots can be classified into industrial, medical, domestic, and military types depending on their purpose or field of use. Robots are equipped with drive units, including actuators or motors, to perform various physical movements, such as moving robot joints. Additionally, mobile robots include wheels, brakes, and propellers in their drive units, enabling them to drive on the ground or fly in the air.

[0648] In addition, the aforementioned technical features can be applied to devices that support augmented reality.

[0649] Extended Reality is a collective term for Virtual Reality (VR), Augmented Reality (AR), and Mixed Reality (MR). VR technology provides real-world objects or backgrounds solely as CG images, AR technology provides virtual CG images superimposed on real-world images, and MR technology is a computer graphics technology that mixes and combines virtual objects with the real world.

[0650] MR technology is similar to AR technology in that it displays real-world objects and virtual objects together. However, there is a difference in that while virtual objects in AR technology are used to complement real-world objects, virtual objects and real-world objects are used as equals in MR technology.

[0651] XR technology can be applied to HMDs (Head-Mount Displays), HUDs (Head-Up Displays), mobile phones, tablet PCs, laptops, desktops, TVs, digital signage, etc., and devices to which XR technology is applied can be called XR devices.

[0652] The present disclosure may have various advantageous effects.

[0653] For example, roaming delays caused by transmission failures can be reduced.

[0654] The advantageous effects obtainable through specific embodiments of the present disclosure are not limited to those listed above. For example, there may be various technical effects that a person skilled in the art can understand and / or derive from the present disclosure. Accordingly, the specific effects of the present disclosure are not limited to those explicitly described herein and may include various effects that can be understood or derived from the technical features of the present disclosure.

[0655] The claims described in this disclosure may be combined in various ways. For example, the technical features of the method claims of this disclosure may be combined to be implemented as a device, and the technical features of the device claims of this disclosure may be combined to be implemented as a method. Additionally, the technical features of the method claims of this disclosure and the technical features of the device claims of this disclosure may be combined to be implemented as a device, and the technical features of the method claims of this disclosure and the technical features of the device claims of this disclosure may be combined to be implemented as a method.

Claims

1. A method performed at a first AP (access point) MLD (multi-link device), A step in which a first AP affiliated with the first AP MLD receives a request frame for a continuous transition from the first AP MLD to the second AP MLD from a STA (station) affiliated with a non-AP MLD; The step of the first AP transmitting a response frame for the request frame to the STA; The step of the first AP transmitting to the STA the first data that is queued in the buffer after the request frame is received; and A method comprising the step of the first AP transmitting the first data to the second AP associated with the second AP MLD based on detecting a transmission failure for the transmission of the first data.

2. A method according to claim 1, wherein the response frame comprises at least one of information regarding the presence of data waiting in the buffer, information regarding the amount of data waiting in the buffer, information regarding the number of one or more packets associated with the data waiting in the buffer, information regarding the sequence number (SN) or packet number (PN) of the one or more packets, or information regarding the traffic identifier (TID) of the one or more packets.

3. A method according to claim 1, further comprising the step of, after a transmission failure for the transmission of the first data is detected, the first AP transmitting the second data waiting after the first data in the buffer to the STA.

4. The step of the first AP starting a timer when the first AP starts transmitting data waiting in the buffer to the STA (upon); and The method further includes the step of, upon expiration of the timer, the first AP stopping the transmission of data waiting in the buffer to the STA, and the first AP transferring or discarding the data remaining in the buffer to the second AP. A method comprising the step of transmitting the first data, wherein the first AP transmits the first data waiting in the buffer to the STA while the timer is operating.

5. The method of claim 4, wherein the step of transmitting the first data comprises transmitting the first data to the second AP before the expiration of the timer based on the first AP detecting a transmission failure for the transmission of the first data.

6. In claim 4, the value of the timer is related to the period during which the timer operates, and A method in which the operating period of the above timer is determined based on at least one of the size of the data waiting in the buffer or the number of one or more packets related to the data waiting in the buffer.

7. A method according to claim 4, wherein the response frame includes information regarding the value of the timer related to the period during which the timer operates.

8. A method according to claim 1, wherein the step of transmitting the first data comprises, based on detecting a transmission failure for the transmission of the first data, the first AP transmitting to the second AP all data waiting in the buffer, including the first data and second data waiting after the first data in the buffer.

9. A method according to claim 8, further comprising the step of the first AP transmitting all data waiting in the buffer to the second AP, and then the first AP transmitting information about the absence of data waiting in the buffer to the STA.

10. A method according to claim 1, wherein the step of transmitting the first data comprises the step of the first AP transmitting the first data to the second AP based on at least one of a channel state, the amount of the first data, or the lifetime of the first data.

11. A method according to claim 1, further comprising the step of the first AP transmitting information regarding the sequence number (SN) of one or more packets associated with the first data to the second AP.

12. A method according to claim 1, wherein the retransmission of the first data is performed from the second AP to the STA after the continuous switching of the STA from the first AP MLD to the second AP MLD is performed.

13. In claim 1, the step of detecting a transmission failure for the transmission of the first data comprises: The step of the first AP monitoring the reception of an ACK (acknowledgement) for the transmission of the first data from the STA; and A method comprising the step of detecting a transmission failure for the transmission of the first data based on the fact that the first AP does not receive an ACK for the transmission of the first data.

14. In the first AP (access point) MLD (multi-link device), Transmitter / Receiver; Memory; and It includes at least one processor functionally coupled with the above-mentioned transceiver and the above-mentioned memory, and The above memory stores instructions for performing operations based on execution by the at least one processor, and the operations are: An operation in which a first AP affiliated with the first AP MLD receives a request frame for a continuous transition from the first AP MLD to the second AP MLD from a STA (station) affiliated with a non-AP MLD; The operation of the first AP transmitting a response frame for the request frame to the STA; The operation of the first AP transmitting the first data queued in the buffer to the STA after the request frame is received; and A first AP MLD comprising an operation in which the first AP transmits the first data to a second AP associated with the second AP MLD, based on detecting a transmission failure for the transmission of the first data.

15. In the device, At least one processor; and It includes at least one memory functionally coupled with the above-mentioned at least one processor, and The above at least one memory stores instructions for performing operations based on execution by the above at least one processor, and the operations are: An operation in which a first AP (access point) affiliated with a multi-link device (MLD) receives a request frame for a continuous transition from the first AP MLD to the second AP MLD from a station (STA) affiliated with a non-AP MLD; The operation of the first AP transmitting a response frame for the request frame to the STA; The operation of the first AP transmitting the first data queued in the buffer to the STA after the request frame is received; and A device comprising an operation in which the first AP transmits the first data to a second AP associated with the second AP MLD, based on detecting a transmission failure for the transmission of the first data.

16. In a non-transitory computer-readable medium (CRM) storing program code that implements instructions for performing operations based on execution by at least one processor, said operations are: An operation in which a first AP (access point) affiliated with a multi-link device (MLD) receives a request frame for a continuous transition from the first AP MLD to the second AP MLD from a station (STA) affiliated with a non-AP MLD; The operation of the first AP transmitting a response frame for the request frame to the STA; The operation of the first AP transmitting the first data queued in the buffer to the STA after the request frame is received; and A CRM comprising an operation in which the first AP transmits the first data to the second AP associated with the second AP MLD, based on detecting a transmission failure for the transmission of the first data.

17. A method performed on a non-AP (access point) MLD (multi-link device), A step in which a STA (station) affiliated with the above non-AP MLD transmits a request frame for a continuous transition from the first AP MLD to the second AP MLD to the first AP affiliated with the first AP MLD; The step of the STA receiving a response frame for the request frame from the first AP; and The above STA includes the step of receiving transmission of the first data that is queued in the buffer after the request frame is transmitted from the first AP, and A method in which, based on the occurrence of a transmission failure for the transmission of the first data, the first data is transferred from the first AP to the second AP associated with the second AP MLD.

18. In a non-AP (access point) MLD (multi-link device), Transmitter / Receiver; Memory; and It includes at least one processor functionally coupled with the above-mentioned transceiver and the above-mentioned memory, and The above memory stores instructions for performing operations based on execution by the at least one processor, and the operations are: An operation in which a STA (station) affiliated with the above non-AP MLD transmits a request frame for a continuous transition from the first AP MLD to the second AP MLD to the first AP affiliated with the first AP MLD; The operation of the STA receiving a response frame for the request frame from the first AP; and The above STA includes an operation of receiving transmission of the first data queued in the buffer after the request frame is transmitted from the first AP, and Based on the occurrence of a transmission failure for the transmission of the first data, the first data is a non-AP MLD transmitted from the first AP to the second AP associated with the second AP MLD.

19. The non-AP MLD of claim 18, wherein the operations further comprise the operation of the STA receiving second data waiting after the first data in the buffer from the first AP after a transmission failure for the transmission of the first data occurs.

20. A non-AP MLD according to claim 18, wherein, based on the occurrence of a transmission failure for the transmission of the first data, all data waiting in the buffer, including the first data and the second data waiting after the first data in the buffer, is transferred from the first AP to the second AP.

Images