Link modification recommendation for roaming in wireless LAN system
The method for link modification proposal in wireless LAN systems addresses the challenge of seamless roaming by allowing STAs to request and perform link modifications within a roaming group, reducing overhead and maintaining connectivity.
Patent Information
- Application Number
- PCT/KR2024/096523
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-07-29
- Filing Date
- 2024-11-13
- Publication Date
- 2025-05-22
AI Technical Summary
Existing wireless LAN systems face challenges in achieving seamless roaming due to the need for reassociation processes and overheads associated with authentication and configuration resets during Fast BSS Transition (FT) technologies.
A method and apparatus for link modification proposal in wireless LAN systems, where a station (STA) performs association with an access point (AP), receives a link reconfiguration notify frame with recommended link modifications for roaming, and transmits a roaming request frame to request link modification, enabling seamless roaming within a roaming group.
This solution enables seamless STA roaming by performing link modifications based on proposed changes, reducing overhead and maintaining connectivity without the need for repeated authentication and configuration processes.
Smart Images

Figure KR2024096523_22052025_PF_FP_ABST
Abstract
Description
Proposal to fix link for roaming in wireless LAN systems
[0001] The present disclosure relates to a link modification recommendation for roaming in a wireless LAN system.
[0002] Next-generation Wi-Fi (e.g., IEEE 802.11be and / or later) aims to support ultra-high reliability in signal transmission to STAs. To this end, various technologies are being considered to support high throughput, low latency, and extended range. For example, a non-AP (access point) multi-link device (MLD) / STA (station) can roam between APs / MLDs. To achieve seamless roaming, a preferred link modification proposal for roaming may be required.
[0003] The present disclosure provides a method and device for link modification proposal for roaming in a wireless LAN system.
[0004] According to an embodiment of the present disclosure, a method performed by an STA in a wireless LAN system includes the steps of: performing an association procedure with an access point (AP); receiving, from the AP, a link reconfiguration notify frame including a list of links for which link modification is recommended for roaming, wherein each link in the list of links for which link modification is recommended is associated with a corresponding AP in a roaming group; transmitting, to the AP, a roaming request frame for requesting link modification of at least one link in the list of links for which link modification is recommended; performing link modification of the at least one link based on receiving a roaming response frame for the roaming request frame; and performing roaming from a first AP included in the roaming group to a second AP included in the roaming group based on the link modification of the at least one link.
[0005] According to an embodiment of the present disclosure, a method performed by an AP in a wireless LAN system comprises the steps of: performing an association procedure with a station (STA); transmitting, to the STA, a link reconfiguration notify frame including a list of links for which link modification is recommended for roaming, wherein each link in the list of links for which link modification is recommended is associated with a corresponding AP in a roaming group; receiving, from the STA, a roaming request frame for requesting link modification of at least one link in the list of links for which link modification is recommended; and transmitting, to the STA, a roaming response frame for link modification of the at least one link, wherein roaming of the STA is performed from a first AP included in the roaming group to a second AP included in the roaming group based on the link modification of the at least one link.
[0006] In various embodiments, devices for implementing the above-described methods are provided.
[0007] The present disclosure may have various advantageous effects.
[0008] For example, a UHR AP MLD can use a link reconfiguration notification frame to inform a non-AP MLD STA of the APs it proposes for roaming and the preferences for the proposals. Furthermore, a non-AP MLD STA can first request an AP proposal for roaming by first sending a link reconfiguration notification request frame to the UHR AP MLD.
[0009] The beneficial effects that can be achieved through specific embodiments of the present disclosure are not limited to the beneficial effects listed above. For example, various technical effects may be understood and / or derived from the present disclosure by those skilled in the art. Therefore, the specific effects of the present disclosure are not limited to those explicitly described herein, but may include various effects that can be understood or derived from the technical features of the present disclosure.
[0010] FIG. 1 illustrates an example of a transmitting device and / or a receiving device of the present disclosure.
[0011] Figure 2 is a conceptual diagram showing the structure of a wireless local area network (WLAN).
[0012] Figure 3 is a diagram illustrating a general link setup process.
[0013] Figure 4 illustrates an embodiment of a multi-link (ML).
[0014] FIG. 5 illustrates a modified example of a transmitting device and / or a receiving device of the present disclosure.
[0015] Figure 6 shows the operation according to UL-MU.
[0016] Figure 7 shows an example of a header of a MAC frame.
[0017] Figure 8 shows an over-the-air (OTA) FT protocol in a Robust Security Network (RSN).
[0018] Figure 9 shows the high-level architecture of AP MLD.
[0019] Figure 10 shows an example of a high-level architecture for a UHR AP MLD.
[0020] Figure 11 shows another example of the upper layer architecture for UHR AP MLD.
[0021] Figure 12 shows the arrangement of AP MLDs for roaming.
[0022] Figure 13 shows an example for RNR IE.
[0023] Figure 14 shows another example for the RNR IE.
[0024] Figure 15 shows another example for the RNR IE.
[0025] FIG. 16 illustrates an example of a transmission and reception process performed by an AP and a STA according to an embodiment of the present disclosure.
[0026] FIG. 17 illustrates an example of the structure of an ML probe request frame when the common information field includes a roaming suggestion possible field according to an embodiment of the present disclosure.
[0027] FIG. 18 illustrates an example of the structure of an ML probe request frame when the link information field includes a roaming suggestion possible field according to an embodiment of the present disclosure.
[0028] FIG. 19 illustrates an example of a method performed by a STA for AP proposal based on a link re-establishment notification frame according to an embodiment of the present disclosure.
[0029] FIG. 20 illustrates an example of a method performed by an AP for AP proposal based on a link reset notification frame according to an embodiment of the present disclosure.
[0030] FIG. 21 illustrates an example of a transmission and reception process performed by an AP and a STA for an AP proposal based on a link re-establishment notification frame according to an embodiment of the present disclosure.
[0031] FIG. 22 illustrates an operation procedure when a link reset notification request frame includes a roaming cause code according to an embodiment of the present disclosure.
[0032] FIG. 23 illustrates an operation procedure when a link reset notification request frame does not include a roaming cause code according to an embodiment of the present disclosure.
[0033] FIG. 24 illustrates an operation procedure when a link reset notification request frame is not transmitted according to an embodiment of the present disclosure.
[0034] FIG. 25 illustrates a first example of a reset ML IE structure for indicating the presence of a common information field later, according to an embodiment of the present disclosure.
[0035] FIG. 26 illustrates a second example of a reset ML IE structure for indicating the presence of a common information field later, according to an embodiment of the present disclosure.
[0036] FIG. 27 illustrates a third example of a reset ML IE structure for indicating the presence of a common information field later, according to an embodiment of the present disclosure.
[0037] FIG. 28 illustrates an example of a common information field of a reset multi-link IE according to an embodiment of the present disclosure.
[0038] FIG. 29 illustrates an example of a link information field of a reset multi-link IE according to an embodiment of the present disclosure.
[0039] FIG. 30 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.
[0040] FIG. 31 illustrates an example in which a common information field of a reset multi-link ID includes a UHR MLD MAC address and an AP MLD ID according to an embodiment of the present disclosure.
[0041] FIG. 32 illustrates an example in which a link 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.
[0042] FIG. 33 illustrates an example in which an AP MLD ID is included in a link information field of a reset multi-link IE according to an embodiment of the present disclosure.
[0043] FIG. 34 illustrates another example in which 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.
[0044] FIG. 35 illustrates 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.
[0045] FIG. 36 illustrates an example in which a temporary field is included in the common information field of a reset ML IE according to an embodiment of the present disclosure.
[0046] FIG. 37 illustrates an example in which a temporary field is included in the link information field of a reset ML IE according to an embodiment of the present disclosure.
[0047] FIG. 38 illustrates another example in which a temporary field is included in the link information field of a reset ML IE according to an embodiment of the present disclosure.
[0048] Figure 39 shows an example where the AP removal timer is included in the common information field of the reset ML IE.
[0049] Figure 40 shows an example of the common information field structure of the basic ML IE.
[0050] Figure 41 shows an example of the link information field structure of the basic ML IE.
[0051] Figure 42 shows an example of a group key information field.
[0052] Figure 43 illustrates a procedure for determining whether an N_AP is capable of roaming using the Collocation Enabled field.
[0053] Figure 44 illustrates a procedure for determining whether an N_AP is capable of roaming using a Collocation ID.
[0054] Figure 45 illustrates the MLD roaming procedure when a UHR AP MLD ID is entered in the reset element.
[0055] Figure 46 illustrates the MLD roaming procedure when the UHR AP MLD ID is not entered in the reset element.
[0056] Figure 47 shows an example of a collocated AP set.
[0057] Figure 48 shows Example 1 for the MLD roaming procedure.
[0058] Figure 49 shows the operation process of Example 1 for the MLD roaming procedure.
[0059] Figure 50 shows Example 2 for the MLD roaming procedure.
[0060] Figure 51 shows the operation process of Example 2 for the MLD roaming procedure.
[0061] Figure 52 shows Example 3 for the MLD roaming procedure.
[0062] Figure 53 shows Example 4 for the MLD roaming procedure.
[0063] Figure 54 shows the operation process of Examples 3 and 4 for the MLD roaming procedure.
[0064] Figure 55 illustrates an example of how to set the type field of an MLD roaming request frame when simultaneously transmitting requests for link addition and deletion.
[0065] Figure 56 illustrates another example of how to set the type field of an MLD roaming request frame when simultaneously transmitting requests for link addition and deletion.
[0066] Figure 57 shows an example of MLD roaming using TIM.
[0067] Figure 58 shows the operation process for the MLD roaming procedure using TIM.
[0068] In this disclosure, “A or B” can mean “only A,” “only B,” or “both A and B.” In other words, “A or B” in this disclosure can be interpreted as “A and / or B.” For example, “A, B or C” in this disclosure can mean “only A,” “only B,” “only C,” or “any combination of A, B, and C.”
[0069] As used herein, a slash ( / ) or a comma can mean "and / or." For example, "A / B" can mean "A and / or B." Accordingly, "A / B" can mean "only A," "only B," or "both A and B." For example, "A, B, C" can mean "A, B, or C."
[0070] 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 identically to “at least one of A and B.”
[0071] In addition, parentheses used in the present disclosure may mean “for example.” Specifically, when “control information (UHR-Signal field)” is indicated, the “UHR-Signal field” may be suggested as an example of “control information.” In other words, the “control information” of the present disclosure is not limited to the “UHR-Signal field,” and the “UHR-Signal field” may be suggested as an example of “control information.” In addition, even when indicated as “control information (UHR-Signal field),” the “UHR-Signal field” may be suggested as an example of “control information.”
[0072] Additionally, as used herein, “a / an” can mean “at least one” or “one or more.” Additionally, terms ending in “(s)” can mean “at least one” or “one or more.”
[0073] Additionally, the expressions “based on” or “on the basis of” or “according to” used in this disclosure mean “based at least in part on” and do not mean “based solely on.”
[0074] Technical features individually described in one drawing in this disclosure may be implemented individually or simultaneously.
[0075] The following examples of the present disclosure can be applied to various wireless communication systems. For example, the following examples of the present disclosure can be applied to a wireless local area network (WLAN) system. For example, the present disclosure can be applied to the IEEE 802.11a / g / n / ac / ax / be / bn standards. Furthermore, the examples of the present disclosure can be applied to the Ultra High Reliability (UHR) standard or a next-generation wireless LAN standard that enhances IEEE 802.11bn. Furthermore, the examples of the present disclosure can be applied to a mobile communication system. For example, the present disclosure can be applied to a mobile communication system based on the Long Term Evolution (LTE) standard and its evolution based on the 3rd Generation Partnership Project (3GPP) standard.
[0076] In order to explain the technical features of the present disclosure, technical features to which the present disclosure can be applied are described below.
[0077] FIG. 1 illustrates an example of a transmitting device and / or a receiving device of the present disclosure.
[0078] 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 a mobile terminal, a wireless device, a Wireless Transmit / Receive Unit (WTRU), a User Equipment (UE), a Mobile Station (MS), a Mobile Subscriber Unit, or simply a user. The STA (110, 120) of the present disclosure may also be referred to by various names such as a network, a base station, a Node-B, an access point (AP), a repeater, a router, a relay, etc. The STA (110, 120) of the present disclosure may also be referred to by various names such as a receiving apparatus, a transmitting apparatus, a receiving STA, a transmitting STA, a receiving device, a transmitting device, etc.
[0079] For example, STA (110, 120) may perform the role of an AP (access point) or a non-AP role. That is, STA (110, 120) of the present disclosure may 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.
[0080] The STA (110, 120) of the present disclosure can support various communication standards other than the IEEE 802.11 standard. For example, it can support communication standards according to the 3GPP standard (e.g., LTE, LTE-A, 5G NR standard). In addition, the STA of the present disclosure can be implemented in various devices such as a mobile phone, a vehicle, a personal computer, etc. In addition, the STA of the present disclosure can support communication for various communication services such as voice calls, video calls, data communications, and autonomous driving (Self-Driving, Autonomous-Driving).
[0081] In the present disclosure, STA (110, 120) may include a medium access control (MAC) and a physical layer interface for a wireless medium that follow the provisions of the IEEE 802.11 standard.
[0082] Based on the sub-drawing (a) of Fig. 1, STA (110, 120) is described as follows.
[0083] The first STA (110) may include a processor (111), a memory (112), and a transceiver (113). The illustrated processor, memory, and transceiver may each be implemented as separate chips, or at least two blocks / functions may be implemented through a single chip.
[0084] The transceiver (113) of the first STA performs signal transmission and reception operations. Specifically, it can transmit and receive IEEE 802.11 packets (e.g., IEEE 802.11a / b / g / n / ac / ax / be, etc.).
[0085] For example, the first STA (110) can perform the intended operation of the AP. For example, the processor (111) of the AP can receive a signal through the transceiver (113), process the received signal, generate a transmission signal, and perform control for signal transmission. The memory (112) of the AP can store a signal received through the transceiver (113) (i.e., a reception signal) and store a signal to be transmitted through the transceiver (i.e., a transmission signal).
[0086] For example, the second STA (120) can perform the intended operation of a non-AP STA. For example, the transceiver (123) of the non-AP performs signal transmission and reception operations. Specifically, it can transmit and receive IEEE 802.11 packets (e.g., IEEE 802.11a / b / g / n / ac / ax / be, etc.).
[0087] For example, the processor (121) of the Non-AP STA can receive a signal through the transceiver (123), process the received signal, generate a transmission signal, and perform control for signal transmission. The memory (122) of the Non-AP STA can store a signal received through the transceiver (123) (i.e., a reception signal) and store a signal to be transmitted through the transceiver (i.e., a transmission signal).
[0088] For example, in the specification below, the operation of a device indicated as AP may be performed in the first STA (110) or the second STA (120). For example, if the first STA (110) is an AP, the operation of the device indicated as AP may be controlled by the processor (111) of the first STA (110), and a related signal may be transmitted or received through a transceiver (113) controlled by the processor (111) of the first STA (110). In addition, control information related to the operation of the AP or a transmission / reception signal of the AP may be stored in the memory (112) of the first STA (110). In addition, when the second STA (110) is an AP, the operation of the device indicated as an AP is controlled by the processor (121) of the second STA (120), and a related signal can be transmitted or received through a transceiver (123) controlled by the processor (121) of the second STA (120). In addition, control information related to the operation of the AP or the transmission / reception signal of the AP can be stored in the memory (122) of the second STA (110).
[0089] For example, in the specification below, the operation of a device indicated as a non-AP (or User-STA) may be performed in the STA (110) or the second STA (120). For example, if the second STA (120) is a non-AP, the operation of the device indicated as a non-AP may be controlled by the processor (121) of the second STA (120), and a related signal may be transmitted or received through a transceiver (123) controlled by the processor (121) of the second STA (120). In addition, control information related to the operation of the non-AP or the transmission / reception signal of the AP may be stored in the memory (122) of the second STA (120). For example, if the first STA (110) is a non-AP, the operation of a device indicated as a non-AP is controlled by the processor (111) of the first STA (110), and a related signal may be transmitted or received through a transceiver (113) controlled by the processor (111) of the first STA (120). In addition, control information related to the operation of the non-AP or the transmission / reception signal of the AP may be stored in the memory (112) of the first STA (110).
[0090] In the following specification, devices called (transmitting / receiving) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmitting / receiving) Terminal, (transmitting / receiving) device, (transmitting / receiving) apparatus, network, etc. may refer to the STA (110, 120) of FIG. 1. For example, devices indicated as (transmitting / receiving) STA, first STA, second STA, STA1, STA2, AP, first AP, second AP, AP1, AP2, (transmitting / receiving) Terminal, (transmitting / receiving) device, (transmitting / receiving) apparatus, network, etc. without specific drawing symbols may also refer to the STA (110, 120) of FIG. 1. For example, in the example below, the operation of various STAs transmitting and receiving signals (e.g., PPDUs) may be performed by the transceivers (113, 123) of FIG. 1. In addition, in the example below, the operation of various STAs generating transmission and reception signals or performing data processing or calculations in advance for transmission and reception signals may be performed by the processors (111, 121) of FIG. 1.For example, an example of an operation for generating a transmission / reception signal or performing data processing or operation in advance for a transmission / reception signal may include 1) an operation for determining / obtaining / configuring / computing / decoding / encoding bit information of a subfield (SIG, STF, LTF, Data) field included in a PPDU, 2) an operation for determining / configuring / obtaining time resources or frequency resources (e.g., subcarrier resources) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 3) an operation for determining / configuring / obtaining a specific sequence (e.g., a pilot sequence, an STF / LTF sequence, an extra sequence applied to SIG) used for a subfield (SIG, STF, LTF, Data) field included in a PPDU, 4) a power control operation and / or a power saving operation applied to an STA, 5) an operation related to determining / obtaining / configuring / computing / decoding / encoding an ACK signal, etc. Additionally, in the examples below, various information (e.g., information related to fields / subfields / control fields / parameters / power, etc.) used by various STAs for determining / acquiring / configuring / computing / decoding / encoding transmission / reception signals can be stored in the memory (112, 122) of FIG. 1.
[0091] The device / STA of the sub-drawing (a) of FIG. 1 described above can be modified as in the sub-drawing (b) of FIG. 1. Hereinafter, the STA (110, 120) of the present disclosure will be described based on the sub-drawing (b) of FIG. 1.
[0092] For example, the transceiver (113, 123) illustrated in sub-drawing (b) of FIG. 1 may perform the same function as the transceiver illustrated in sub-drawing (a) of FIG. 1 described above. For example, the processing chip (114, 124) illustrated in sub-drawing (b) of FIG. 1 may include a processor (111, 121) and a memory (112, 122). The processor (111, 121) and the memory (112, 122) illustrated in sub-drawing (b) of FIG. 1 may perform the same function as the processor (111, 121) and the memory (112, 122) illustrated in sub-drawing (a) of FIG. 1 described above.
[0093] The mobile terminal, wireless device, Wireless Transmit / Receive Unit (WTRU), User Equipment (UE), Mobile Station (MS), Mobile Subscriber Unit, user, user STA, network, Base Station, Node-B, Access Point (AP), repeater, router, relay, receiving device, transmitting device, receiving STA, transmitting STA, receiving Device, transmitting Device, receiving Apparatus, and / or transmitting Apparatus described below may refer to the STA (110, 120) illustrated in the sub-drawings (a) / (b) of FIG. 1, or may refer to the processing chip (114, 124) illustrated in the sub-drawing (b) of FIG. 1. That is, the technical feature of the present disclosure may be performed in the STA (110, 120) illustrated in the sub-drawings (a) / (b) of FIG. 1, or may be performed only in the processing chip (114, 124) illustrated in the sub-drawings (b) of FIG. 1. For example, the technical feature that the transmitting STA transmits a control signal may be understood as a technical feature that the control signal generated in the processor (111, 121) illustrated in the sub-drawings (a) / (b) of FIG. 1 is transmitted through the transceiver (113, 123) illustrated in the sub-drawings (a) / (b) of FIG. 1. Alternatively, the technical feature that the transmitting STA transmits a control signal may be understood as a technical feature that the control signal to be transmitted to the transceiver (113, 123) is generated in the processing chip (114, 124) illustrated in the sub-drawings (b) of FIG. 1.
[0094] For example, the technical feature of a receiving STA receiving a control signal can be understood as a technical feature of a control signal being received by a transceiver (113, 123) illustrated in sub-drawing (a) of FIG. 1. Alternatively, the technical feature of a receiving STA receiving a control signal can be understood as a technical feature of a control signal received by a transceiver (113, 123) illustrated in sub-drawing (a) of FIG. 1 being acquired by a processor (111, 121) illustrated in sub-drawing (a) of FIG. 1. Alternatively, the technical feature of a receiving STA receiving a control signal can be understood as a technical feature of a control signal received by a transceiver (113, 123) illustrated in sub-drawing (b) of FIG. 1 being acquired by a processing chip (114, 124) illustrated in sub-drawing (b) of FIG.
[0095] Referring to the sub-drawing (b) of FIG. 1, software code (115, 125) may be included in the memory (112, 122). The software code (115, 125) may include instructions that control the operation of the processor (111, 121). The software code (115, 125) may be included in various programming languages.
[0096] The processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include an application-specific integrated circuit (ASIC), another chipset, a logic circuit, and / or a data processing device. The processor may be an application processor (AP). For example, the processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may include at least one of a digital signal processor (DSP), a central processing unit (CPU), a graphics processing unit (GPU), and a modem (modulator and demodulator). For example, the processor (111, 121) or processing chip (114, 124) illustrated in FIG. 1 may be a SNAPDRAGON® series processor manufactured by Qualcomm®, an 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 an enhanced processor thereof.
[0097] In the present disclosure, uplink may mean a link for communication from a non-AP STA to an AP STA, and uplink PPDU / packet / signal, etc. may be transmitted through the uplink. In addition, in the present disclosure, downlink may mean a link for communication from an AP STA to a non-AP STA, and downlink PPDU / packet / signal, etc. may be transmitted through the downlink.
[0098] Figure 2 is a conceptual diagram showing the structure of a wireless local area network (WLAN).
[0099] The upper part of Figure 2 shows the structure of the infrastructure BSS (basic service set) of IEEE (institute of electrical and electronic engineers) 802.11.
[0100] Referring to the top of FIG. 2, the wireless LAN system may include one or more infrastructure BSSs (200, 205) (hereinafter, BSS). The BSSs (200, 205) are a collection of APs and STAs, such as an access point (AP) 225 and a station (STA1, 200-1), that have successfully synchronized and can communicate with each other, and are not a concept that designates a specific area. The BSS (205) may also include one or more STAs (205-1, 205-2) that can be associated with one AP (230).
[0101] A BSS may include at least one STA, an AP (225, 230) providing a distribution service, and a distribution system (DS, 210) connecting multiple APs.
[0102] A distributed system (210) can connect multiple BSSs (200, 205) to implement an extended service set (ESS, 240). An ESS (240) can be used as a term to indicate a network formed by connecting one or more APs through the distributed system (210). APs included in a single ESS (240) can have the same SSID (service set identification).
[0103] The portal (portal, 220) can act as a bridge to connect a wireless LAN network (IEEE 802.11) to another network (e.g., 802.X).
[0104] In a BSS such as the upper part of Fig. 2, a network between APs (225, 230) and a network between APs (225, 230) and STAs (200-1, 205-1, 205-2) can be implemented. However, it may also be possible to establish a network and perform communication between STAs without an AP (225, 230). A network that establishes a network and performs communication between STAs without an AP (225, 230) is defined as an ad-hoc network or an independent basic service set (IBSS).
[0105] The bottom of Figure 2 is a conceptual diagram showing IBSS.
[0106] Referring to the bottom of Fig. 2, the IBSS is a BSS that operates in ad-hoc mode. Since the IBSS does not include an AP, there is no centralized management entity. That is, in the IBSS, the STAs (250-1, 250-2, 250-3, 255-4, 255-5) are managed in a distributed manner. In the IBSS, all STAs (250-1, 250-2, 250-3, 255-4, 255-5) can be mobile STAs, and access to the distributed system is not permitted, forming a self-contained network.
[0107] Figure 3 is a diagram illustrating a general link setup process.
[0108] In step S310, the STA may perform a network discovery operation. This network discovery operation may include scanning by the STA. That is, for the STA to access the network, it must find a network it can join. Before joining a wireless network, the STA must identify compatible networks. The process of identifying networks in a specific area is called scanning. Scanning methods include active scanning and passive scanning.
[0109] Figure 3 illustrates a network discovery operation that includes an active scanning process as an example. In active scanning, an STA performing scanning transmits a probe request frame to discover which APs exist in the vicinity while moving between channels and waits for a response. A responder transmits a probe response frame to the STA that transmitted the probe request frame in response to the probe request frame. Here, the responder may be the STA that last transmitted a beacon frame in the BSS of the channel being scanned. In the BSS, the AP transmits the beacon frame, so the AP becomes the responder. In the IBSS, the STAs within the IBSS take turns transmitting the beacon frame, so the responder is not constant. For example, an STA that transmits a probe request frame on channel 1 and receives a probe response frame on channel 1 can store BSS-related information included in the received probe response frame and move to the next channel (e.g., channel 2) to perform scanning (i.e., transmitting and receiving probe requests / responses on channel 2) in the same manner.
[0110] Although not shown in the example of FIG. 3, the scanning operation can also be performed in a passive scanning manner. An STA performing scanning based on passive scanning can wait for a beacon frame while moving between channels. A beacon frame is one of the management frames in IEEE 802.11. It announces the presence of a wireless network and is periodically transmitted so that the scanning STA can find the wireless network and participate in the wireless network. In the BSS, the AP periodically transmits the beacon frame, and in the IBSS, the STAs within the IBSS take turns transmitting the beacon frame. When the scanning STA receives a beacon frame, it stores the information about the BSS included in the beacon frame and moves to another channel, recording the beacon frame information on each channel. An STA that receives a beacon frame can store the BSS-related information included in the received beacon frame, move to the next channel, and perform scanning on the next channel in the same manner.
[0111] An STA that discovers a network can perform an authentication process through step S320. This authentication process may be referred to as the first authentication process to clearly distinguish it from the security setup operation of step S340 described below. The authentication process of S320 may include a process in which the STA transmits an authentication request frame to the AP, and the AP responds by transmitting an authentication response frame to the STA. The authentication frame used for the authentication request / response corresponds to a management frame.
[0112] The authentication frame may include information such as an authentication algorithm number, an authentication transaction sequence number, a status code, a challenge text, a Robust Security Network (RSN), and a Finite Cyclic Group.
[0113] An STA can transmit an authentication request frame to an AP. The AP can determine whether to grant authentication to the STA based on the information contained in the received authentication request frame. The AP can provide the result of the authentication process to the STA via an authentication response frame.
[0114] A successfully authenticated STA may perform an association process based on step S330. The association process includes a process in which the STA transmits an association request frame to the AP, and the AP transmits an association response frame to the STA in response. For example, the association request frame may include information related to various capabilities, such as a beacon listen interval, a service set identifier (SSID), supported rates, supported channels, RSN, mobility domain, supported operating classes, a Traffic Indication Map Broadcast request, and interworking service capabilities. For example, the association response frame may contain information related to various capabilities, status codes, Association ID (AID), supported rates, Enhanced Distributed Channel Access (EDCA) parameter sets, Received Channel Power Indicator (RCPI), Received Signal to Noise Indicator (RSNI), mobility domains, timeout interval (association comeback time), overlapping BSS scan parameters, TIM broadcast response, QoS maps, etc.
[0115] In step S340, the STA may perform a security setup process. The security setup process of step S340 may include, for example, a process of setting up a private key through a four-way handshaking using an Extensible Authentication Protocol over LAN (EAPOL) frame.
[0116] Below, the multi-link (ML) is explained.
[0117] Terms related to multi-links can be defined as follows:
[0118] - A multi-link device (MLD) can support multiple affiliated STAs, can operate using one or more affiliated STAs, and can mean a logical entity that provides one MAC data service and a single MAC service access point (SAP) to the logical link control (LLC) lower layer;
[0119] - Multi-link operation (MLO) may refer to operations such as discovery, authentication, multi-link setup, and frame exchange between two MLDs;
[0120] - A linked STA is an STA that provides link-specific lower MAC and PHY services within the MLD, and may be an AP (access point) STA or a non-AP (non-access point) STA;
[0121] - AP MLD is an MLD in which each STA associated with it is an AP;
[0122] - A non-AP MLD is an MLD in which each STA associated with it is a non-AP STA;
[0123] - The associated AP is an AP STA associated with an AP MLD;
[0124] - A linked non-AP STA is a non-AP STA linked to a non-AP MLD.
[0125] Figure 4 illustrates an example of multiple links.
[0126] As illustrated in FIG. 4, multiple MLDs (multi-link devices) can communicate via multiple links. The MLDs can be categorized into AP MLDs including multiple AP STAs and non-AP MLDs including multiple non-AP STAs. That is, the AP MLD can include affiliated APs (i.e., AP STAs), and the non-AP MLD can include affiliated STAs (i.e., non-AP STAs, or user-STAs).
[0127] A multilink may include a first link and a second link, and different channels / subchannels / frequency resources may be allocated to the first and second links. The first and second multilinks may be identified through a link ID of 4 bits (or other n bits). The first and second links may be configured in the same 2.4 GHz, 5 GHz, or 6 GHz band. Alternatively, the first link and the second link may be configured in different bands.
[0128] The AP MLD of FIG. 4 includes three affiliated APs. In the example of FIG. 4, AP1 may operate in the 2.4 GHz band, AP2 may operate in the 5 GHz band, and AP3 may operate in the 6 GHz band. In the example of FIG. 4, the first link in which AP1 and non-AP1 operate may be defined as a channel / subchannel / frequency resource within the 2.4 GHz band. Furthermore, in the example of FIG. 4, the second link in which AP2 and non-AP2 operate may be defined as a channel / subchannel / frequency resource within the 5 GHz band. Furthermore, in the example of FIG. 4, the third link in which AP3 and non-AP3 operate may be defined as a channel / subchannel / frequency resource within the 6 GHz band.
[0129] In the example of FIG. 4, AP1 may initiate a multi-link setup procedure (ML setup procedure) by transmitting an Association Request frame to non-AP STA1. In the example of FIG. 4, non-AP STA1 may transmit an Association Response frame in response to the Association Request frame. Each AP (e.g., AP1 / 2 / 3) illustrated in FIG. 4 may be identical to the AP illustrated in FIG. 1 and / or FIG. 2, and each non-AP (e.g., non-AP1 / 2 / 3) illustrated in FIG. 4 may be identical to the STA (i.e., user-STA or non-AP STA) illustrated in FIG. 1 and / or FIG. 2. When ML setup is completed, an enabled link for ML communication may be determined. An STA may perform frame exchange through at least one of a plurality of links determined as an enabled link. For example, an enabled link may be used for at least one of a management frame, a control frame, and a data frame.
[0130] When one STA supports multiple Links, the transmitting and receiving devices supporting each Link can operate as one logical STA. For example, one STA supporting two Links can be represented by one Multi-Link Device (MLD) including a first STA for the first Link and a second STA for the second Link. For example, one AP supporting two Links can be represented by one AP MLD including a first AP for the first Link and a second AP for the second Link. In addition, one non-AP supporting two Links can be represented by one non-AP MLD including a first STA for the first Link and a second STA for the second Link.
[0131] Below, more specific features regarding the ML setup are described.
[0132] An MLD (AP MLD and / or non-AP MLD) can transmit information about links that the MLD can support through ML setup. The information about the links can be configured in various ways. For example, the information about the links can include at least one of 1) information about whether the MLD (or STA) supports simultaneous RX / TX operation, 2) information about the number / upper limit of uplink / downlink links supported by the MLD (or STA), 3) information about the location / band / resource of uplink / downlink links supported by the MLD (or STA), 4) information about the type of frame (management, control, data, etc.) available or preferred in at least one uplink / downlink Link, 5) information about ACK policy available or preferred in at least one uplink / downlink Link, and 6) information about a traffic identifier (TID) available or preferred in at least one uplink / downlink Link. TID is related to the priority of traffic data and is expressed as eight types of values according to the existing wireless LAN standard. That is, eight TID values can be defined corresponding to four access categories (AC) (AC_BK (background), AC_BE (best effort), AC_VI (video), AC_VO (voice)) according to the existing wireless LAN standard.
[0133] For example, all TIDs can be pre-configured to be mapped to uplink / downlink Links. Specifically, if no negotiation is performed through ML setup, all TIDs are used for ML communication. If the mapping between uplink / downlink Links and TIDs is negotiated through additional ML setup, the negotiated TID can be used for ML communication.
[0134] ML setup allows multiple links to be configured for use by the transmitting and receiving MLDs involved in ML communication, referred to as "enabled links." "Enabled links" may be referred to by various names, such as "First Link," "Second Link," "Transmit Link," and "Receive Link."
[0135] After the ML setup is complete, the MLD can update the ML setup. For example, if an update is needed regarding link information, the MLD can transmit information regarding a new link. The information regarding the new link can be transmitted based on at least one of a management frame, a control frame, and a data frame.
[0136] 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 multiple links can be defined in various ways within at least one band.
[0137] FIG. 5 illustrates a modified example of a transmitting device and / or a receiving device of the present disclosure.
[0138] The devices (e.g., AP STA, non-AP STA) illustrated in FIGS. 1 to 4 may be modified as illustrated in FIG. 5. The transceiver (530) of FIG. 5 may be identical to the transceivers (113, 123) of FIG. 1. The transceiver (530) of FIG. 5 may include a receiver and a transmitter.
[0139] The processor (510) of FIG. 5 may be identical to the processor (111, 121) of FIG. 1. Alternatively, the processor (510) of FIG. 5 may be identical to the processing chip (114, 124) of FIG. 1.
[0140] 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.
[0141] Referring to FIG. 5, a power management module (511) manages power to 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 an associated key used to identify and authenticate a subscriber in a mobile phone device, such as a mobile phone or computer.
[0142] Referring to FIG. 5, the speaker (540) can output sound-related results processed by the processor (510). The microphone (541) can receive sound-related input to be used by the processor (510).
[0143] Figure 6 illustrates an operation according to UL-MU. As illustrated, a transmitting STA (e.g., AP) can acquire a TXOP (625) by performing channel access through contending (i.e., backoff operation) and transmit a trigger frame (630). That is, the transmitting STA (e.g., AP) can transmit a PPDU including a trigger frame (630). When a PPDU including a trigger frame is received, a TB (trigger-based) PPDU is transmitted after a delay equal to a short interframe space (SIFS).
[0144] TB PPDUs (641, 642) are transmitted at the same time and can be transmitted from multiple STAs (e.g., User STAs) whose AIDs are indicated in the Trigger frame (630). The ACK frame (650) for the TB PPDU can be implemented in various forms. For example, the ACK frame (650) for the TB PPDU can be implemented in the form of a BA (block ACK).
[0145] In FIG. 6, transmission(s) of a Trigger Frame (630), a TB PPDU (641, 642) and / or an ACK frame (650) can be performed within a TXOP (625).
[0146] Below, the structure and types / subtypes of MAC frames are described.
[0147] Fig. 7 illustrates an example of a header of a MAC frame. As illustrated, the MAC frame may include a frame control field / information of 2 octets in length, a duration field / information of 2 octets in length, a Receiver Address (RA) field / information of 6 octets in length, and a Transmitter Address (TA) field / information of 6 octets in length. As illustrated in Fig. 7, the four fields may be consecutive to each other. 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.
[0148] The MAC header illustrated in Fig. 7 may be positioned at the very front of a MAC frame. That is, the MAC frame may include a MAC header as illustrated in Fig. 7 and MAC body fields / information consecutive to the MAC header. The MAC frame including the MAC header of Fig. 7 is inserted / included in the data field of a PPDU (e.g., UHR PPDU).
[0149] The MAC frames included in the data field of the PPDU of the present disclosure can be classified into various types. For example, the MAC frames of the present disclosure can be classified into a control frame, a management frame, and a data frame.
[0150] For example, the management frame includes Association Request, Association Response, Reassociation Request, Reassociation Response, Probe Request, Probe Response, Beacon, Disassociation, Authentication, and Deauthentication frames / signals defined in conventional WLAN. For the management frame, the values of the type fields (B3 and B2) of the MAC header are set to 00. In addition, the values of the subtype fields (B7, B6, B5, B4) of the MAC header are as follows: Association Request (0000), Association Response (0001), Reassociation Request (0010), Reassociation Response (0011), Probe Request (0100), Probe Response (0101), Beacon (1000), Disassociation (1010), Authentication (1011), Deauthentication (1100).
[0151] For example, the control frame includes Trigger Beamforming Report Poll, NDP Announcement (NDPA), Control Frame Extension, Control Wrapper, Block Ack Request (BlockAckReq), Block Ack (BlockAck), PS-Poll, RTS, CTS, Ack, and CF-End frames / signals defined in conventional WLAN. For the control frame, the value of the type field (B3 and B2) of the MAC header is set to 01. Additionally, 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).
[0152] For example, the data frame includes (QoS) Data, (QoS) Null, etc. defined in conventional WLAN. For the data frame, the value of the type field (B3 and B2) of the MAC header is set to 10.
[0153] Figure 8 shows an over-the-air (OTA) FT protocol in a Robust Security Network (RSN).
[0154] Currently, in 802.11, when a non-AP STA moves from an AP (Old AP) to another AP (New AP), i.e., a Basic Service Set (BSS) transition occurs, it must go through a reassociation process in the same mobility area. A representative example is the Fast BSS Transition (FT) technology. In FT, as shown in Figure 8, several processes are performed, including authentication and reassociation between the FT Originator (FTO) and the Target FT Responder (FTR) (i.e., the New AP).
[0155] After this process, many operational parameters such as Agreement, Sequence Number (SN), EDCAF Parameter, etc. related to BlockAck (BA), Stream Classification Service (SCS), etc. are reset. Accordingly, there is an overhead of having to perform agreement / configuration again along with multiple frame exchanges, and data loss may also occur during the FT process. In addition, from the perspective of a Non-AP STA, seamless movement is not easy. Therefore, the present disclosure proposes a continuous roaming method utilizing an AP Multi-Link Device (MLD) to solve this problem. Unlike FT, roaming does not require the authentication / association process to be performed again.
[0156] In the present disclosure, a non-AP MLD / STA can roam from a serving / source AP MLD to another AP MLD (i.e., a target AP MLD). Alternatively, the non-AP MLD / STA can roam from at least one AP of the serving / source AP MLD to at least one AP of another AP MLD (i.e., a target AP MLD). In this case, the non-AP MLD / STA can remain connected and authenticated during and after roaming to another AP MLD. The roaming can include an operation of establishing a link with at least one AP of the target AP MLD and / or an operation of releasing a link with at least one AP of the serving / source AP MLD. For example, the non-AP MLD / STA can release a link with at least one AP of the serving / source AP MLD after establishing a link with at least one AP of the target AP MLD. As another example, a non-AP MLD / STA may establish a link with at least one AP in a target AP MLD after releasing a link with at least one AP in a serving / source AP MLD.
[0157] In this disclosure, an STA performing a BSS transition (e.g., roaming) is referred to as an RSTA, the AP to which the STA is currently connected when roaming is referred to as an Old AP (O_AP), and the AP to which the STA will roam is referred to as a New AP (N_AP). In addition, the roaming method proposed in this disclosure is referred to as MLD roaming. The designations (names) in this disclosure may be changed, and an STA may include an AP STA and / or a non-AP STA.
[0158] Figure 9 shows the high-level architecture of AP MLD.
[0159] Referring to Figure 9, the AP MLD can include at least one AP. The MLD can control various procedures / parameters common to multiple APs using the upper MAC layer / sublayer. For example, the MLD can perform / control authentication, association, SN (sequence number) / PN (packet number) allocation, and power-saving buffering of individually addressed frames.
[0160] Therefore, when the AP MLD function is used, MLD-level parameters can be maintained without being reset when a non-AP MLD / STA moves / roams between APs associated with the AP MLD. In this disclosure, a roaming method utilizing the functionality of the AP MLD is proposed.
[0161] Figure 10 shows an example of a high-level architecture for a UHR AP MLD.
[0162] In Figure 10, APs can support continuous roaming. To support continuous roaming, APs must be compatible with devices based on previous standard versions and enable continuous roaming among multiple 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 MLD definitions must not be violated, and the existing architecture must not be modified. Therefore, as shown in Figure 10, a UHR AP MLD can be defined that maintains the existing MLD architecture while hierarchically linking MLDs capable of continuous roaming. 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. This architecture can also address scalability issues caused by the limitations of the bit size of the link ID. By default, 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 existing method limits the number of APs that can be roamed to 16. To address this issue, link IDs are grouped by AP MLD IDs, thereby addressing the scalability issue.
[0163] Figure 11 shows another example of the upper layer architecture for UHR AP MLD.
[0164] Figure 11 shows an example with a similar architecture to Figure 10, but with different interfacing. Figure 11 shows that the LMAC of the AP MLD and the UHR UMAC are not directly connected, but rather are interfaced to the TID-to-Link mapping function among the functions of the UMAC. This architecture allows for the TID-to-Link mapping to be performed individually in the UMAC of the AP MLD or in the UHR UMAC. The way this architecture is utilized and the types and number of functions interfaced with the UHR UMAC are not limited.
[0165] The deployment of AP MLDs for roaming is shown in Figure 12.
[0166] Figure 12 shows the arrangement of AP MLDs for roaming.
[0167] Referring to Fig. 12, each AP MLD is located in a different location, i.e., non-collocated, and the APs belonging to / associated with each AP MLD are located in the same or similar locations, i.e., collocated. The collocated APs may mean that the APs belong to the exact same physical device, or may not belong to the exact same physical device but are located in a similar logical location. Basically, since the AP MLD is a logical entity, it can be any physical device, but it can operate as an MLD that covers the associated APs regardless of their locations and can apply MLO. Ultimately, all APs belonging to each AP MLD can be associated APs of a group-managing AP MLD. For example, AP MLD 1 in Fig. 12 may include associated APs 1, AP2, and AP3.
[0168] In the present disclosure, AP MLDs including APs associated with a group management AP MLD may be included in a roaming group, and roaming may be performed between AP MLDs / APs included in the roaming group. In other words, roaming between AP MLDs included in a roaming group is possible, but roaming between an AP MLD included in a roaming group and an AP MLD not included in the roaming group may not be possible. An AP MLD included in a roaming group may be referred to as a group member AP MLD. For example, in FIG. 12, AP MLD 1, AP MLD 2, and AP MLD 3 may be group member AP MLDs.
[0169] When a non-AP MLD / STA moves, the non-AP MLD / STA can roam from one AP MLD to another. For example, if a non-AP MLD has a multi-link configuration with an AP MLD, and STA 1 and STA 2 are connected to AP 2 and AP 3 of AP MLD 1, and roaming to AP MLD 2 occurs, STA 1 may be connected to AP 4 and STA 2 may be connected to AP 5. In this case, each STA may temporarily establish connections with AP 4 and AP 5 so that AP 4 and AP 5 can transmit frames to each STA during the roaming process.
[0170] In FIG. 12, a non-AP MLD is illustrated as a non-AP MLD with multiple associated STAs, but this architecture can also be applied to a non-AP MLD with one associated STA or a non-AP STA that is not an MLD.
[0171] In this disclosure, roaming is not necessarily limited to movement between different AP MLDs. For example, a non-AP MLD / STA can change APs through roaming even within an AP MLD.
[0172] A UHR AP MLD (or group-managed AP MLD) associates at least one (EHT) AP MLD, each of which is non-collocated, and the APs within each AP MLD are collocated. A non-AP MLD (or STA) can roam from one AP MLD to another. An STA can change APs by roaming within a specific AP MLD.
[0173] When changing APs within an AP MLD, roaming can be considered as a way to change links while maintaining the multi-link configuration without breaking the existing multi-link configuration.
[0174] For roaming, a) broadcasting procedures and b) frame exchange can be performed.
[0175] a) Broadcast procedure: Broadcast information related to roaming APs within the AP MLD to STAs, including information indicating whether each AP in the AP MLD can perform MLD roaming as proposed in this disclosure.
[0176] b) Frame Exchange Procedure: This is the 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 operation with the N_AP is performed, no longer with the O_AP.
[0177] In the present disclosure, the following methods may be used for MLD roaming:
[0178] - One or more STAs belonging to a non-AP MLD can establish multiple links, each with a wireless transceiver. Therefore, a method for a single STA to add and delete links can be used. Consequently, two or more links can be established for a single STA.
[0179] - However, since frame exchange is performed only on one link and frame exchange is not possible on the remaining links, the remaining links may be in an idle (doze) or disabled state.
[0180] - A non-AP MLD can indicate whether it has 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 can be included in the MLD Capabilities and Operations subfield of the common information field if possible for all STAs, or in the link information field if possible for only some STAs. For example, "Single-radio ML setup enabled" can be included. "Single-radio ML setup enabled" means that STAs of a non-AP MLD can establish multiple links, each with one radio transceiver. Therefore, it means that more than two links can be connected to one STA.
[0181] Broadcast for MLD roaming
[0182] Each AP in each AP MLD can broadcast information regarding whether roaming as proposed in this disclosure is possible (e.g., whether frame exchange is possible). The relevant information may include at least one of the following:
[0183] - UHR MLD MAC address (or MAC address for roaming group): MAC address commonly used by AP MLDs included in the roaming group.
[0184] - MLD roaming enabled: Indicator of whether roaming is enabled (can be indicated by 1 bit, for example).
[0185] - UHR AP MLD ID (or Roaming Group ID, Group ID): An ID that identifies a group of APs (i.e., a roaming group) that can be used for MLD roaming. The settings for this group ID are as follows:
[0186] A. Setting up ID for roaming in AP MLD
[0187] Basically, an ID can be assigned to a UHR AP MLD (or group management AP MLD) that links collocated AP MLDs. In the present disclosure, this is referred to as a UHR AP MLD ID (or group management AP MLD ID / roaming group ID / group ID). This UHR AP MLD ID can be unique within a UHR AP MLD / roaming group or can be an ID that is unique to the UHR AP MLD / roaming group within the entire network. By defining a UHR AP MLD ID / group ID to distinguish the UHR AP MLD / roaming group, it can solve the scalability problem caused by the limited number of links and help identify more APs.
[0188] A-1) Set a unique ID within the UHR AP MLD on the network
[0189] This section proposes a method for ensuring that UHR AP MLD IDs are unique within a network. UHR AP MLD IDs can typically have values such as 0, 1, 2, etc. For example, a 4-bit UHR AP MLD ID can have values from 0 to 15, while an 8-bit UHR AP MLD ID can have values from 0 to 127. The bit sizes can be customized. The following explains the meaning of each UHR AP MLD ID / group ID:
[0190] 1) When UHR AP MLD ID / Group ID is 0: In this case, it can be known that the APs with this UHR AP MLD ID / Group ID correspond to the APs belonging to the AP MLD within the same UHR AP MLD / roaming group. That is, when a non-AP MLD (or STA) recognizes this, it can recognize that the APs currently belong to the same UHR AP MLD / roaming group. Therefore, roaming is possible only when the UHR AP MLD ID / Group ID is 0. In addition, since other APs (transmitted BSSID (TxBSSID) or nontransmitted BSSID (NonTxBSSID)) of the multi-BSSID set to which each AP belonging to this UHR AP MLD / roaming group belongs also use the same physical resources, this UHR AP MLD ID / Group ID is assigned to them. However, the AP MLD ID of the AP MLD to which these APs belong (transmitted BSSID (TxBSSID) or nontransmitted BSSID (NonTxBSSID)) may be different.
[0191] Other UHR AP MLD IDs / Group IDs are mapped to uniquely identify each UHR AP MLD / Roaming Group.
[0192] A-2) Setting a unique ID within the AP MLD
[0193] This section proposes a method to assign unique IDs to APs that can roam within the entire UHR AP MLD / group.
[0194] - Temporary Link Add / Remove: Indicates whether a link can be temporarily added or removed for an STA. This means that one STA can have more than one link for a certain period of time (e.g., indicated by bit 1).
[0195] - Collocation enabled: Indicates whether AP MLDs are collocated (e.g., indicated by 1 bit)
[0196] For example, if Collocation enabled = 1, it means that the AP and the reporting AP are physically close. Therefore, since you can communicate with the existing connected AP without moving to the AP set to 1, you can avoid roaming if the neighboring AP has Collocation enabled set to 1. In other words, MLD roaming requests / responses are not sent or received to APs with Collocation enabled = 1.
[0197] Collocation ID: An ID that distinguishes collocated AP MLDs. The settings for this Collocation ID are as follows:
[0198] B. Setting Collocation ID for Roaming in UHR AP MLD / Group
[0199] Basically, an ID can be assigned to collocated AP MLDs. In this disclosure, this is referred to as a collocation ID. This collocation ID can be unique within a set of collocated AP MLDs, or can be a unique ID for collocated AP MLDs within a UHR AP MLD / roaming group.
[0200] B-1. Setting a Unique Collocation ID within the Collocation Set in UHR AP MLD
[0201] This section proposes a method for ensuring that collocation IDs are unique within a collocated AP MLD set. Collocation IDs can typically have values such as 0, 1, 2, etc. For example, a 4-bit collocation ID can have values from 0 to 15, while an 8-bit collocation ID can have values from 0 to 127, and the bit size can be changed. The following explains the meaning of each collocation ID:
[0202] When Collocation ID is 0: In this case, APs with this Collocation ID can be considered as APs belonging to the same collocated AP MLD set. That is, if the MLD (or STA) recognizes this, it can recognize that the APs are currently collocated. In addition, other APs (transmitted BSSID (TxBSSID) or nontransmitted BSSID (NonTxBSSID)) of the multi-BSSID set to which each AP belonging to this set belongs are also assigned this Collocation ID because they 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.
[0203] Multiple AP MLDs can be included within a set of APs with the same Collocation ID.
[0204] Other Collocation IDs can be mapped so that each Collocated AP MLD set can be uniquely identified.
[0205] B-2) Setting a unique collocation ID within the UHR AP MLD / roaming group
[0206] This section proposes a method for assigning a unique collocation ID within a collocated AP MLD set within a UHR AP MLD / roaming group. Collocation IDs can be assigned values of 0, 1, 2, etc. For example, a 4-bit collocation ID can have a value between 0 and 15, while an 8-bit collocation ID can have a value between 0 and 127, and the bit size can be changed.
[0207] The above information (e.g., UHR MLD MAC address (or MAC address for 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, and / 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 MLD roaming IEs containing new MLD roaming information or in existing Reduced Neighbor Report (RNR) IEs (Information Elements).
[0208] The following is an example of a case where MLD roaming parameters are included in the RNR IE. Basically, MLD roaming parameters may be included in the TBTT information field for each AP. The MLD roaming parameters may include at least one of the fields shown in FIGS. 13 and 14 , and the arrangement of the fields may be as shown in FIGS. 13 and 14 . Furthermore, in addition to the fields shown in FIGS. 13 and 14 , at least one of the fields defined in the present disclosure may be included.
[0209] Figure 13 shows an example for RNR IE.
[0210] Non-AP STAs send and receive MLD roaming requests / responses only to APs with Collocation Enabled = 0 via RNR IE.
[0211] Figure 14 shows another example for the RNR IE.
[0212] Non-AP STAs send and receive MLD roaming requests / responses only to APs whose Collocation ID is not 0 via RNR IE.
[0213] If the size of the existing MLD parameter subfield is not sufficient, as shown in FIGS. 13 and 14, a new MLD roaming parameter subfield can be created in the RNR IE to contain information. Changing the size of the existing MLD parameter subfield is also possible, but this has the problem that it may cause decoding issues for 802.11be STAs. In this case, the MLD roaming parameter subfield may not include MLD roaming Enabled, since including the MLD roaming parameter itself may imply that MLD roaming is possible.
[0214] The RNR IE can indicate only whether another AP is collocated or non-collocated with the AP currently sending a beacon or probe response by including a Collocation Enabled field as shown in FIG. 13, which can reduce overhead. Furthermore, it can also indicate which AP is included in which collocation set by indicating the AP's Collocation ID as shown in FIG. 14. The RNR IE can include at least one of the Collocation Enabled field and the Collocation ID.
[0215] Figure 15 shows another example for the RNR IE.
[0216] When only MLD roaming availability (i.e., MLD roaming enabled) is included, as in FIG. 15, MLD roaming Enabled can be indicated using the existing MLD parameter subfield. Other information can be included in a separate parameter (e.g., MLD roaming parameter), as in FIG. 13 or FIG. 14.
[0217] Below, a method for recommending AP(s) to roam to for continuous roaming and a method for signaling related information are described.
[0218] FIG. 16 illustrates an example of a transmission and reception process performed by an AP and a STA according to an embodiment of the present disclosure.
[0219] Referring to Figure 16, the transmission and reception process of the AP is as follows:
[0220] An O_AP may transmit a beacon to an STA containing information about other APs and / or a list of APs to which roaming is proposed. The O_AP may receive an MLD roaming request frame from an STA and determine the ID of the AP to which the STA will roam through the link ID and / or the AP MLD ID. The O_AP may additionally determine the UHR AP MLD ID if the UHR AP MLD ID is included. The O_AP may transmit an MLD roaming response frame to the STA, indicating whether roaming is accepted and including various IEs described in the present disclosure.
[0221] Referring to Figure 16, the STA transmission and reception process is as follows:
[0222] An STA may receive a beacon from an O_AP that includes information about other APs and / or a list of APs to which roaming is proposed. The STA may determine an AP to which to roam based on the information about the APs to which roaming is proposed received from the O_AP. The STA may transmit a roaming request frame to the O_AP that includes information about the AP to which to roam and various IEs described in the present disclosure. The STA may receive a roaming response frame from the O_AP, and if roaming is accepted, the STA may roam to an N_AP.
[0223] A non-AP MLD / STA may request information about APs to which it wishes to roam (or APs to which roaming is proposed) through an ML Probe Request frame, based on the MLD Roaming Enabled of the RNR IE received through the management frame, among enabled APs (or APs capable of roaming). In response to the ML Probe Request frame, the AP MLD / STA may inform the non-AP MLD / STA of information about whether the AP is suitable for roaming (or a list of APs to which roaming is proposed) through an ML Probe Response frame and / or a link reconfiguration notify frame. When transmitting an ML Probe Request frame to roam to the corresponding AP, ML Roaming Enabled may be set to 1.
[0224] (1) ML probe request frame format for AP proposal
[0225] For probe requests that are not related to roaming, an AP roaming suggestion enabled field (or simply roaming suggestion enabled field) may be added to the ML probe request frame to reduce the overhead that may occur if the AP makes unnecessary AP suggestions.
[0226] 1) When the roaming suggestion field is included in the common information field.
[0227] FIG. 17 illustrates an example of the structure of an ML probe request frame when the common information field includes a roaming suggestion possible field according to an embodiment of the present disclosure.
[0228] Referring to FIG. 17, the presence bitmap subfield of the probe request ML IE may indicate whether the common information field of the probe request ML IE includes an AP Roaming Suggestion Possible field. If the AP Roaming Suggestion Possible field is included in the common information field, information about all APs to which the probe request frame is transmitted may be requested for roaming. That is, if at least one AP is included in the ML probe request frame for another operation, such as a non-roaming connection, the AP Roaming Suggestion Possible field is not added to the common information field.
[0229] When a non-AP STA transmits a list of APs to which it can roam before roaming, the non-AP STA can set a roaming reason code to inform the AP of the reason / reason for which the non-AP STA is performing roaming. At this time, by adding the Probe Request ML IE / Roaming Reason Code to the Link Reset Notification Request frame, the AP can refer to the roaming reason code when determining which APs to propose to the non-AP.
[0230] If a roaming reason code is present in the link reset notification request frame, the roaming reason code may not be included in the probe request ML IE. If the reason for requesting roaming is the same for all links, the roaming reason code can be included in the common information field to reduce overhead. The roaming reason code settings are described in below.
[0231] 2) When the roaming suggestion possible field is included in the link information field.
[0232] FIG. 18 illustrates an example of the structure of an ML probe request frame when the link information field includes a roaming suggestion possible field according to an embodiment of the present disclosure.
[0233] Referring to Figure 18, if the Roaming Proposal Capability field is included in the Link Information field, information about APs can be individually requested for roaming. If at least one AP is included in the ML Probe Request frame to perform a connection-like operation rather than roaming, the AP Roaming Proposal Capability field may be added to the Link Information field.
[0234] (2) ML probe response frame format for AP proposal
[0235] A non-AP MLD / STA can request information about APs it wants to roam with (or APs that can be proposed for roaming) through an ML Probe Request frame for APs that are enabled based on MLD roaming enabled (or APs that can be roamed). In response to the ML Probe Request frame, the AP MLD / STA can inform the non-AP MLD / STA of information about whether the AP is suitable for roaming (or a list of APs proposed for roaming) through an ML Probe Response frame.
[0236] For example, the ML probe response frame may include a list of APs suitable for roaming (or APs to which roaming is proposed) (e.g., a Recommended AP list). The list of APs suitable for roaming (or APs to which roaming is proposed) may include a list of link IDs associated with the APs suitable for roaming (or APs to which roaming is proposed).
[0237] Meanwhile, the AP proposal may be based on a link reset notification (request) frame.
[0238] FIG. 19 illustrates an example of a method performed by a STA for AP proposal based on a link re-establishment notification frame according to an embodiment of the present disclosure.
[0239] Referring to FIG. 19, in step S1901, the STA may perform a connection procedure with an AP (e.g., UHR AP MLD).
[0240] In step S1903, the STA may receive a link reconfiguration notify frame from the AP, which includes a list of links for which link modification is recommended for roaming. Each link in the list of links for which link modification is recommended may be associated with a corresponding AP in the roaming group.
[0241] In step S1905, the STA may transmit a roaming request frame to the AP to request link modification of at least one link from a list of links for which link modification is proposed.
[0242] In step S1907, based on receiving a roaming response frame for a roaming request frame, the STA may perform link modification of at least one link.
[0243] In step S1909, based on link modification of at least one link, the STA can perform roaming from a first AP included in the roaming group to a second AP included in the roaming group.
[0244] According to various embodiments, link modification of at least one link may include at least one of link deletion of a link associated with a first AP or link addition of a link associated with a second AP.
[0245] According to various embodiments, information about the list of links for which link modification is proposed may be included in a reset ML (multi-link) information element (IE) of a link reset notification frame.
[0246] According to various embodiments, the ML IE may include one or more STA profiles. Each of the one or more STA profiles may indicate whether link modification of the corresponding link is proposed. The list of links for which link modification is proposed may include links corresponding to STA profiles that indicate that link modification is proposed.
[0247] According to various embodiments, in the reset ML IE, each STA profile may be positioned in the order in which link modifications are proposed, such that the STA profile corresponding to the link for which link modification is most proposed is positioned first.
[0248] According to various embodiments, the reset ML IE may include a list of modified link IDs. The list of modified link IDs may include the link ID of each link in the list of links for which link modification is proposed.
[0249] According to various embodiments, each link ID in the list of modified link IDs may be listed in the order in which link modifications are proposed, such that the link ID corresponding to the link for which link modification is most proposed is listed first.
[0250] According to various embodiments, the list of links for which link modification is proposed may include links associated with at least one AP associated with a first AP multi-link device (MLD) and links associated with at least one AP associated with a second AP MLD that is different from the first AP MLD. The reset ML IE may include a common information field for the first AP MLD and a subsequent common information field for the second AP MLD after the common information field.
[0251] According to various embodiments, the STA information field for at least one AP associated with the first AP MLD in the reset ML IE may include a Last Per-STA Info field indicating whether there is a subsequent common information field for the second AP MLD after the STA information field.
[0252] According to various embodiments, the common information field for the first AP MLD in the reset ML IE may include at least one of a number of per-STA profiles field indicating whether a subsequent common information field for the second AP MLD exists, or a more common info field.
[0253] According to various embodiments, before receiving a link reset notification frame, the STA may transmit a link reset notification request frame to the AP. The link reset notification frame may be a response frame to the link reset notification request frame.
[0254] According to various embodiments, the link reset notification request frame may include a list of links for which the STA proposes link modification.
[0255] According to various embodiments, at least one of the link reset notification frame or the link reset notification request frame may include a roaming reason code indicating the reason for requesting link modification for roaming.
[0256] According to various embodiments, the list of links for which link modification is proposed may be determined based on a roaming cause code.
[0257] FIG. 20 illustrates an example of a method performed by an AP for AP proposal based on a link reset notification frame according to an embodiment of the present disclosure.
[0258] Referring to FIG. 20, in step S2001, the AP can perform a connection procedure with a STA (station).
[0259] In step S2003, the AP may transmit a link reconfiguration notify frame to the STA, which includes a list of links for which link modification is recommended for roaming. Each link in the list of links for which link modification is recommended may be associated with a corresponding AP in the roaming group.
[0260] In step S2005, the AP may receive a roaming request frame from the STA to request link modification of at least one link from a list of links for which link modification is proposed.
[0261] In step S2007, the AP may transmit a roaming response frame to the STA for link modification of at least one link. Based on the link modification of at least one link, roaming of the STA may be performed from a first AP included in the roaming group to a second AP included in the roaming group.
[0262] FIG. 21 illustrates an example of a transmission and reception process performed by an AP and a STA for an AP proposal based on a link re-establishment notification frame according to an embodiment of the present disclosure.
[0263] Referring to Figure 21, the transmission and reception process of the AP is as follows:
[0264] An AP (e.g., an AP included in a UHR AP MLD) can transmit a link reconfiguration notification frame to an STA (e.g., an STA included in a non-AP MLD). Depending on the type of reconfiguration operation, the AP can receive a reset request from an STA via a roaming request frame, or transmit a reset request to an STA via a roaming request frame, to delete / add the corresponding link. When an AP (e.g., an AP included in a UHR AP MLD) receives a reset request from an STA (e.g., an STA included in a non-AP MLD) via a roaming request frame, the roaming request frame may request deletion of at least one of the links corresponding to deletion among the links included in the link reconfiguration notification frame, and / or request addition of at least one of the links corresponding to addition. When an AP (e.g., an AP included in a UHR AP MLD) transmits a reset request to an STA (e.g., an STA included in a non-AP MLD) via a roaming request frame, the link reconfiguration notification frame may be omitted.
[0265] Referring to Figure 21, the STA transmission and reception process is as follows:
[0266] An STA (e.g., an STA included in a non-AP MLD) may receive a link reconfiguration notification frame from an AP (e.g., an AP included in a UHR AP MLD). Depending on the type of reconfiguration operation, the STA may transmit a reconfiguration request to the AP via a roaming request frame, or may receive a reconfiguration request from the AP via a roaming request frame to delete / add the corresponding link. When an STA (e.g., an STA included in a non-AP MLD) transmits a reconfiguration request to an AP (e.g., an AP included in a UHR AP MLD) via a roaming request frame, the roaming request frame may request deletion of at least one of the links corresponding to deletion among the links included in the link reconfiguration notification frame, and / or request addition of at least one of the links corresponding to addition. When an STA (e.g., an STA included in a non-AP MLD) receives a reconfiguration request from an AP (e.g., an AP included in a UHR AP MLD) via a roaming request frame, the link reconfiguration notification frame may be omitted.
[0267] Below, a detailed implementation of AP proposal based on the link reset notification (request) frame is described.
[0268] (1) Link reset notification request frame for AP proposal
[0269] Non-AP MLDs can individually transmit Link Reset Notification Request frames to UHR AP MLDs without waiting to receive a Link Reset Notification frame for AP Proposal from the UHR AP MLD.
[0270] The format of the link reset notification request frame action field is as shown in below:
[0271] Order Meaning 1 Category 2 Protected UHR Action 3 Dialog Token 4 Reset (or, probe request) ML IE
[0272] When sending a link reset notification request frame, the reason for requesting roaming can be indicated using a roaming reason code. The roaming reason code settings are described in below.
[0273] Roaming Cause Value Description 0 Undefined 1 Excessive frame loss rate and / or poor quality conditions 2 Excessive delay for the current traffic stream 3 Insufficient QoS capacity for the current traffic stream 4 Finding a better link 5 Finding a better AP 6 Excessive replay counter failures 7 Excessive data MIC failures 8 Maximum retransmissions exceeded 9 Excessive broadcast disassociations 10 Excessive broadcast deauthentications 11 Previous roaming failed 12 Low RSSI 13 Switching due to received roaming request frame 14 Preferred roaming offer list included 15 - 255 Reserved
[0274] The values and descriptions in are subject to change. When a non-AP STA informs the AP of the reason for roaming in this way, the AP can suggest more suitable AP(s) to the non-AP STA. If the roaming reason code is included in the probe request ML IE, the roaming reason code may not be included in the link re-establishment notification request frame. Also, if the reason for roaming varies for each link, the roaming reason code may not be included in the link re-establishment notification request frame.
[0275] (2) Link reset notification frame for AP proposal
[0276] A UHR AP MLD can notify a non-AP MLD of a link on which roaming is proposed using a link reconfiguration notification frame rather than an ML probe request / response frame.
[0277] The format of the Link Reset Notification Frame Action field is as shown in Table 3 below:
[0278] Sequence Meaning 1 Category 2 Protected UHR Action 3 Dialog Token 4 Reset ML IE 5 Roaming Reason Code (Optional)
[0279] Step 4: The Reset ML IE defined in 802.11be can be utilized to convey the information required for link proposal. If the Reset ML IE includes one STA profile, the STA profile can propose deletion or addition for one link. However, in this case, link modification cannot be proposed for multiple links. Therefore, to increase efficiency, the Reset ML IE can include one or more STA profile sub-elements, and one or more STA profile sub-elements can propose link modification for one or more links. In this case, the UHR AP MLD can indicate the preference of the most suitable AP for roaming among the APs to be roamed. The preference of the most suitable AP for roaming can be expressed in the order of the STA profiles (sub-elements) in the Reset ML IE, or indicated through the Add / Delete Link ID List (or Modify (e.g., Add / Delete) Link ID List) field. When the order of STA profiles (sub-elements) indicates the preference for APs suitable for roaming, the STA profile (sub-element) corresponding to the link most preferably deleted or added first may be positioned first in the reset ML IE, and then the STA profiles (sub-elements) in order of highest preference may be positioned in the reset ML IE. Similarly, when the order of STA profiles suitable for roaming is indicated through the add / delete link ID list field, the link ID corresponding to the link most preferably deleted or added first may be positioned first in the add / delete link ID list, and then the link IDs in order of highest preference may be positioned in the add / delete link ID list.Step 5: If a non-AP STA first transmits a link reset notification request frame, but the link reset notification request frame does not include a roaming cause code, or if the AP MLD (e.g., UHR AP MLD) transmits a link reset notification frame without receiving the link reset notification request frame, the AP MLD (e.g., UHR AP MLD) may transmit a link reset notification frame that includes a roaming cause code.
[0280] FIG. 22 illustrates an operation procedure when a link reset notification request frame includes a roaming cause code according to an embodiment of the present disclosure.
[0281] Referring to Figure 22, the transmission and reception process of the AP is as follows:
[0282] An AP may receive a link reconfiguration notification request frame from an STA. The AP may check the roaming cause code in the link reconfiguration notification request frame and transmit a link reconfiguration notification frame to the STA, which includes a list of APs / links proposed by the AP. In some implementations, the link reconfiguration notification frame may further include a roaming cause code. The AP may perform a roaming procedure for the STA to roam to another AP.
[0283] Referring to Figure 22, the STA transmission and reception process is as follows:
[0284] An STA can request a list of proposed APs / links by sending a link reconfiguration notification request frame to the currently connected AP. The link reconfiguration notification request frame can include a list of APs / links proposed by a non-AP STA. A roaming cause code can be set in the link reconfiguration notification request frame to inform the AP of the reason for roaming. The STA can receive a link reconfiguration notification frame from the AP, which includes a list of APs / links proposed by the AP. In some implementations, the link reconfiguration notification frame can further include a roaming cause code. The STA can perform a roaming procedure for roaming from the AP with which a link is currently established to another AP.
[0285] FIG. 23 illustrates an operation procedure when a link reset notification request frame does not include a roaming cause code according to an embodiment of the present disclosure.
[0286] Referring to Figure 23, the transmission and reception process of the AP is as follows:
[0287] The AP can receive a link reconfiguration notification request frame. The AP can transmit a link reconfiguration notification frame to the STA, including a list of APs / links proposed by the AP and a roaming reason code. The AP can perform a roaming procedure for the STA to roam to another AP.
[0288] Referring to Figure 23, the STA transmission and reception process is as follows:
[0289] An STA can request a list of proposed APs / links by sending a Link Reset Notification Request frame to the currently connected AP. The Link Reset Notification Request frame can include a list of APs / links proposed by a non-AP STA. The STA can receive a Link Reset Notification frame from the AP, which includes a list of APs / links proposed by the AP and a roaming cause code. The STA can perform a roaming procedure for roaming from the AP with which the current link is established to another AP.
[0290] FIG. 24 illustrates an operation procedure when a link reset notification request frame is not transmitted according to an embodiment of the present disclosure.
[0291] Referring to Figure 24, the transmission and reception process of the AP is as follows:
[0292] The AP may transmit a link reconfiguration notification frame to the STA, which includes a list of APs / links proposed by the AP and a roaming cause code. The AP may perform a roaming procedure for the STA to roam to another AP.
[0293] Referring to Figure 24, the STA transmission and reception process is as follows:
[0294] An STA may receive a link reconfiguration notification frame from an AP, which includes a list of APs / links proposed by the AP and a roaming cause code. The STA may perform a roaming procedure to roam from the AP with which a link is currently established to another AP.
[0295] Meanwhile, there may be more than one AP MLD to which the proposed APs are associated. Therefore, an extension of the Reset ML IE (in the Link Reset Notification Request frame / Link Reset Notification frame) may be required to carry information of two or more AP MLDs. To carry information of multiple AP MLDs, the Reset ML IE needs to include two or more common information fields. Therefore, an extension to a Reset ML IE that has a common information field containing information of a new AP MLD after the Per-STA information, rather than a format that ends after the Per-STA information, may be required. However, even if such a Reset ML IE is received, a non-AP STA can read up to the Per-STA information field. In other words, since a non-AP STA cannot read the common information field that follows the Per-STA information field, a method for indicating that a common information field exists after the Per-STA information field is required.
[0296] FIG. 25 illustrates a first example of a reset ML IE structure for indicating the presence of a common information field later, according to an embodiment of the present disclosure.
[0297] Referring to FIG. 25, the Last Per-STA information field can be used to indicate that a common information field exists after the Per-STA information field. The last field of the Per-STA information field can include the Last Per-STA information field, and the Last Per-STA information field can indicate whether a common information field exists afterward. For example, if the Last Per-STA information field is set to 1, it can mean that no common information field exists afterward, and a non-AP STA can stop decoding. As another example, if the Last Per-STA information field is set to 0, it can mean that a common information field exists afterward, and a non-AP STA can continue decoding without stopping.
[0298] FIG. 26 illustrates a second example of a reset ML IE structure for indicating the presence of a common information field later, according to an embodiment of the present disclosure.
[0299] Referring to FIG. 26, the common information field of the reset ML IE may include a Number of Per-STA Profiles field indicating the total number of Per-STA profiles following the common information field. When a non-AP STA reads the Per-STA profiles indicated by the Number of Per-STA Profiles field, it can then determine that a common information field for a new AP MLD exists. If the Number of Per-STA Profiles field does not exist, the non-AP STA recognizes that it is not a reset ML IE for an AP proposal and can stop decoding after decoding all per-STA profiles.
[0300] FIG. 27 illustrates a third example of a reset ML IE structure for indicating the presence of a common information field later, according to an embodiment of the present disclosure.
[0301] Referring to Fig. 27, the common information field of the reset ML IE may include a More common info field at the end. For example, if the More common info field is set to 1, it may indicate that there is an additional common information field after the Per-STA information / profile. Therefore, a non-AP STA may continue decoding without interruption since it may know that a new common information field exists after the decoding of the Per-STA information / profile when the More common info field is set to 1. The More common info field of Fig. 27 may also be used in the reset ML IE structure of Fig. 25 and / or the reset ML IE structure of Fig. 26.
[0302] Frame exchange for MLD roaming
[0303] For MLD roaming to be triggered, frame exchange is required between the non-AP MLD (or STA) and the AP MLD. MGMT frames can be utilized, particularly Action frames, a type of MGMT frame. Roaming-related frames can be referred to as follows:
[0304] - The frame in which the STA requests MLD roaming to the AP can be called an MLD roaming request frame.
[0305] - The frame in which the AP requests MLD roaming to the STA can be called an MLD roaming response frame.
[0306] (1) MLD roaming request frame format
[0307] The MLD roaming request frame may contain information as shown in Table 4 below:
[0308] Order Information 1 Category 2 UHR Action or Protected UHR Action 3 Dialog Token 4 Reconfiguration Multi-Link Element
[0309] Step 1: Basically, the category can be included in a new UHR Action or Protected UHR Action, but is not limited to these. Step 4: The Reset Multi-Link IE defined in the existing 802.11be can be utilized for the information required for an MLD roaming request.
[0310] In various embodiments, the reset multi-link IE may include a UHR MLD MAC address (or a MAC address for a roaming group). For example, the UHR MLD MAC address (or a MAC address for a roaming group) may be included in the common information field of the reset multi-link IE. In another example, the UHR MLD MAC address (or a MAC address for a roaming group) may be included in the link information field of the reset multi-link IE.
[0311] The common information fields and link information fields in the reset multi-link IE are as follows:
[0312] 1) Common information fields
[0313] FIG. 28 illustrates an example of a common information field of a reset multi-link IE according to an embodiment of the present disclosure.
[0314] When moving to a new AP, if one or more STAs, particularly from a non-AP MLD perspective, simultaneously perform MLD roaming, MLD capabilities and behavior or EML capabilities may change. Therefore, this information can be additionally included in the common information field. As before, the presence of subfields in the common information field can be determined from the presence bitmap.
[0315] Referring to FIG. 28, the UHR MLD MAC address (or the MAC address for the roaming group) may be included in the common information field of the reset ML IE. The present bitmap subfield of the reset ML IE may further include a subfield (e.g., UHR MAC address present) indicating whether the MAC address for the roaming group is included in the common information field of the reset ML IE.
[0316] 2) Link information field
[0317] If more than one STA performs MLD roaming simultaneously, one or more Per-STA profile subelements may be required.
[0318] FIG. 29 illustrates an example of a link information field of a reset multi-link IE according to an embodiment of the present disclosure.
[0319] Referring to Figure 29, the UHR MLD MAC address (or MAC address for the roaming group) may be included in the Per-STA profile sub-element in the link information field of the reset ML IE.
[0320] Basically, when moving to a different AP, the information about whether each link is STR (Simultaneous transmission and receive) or NSTR (non-STR) may change from a non-AP MLD perspective, so the STA information field may include an NSTR indication bitmap. Similarly, as before, the presence or absence of subfields in the STA information can be determined by the Present subfields of the STA control field.
[0321] The link ID can indicate a link ID corresponding to N_AP.
[0322] The Complete profile refers to the Complete information of the STA, i.e. all information included when transmitting a connection request frame, as before. However, since this is a case where an existing STA, not a new STA, moves, the capabilities or operating parameters of the STA may not change. Since the AP MLD already knows this, it can be used as an instruction that includes only the changed information instead of the Complete profile. For example, if the Complete profile = 0, which is a Partial profile as before, the STA profile only includes information (i.e., fields / IEs) that will change when moving to N_AP. Alternatively, the Complete profile is referred to as the Changed profile, and if this value is 1, the STA profile only includes information (i.e., fields / IEs) that will change when moving to N_AP.
[0323] The MLD roaming timer indicates the time when MLD roaming is completed and no longer operates with the O_AP, but operates with the N_AP. In other words, it can indicate the remaining time until the expected time to switch to the AP to which it will roam. This is related to the TIM field described below. If the MLD roaming timer is applied commonly to all APs, it can be included in the common information field, unlike in Fig. 29. In this case, the presence or absence of the MLD roaming timer in the common information field can be indicated through the Presence bitmap. Since this is information transmitted by the STA, it can be interpreted as a reference to the AP MLD.
[0324] In addition to the above information, the UHR AP MLD ID (or Group ID), AP MLD ID, Collocation ID and / or UHR MLD MAC address (or MAC address for roaming group) may be included in the Reset Multi-Link IE 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 non-AP MLD (or STA) will roam belong. In a situation where the AP MLD has previously confirmed the UHR AP MLD ID (or Group ID) through a beacon or probe request / response process and only sends roaming requests 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 be present in the Reset Multi-Link IE. Such cases are described in more detail below. That is, it describes the format depending on whether the reset multi-link IE will always include the UHR AP MLD ID (or group ID), AP MLD ID, Collocation ID and / or the UHR MLD MAC address (or MAC address for the roaming group).
[0325] Case 1-1) If included in the common information field
[0326] FIG. 30 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.
[0327] The Presence bitmap may indicate whether at least one of a UHR MLD MAC address (or MAC address for a roaming group), a UHR AP MLD ID, an AP MLD ID, a Collocation ID, a Roaming Proposal List (i.e., a list of APs to which roaming is proposed / a list of links to which link modification for roaming is proposed), or a roaming reason code is included. If it is included only in the Common Information field, roaming can only be requested 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 a 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 a roaming group) even within the same UHR AP MLD (or roaming group). For example, one or more STAs cannot request reconfiguration to an AP belonging to an AP MLD different from the AP MLD of the same AP. However, if roaming with the same AP MLD is common, overhead can be reduced by including each link information field as shown below.
[0328] Referring to FIG. 30, the UHR MLD MAC address (or the MAC address for the roaming group) may be included in the common information field of the reset ML IE. The present bitmap subfield of the reset ML IE may further include a subfield (e.g., UHR MAC address present) that indicates whether the MAC address for the roaming group is included in the common information field of the reset ML IE.
[0329] Case 1-2) If included in the common information field
[0330] FIG. 31 illustrates an example in which a common information field of a reset multi-link ID includes a UHR MLD MAC address and an AP MLD ID according to an embodiment of the present disclosure.
[0331] If the STA and the AP have confirmed and recognized that the UHR AP MLD (or roaming group) to which N_AP and O_AP are linked through the previous connection process is the same, there is no need to transmit the UHR AP MLD ID (or group ID), so overhead can be reduced without separately adding the UHR AP MLD ID (or group ID) field as shown in FIG. 31. The method of including fields is the same as in Case 1-1, except for whether or not the UHR AP MLD ID (or group ID) field is included.
[0332] Referring to FIG. 31, the UHR MLD MAC address (or the MAC address for the roaming group) may be included in the common information field of the reset ML IE. The present bitmap subfield of the reset ML IE may further include a subfield (e.g., UHR MAC address present) that indicates whether the MAC address for the roaming group is included in the common information field of the reset ML IE.
[0333] Case 2-1) If included in the link information field - always present
[0334] FIG. 32 illustrates an example in which a link 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.
[0335] The link information field can contain multiple Per-STA profile sub-elements, each of which can indicate a roaming request to an AP through a 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 can be used to distinguish the AP to which the STA wants to roam. This allows roaming requests to multiple APs corresponding to multiple AP MLD IDs, but when requests are made for the same AP MLD ID, the overhead is greater than when indicating in the common information field.
[0336] Referring to Figure 32, the UHR MLD MAC address (or MAC address for the roaming group) may be included in the STA control field of the Per-STA profile sub-element.
[0337] Case 2-2) If included in the link information field - always present
[0338] FIG. 33 illustrates an example in which an AP MLD ID is included in a link information field of a reset multi-link IE according to an embodiment of the present disclosure.
[0339] If the STA and the AP have confirmed and recognized that the UHR AP MLD (or roaming group) to which N_AP and O_AP are linked through the previous connection process is the same, there is no need to transmit the UHR AP MLD ID (or group ID), so overhead can be reduced without separately adding the UHR AP MLD ID (or group ID) field as shown in FIG. 33.
[0340] Additionally, the link information field of the reset multi-link IE may include a UHR MAC address (or MAC address for a roaming group) present field. The UHR MAC address (or MAC address for a roaming group) present field may indicate whether a UHR MAC address (or MAC address for a roaming group) is included.
[0341] Referring to Figure 33, the UHR MLD MAC address (or MAC address for the roaming group) may be included in the STA control field of the Per-STA profile sub-element.
[0342] Case 3-1) If included in the link information field - if it does not always exist
[0343] FIG. 34 illustrates another example in which 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.
[0344] The UHR AP MLD ID (or Group ID) Present and AP MLD ID Present of the STA Control field of the Per-STA profile sub-element can indicate whether to include the UHR AP MLD ID (or Group ID) and AP MLD ID for the AP corresponding to the link ID. The UHR AP MLD ID, AP MLD ID, roaming proposal list (i.e., list of APs proposed for roaming / list of links proposed for link modification for roaming) and / or roaming reason code can be included in the STA information field or the STA profile field. Similarly, it can request information for multiple APs corresponding to multiple AP MLD IDs. In particular, when requesting roaming for APs corresponding to the same AP MLD ID, when combined with the indication method in the common information field described above, overhead can be reduced compared to the indication method in the link information field by not including the UHR AP MLD ID (or group ID), AP MLD ID, roaming suggestion list (i.e., list of APs for which roaming is proposed / list of links for which link modification for roaming is proposed) and / or roaming cause code.
[0345] Meanwhile, if the common information indicates a UHR AP MLD ID (or group ID) and an AP MLD ID in another way, it is implicitly recognized that this is a roaming request for APs corresponding to the same UHR AP MLD ID (or group ID) and AP MLD ID, and thus the UHR AP MLD ID (or group ID), AP MLD ID, roaming proposal list (i.e., list of APs to which roaming is proposed / list of links to which link modification for roaming is proposed) and / or roaming reason code may not be included. That is, the UHR AP MLD ID (or group ID) Present field and the AP MLD ID Present field may not be included.
[0346] Referring to FIG. 34, the UHR MLD MAC address (or the 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 Per-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.
[0347] Case 3-2) If included in the link information field - if it does not always exist
[0348] FIG. 35 illustrates 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.
[0349] If the STA and the AP have confirmed and recognized that the UHR AP MLD (or roaming group) to which N_AP and O_AP are linked through the previous connection process is the same, there is no need to transmit the UHR AP MLD ID, so overhead can be reduced without separately adding the UHR AP MLD ID (or group ID) field as shown in FIG. 35.
[0350] Referring to FIG. 35, the UHR MLD MAC address (or the 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 Per-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.
[0351] Additionally, since the present disclosure includes the ability to temporarily add and delete links for MLD roaming, a method for directing this is required, and the following method can be used.
[0352] Basically, you can use 2 bits or more to indicate the (link) type, which can be Type 0: Addition / Type 1: Deletion / Type 2: Temporary Addition / Type 3: Temporary Deletion. Temporary Deletion can also be replaced with Type 1. Addition means that an STA in a non-AP MLD requests an additional link association with an AP in an AP MLD. Deletion means disconnecting (removing) the currently connected link. Temporary Addition means that an STA in a non-AP MLD requests an additional association with an AP other than the currently connected AP so that multiple links can be established.
[0353] A separate field can be configured in the Type field to indicate "temporary." For example, the Type field can indicate link addition / change, and a Temporary field can be configured to indicate temporary. Temporary additions can be configured using the values of both fields (e.g., the first field = addition, the second field = 1 (temporary)).
[0354] When requesting both deletion and addition during MLD roaming, the (link) type in the common information field can be set to 4 or 5. Type 4 indicates add then delete, while type 5 indicates delete then add. For type 4, links corresponding to addition are added first, and then links corresponding to deletion are deleted. Conversely, for type 5, links corresponding to deletion are deleted first, and then links corresponding to addition are added.
[0355] Type 6 can indicate a link switch. Link switching refers to switching a link to another link in one go, as opposed to adding or deleting.
[0356] The Add / Delete Link ID list field is an optional field that can be included when the Type field is set to 4 and 5. The link IDs in this Add / Delete Link ID list can include a list of link IDs of links that request addition and deletion at the same time. For link information (fields) with link IDs included in the Add / Delete Link ID list, if the Type field indicates addition, it can be known that it is an adding link among the links that request addition and deletion at the same time, and if it indicates deletion, it can be known that it is a deleting link.
[0357] If the type value of the common information field is 6, the add / delete link ID list may not exist.
[0358] The Type field of the Link Information field requires a value for both simultaneous addition and deletion requests, in addition to the value required for simple additions or deletions. The Type field's value can be configured as follows, but the Type field's values and settings are not limited to the values mentioned:
[0359] - Type 0: Add
[0360] - Type 1: Delete
[0361] - Type 2: Temporary addition
[0362] - Type 3: Temporary deletion
[0363] - Type 4: Add and Delete (Add)
[0364] - Type 5: Add and Delete (Delete)
[0365] - Type 6: Delete and add (add)
[0366] - Type 7: Delete and add (delete)
[0367] - Type 8: Link Switching
[0368] Type 4 is for links that are added in the action of adding and then deleting links, and type 5 is for links that are deleted.
[0369] Type 6 is for links that are added in the action of deleting and adding links, and type 7 is for links that are deleted.
[0370] The type field and the temporary field may be included as follows, and at least one more field may be included:
[0371] In some implementations, the type field and / or the temporary field may be included in the MLD Roaming Request frame body or the common information field of the Reset IE.
[0372] FIG. 36 illustrates an example in which a temporary field is included in the common information field of a reset ML IE according to an embodiment of the present disclosure.
[0373] In this case, only one action can be directed to all APs. That is, in the case of an addition instruction, a request to add links can only be made to the APs indicated by the link information field.
[0374] In some implementations, the type field and / or the temporary field may be included in the MLD roaming request frame body or the link information field of the reset IE.
[0375] FIG. 37 illustrates an example in which a temporary field is included in the link information field of a reset ML IE according to an embodiment of the present disclosure.
[0376] In this case, you can request different actions for each AP. For example, you can request temporary addition for one AP and deletion for another.
[0377] FIG. 38 illustrates another example in which a temporary field is included in the link information field of a reset ML IE according to an embodiment of the present disclosure.
[0378] Referring to Figure 38, for a link information field where the UHR AP MLD ID (or group ID) field is omitted, an example is provided where the type field is included in the link information field.
[0379] In some implementations, link addition and deletion can be requested simultaneously. For example, a new link may be added first, followed by the deletion of an existing link. In this case, the request method is as follows:
[0380] - When the common information field contains both a type field and an add / delete link ID list field.
[0381] Set the type of the common information field to 4, and add the link IDs of the newly added link and the link IDs of the deleted link to the add / delete link ID list. At this time, the link ID of the added link can be listed before the link ID of the deleted link in the list order. For example, if the link ID of the added link is 5 and the link ID of the deleted link is 2, the added / deleted link ID list can be set as 5, 2. By setting the order in this way, you can know which link is the target of addition and which link is the target of deletion in the common information field, but since this can also be known through the type field of the link information field, the action of setting the order may not be necessary.
[0382] Since the type field of the link information field already indicates whether the frame is requesting addition and deletion individually or simultaneously through the common information field, it is possible to indicate whether the link is being added or deleted using only type 0 and 1. Alternatively, if the link IDs are sequentially ordered in the add / delete link ID list of the common information, the overhead can be reduced by omitting the type field in the link information field.
[0383] - If the common information field contains only the type field.
[0384] You can set the Type field of the Common Information field to 4 and use Type 0, 1 in the Link Information field to indicate whether the link is being added or deleted.
[0385] - If the common information field does not include both the type field and the add / delete link ID list field.
[0386] In this case, you can request addition and deletion using the Type field value of the Link Information field as 4 or 5. In this case, the link being added will be set to Type 4, and the link being deleted can be set to Type 5. The link set to Type 4 is added first, and then the link set to Type 5 is deleted.
[0387] In some implementations, when link addition and deletion are requested simultaneously, the existing link may be deleted first, followed by the new link. In this case, the request method is as follows:
[0388] - When the common information field contains both a type field and an add / delete link ID list field.
[0389] Set the type of the common information field to 5, and add the link IDs of the newly added link and the link IDs of the deleted link to the add / delete link ID list. At this time, the link ID of the deleted link can be listed before the link ID of the added link in the list order. For example, if the link ID of the deleted link is 5 and the link ID of the added link is 2, the list of added / deleted link IDs can be set as 5, 2. By setting the order in this way, you can know which link is the target of addition and which link is the target of deletion in the common information field, but since this can also be known through the type field of the link information field, the action of setting the order may not be necessary.
[0390] - If the common information field contains only the type field.
[0391] You can set the type of the common information field to 5 and use the type 0, 1 in the link information field to indicate whether it is an adding link or a deleting link.
[0392] - If the common information field does not include both the type field and the add / delete link ID list field.
[0393] In this case, you can request addition and deletion by using the Type field value of the Link Information field as 6 or 7. In this case, the link being added will be set to Type 6, and the link being deleted will be set to Type 7. The link set to Type 6 is added first, and then the link set to Type 7 is deleted.
[0394] In some implementations, the type field can be used to indicate a link switch. When changing a link, if the type 6 of the common information field is used to indicate a link change instead of indicating link addition / deletion, the link transmitting the MLD roaming request frame can be switched to the link corresponding to the link ID in the link information field. In the case of a link switch, the type field can be omitted from the link information field to reduce overhead. When switching a link, the AP and the STA must know the time for which the link switch must be performed. This can be determined by the AP and notified to the STA, or determined by the STA and notified to the AP. If the AP notifies the STA, the Channel Switch Count field can be added and notified in the MLD roaming response frame, as shown in FIG. 40 or FIG. 41. If the STA determines and notifies the AP, the Delete Timer field in the Reset ML IE can be used to notify the AP through the MLD roaming request frame.
[0395] Figure 39 shows an example where the AP removal timer is included in the common information field of the reset ML IE.
[0396] Referring to FIG. 39, when the completion time of link switching is indicated using the removal timer field of the reset ML IE, if all links that requested link switching through the MLD roaming request frame have the same removal timer value, the AP removal timer (or removal timer) field may be added to the common information field instead of the link information field to reduce overhead. In this case, the AP removal timer (or removal timer) field may not be used based on the AP removal timer present (or removal timer present) field included in the link information field or the present bitmap subfield of the reset ML IE.
[0397] If the removal timer values of the links for which link switching is requested are different, an AP removal timer (or deletion timer) field may be added to the link information field instead of the common information field. If there is only one link to be switched, an AP removal timer (or deletion timer) field may be added to the common information field, or an AP removal timer (or deletion timer) field may be added to the user information field / link information field.
[0398] (2) MLD roaming response frame format
[0399] In the MLD roaming response frame, it is necessary to consider the link level parameters that must be provided because the link must be changed while maintaining the multi-link configuration.
[0400] Sequence 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)
[0401] Step 1: Basically, the category can be included in a new UHR Action or a Protected UHR Action, but is not limited to this. Step 4: The status code can utilize the existing status code field.
[0402] - When responding to an MLD roaming request, the basic multi-link IE defined in the existing 802.11be can be used for the necessary information about AP MLD and N_AP.
[0403] Step 5: The modified basic multi-link element IE is as follows:
[0404] 1) Common information fields
[0405] Figure 40 shows an example of the common information field structure of the basic ML IE.
[0406] Referring to Figure 40, the common information is common information corresponding to N_APs where 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.
[0407] When transmitting a beacon or ML probe response frame and including the basic ML IE, the channel transition count field may be omitted by using the channel transition count Present field.
[0408] When the Type field of the Common Information field in the Reset ML IE of the MLD Roaming Request frame is set to Type 6, or the Type field of the User Information field / Link Information field is set to Type 8, the Common Information field of the basic ML IE may include a Channel Switching Count field. When the Common Information field includes a Channel Switching Count field, if more than one link(s) requesting link switching simultaneously with one MLD roaming request have the same time to finish switching to the new link(s), the Channel Switching Count field of the Common Information field can be used to inform the AP / STA how long the link switching will take. The Link Switching Count / Channel Switching Count indicates the number of TBTTs to be received from the AP connected to the existing link before the link is switched to the new link. The Channel Switching Count field allows the AP to inform the STA how long it will perform link switching to the new link.
[0409] 2) Link information field
[0410] When more than one STA performs MLD roaming simultaneously, one or more Per-STA profile sub-elements (profile sub-elements) may be required for the corresponding APs.
[0411] The link information field reflecting the information changed for the STA control field, STA information field, and STA profile field of the existing basic multi-link element IE is exemplified in Fig. 41.
[0412] Figure 41 shows an example of the link information field structure of the basic ML IE.
[0413] Referring to Figure 41:
[0414] - The UHR MLD MAC address (or the MAC address for the roaming group) may be included in the link information field in the basic ML IE. For example, the UHR MLD MAC address (or the MAC address for the roaming group) may be included in the STA control field of the link information field. As another example, the UHR MLD MAC address (or the MAC address for the roaming group) may be included in the STA information field of the link information field. In this case, the STA control field may further include a subfield (e.g., UHR MAC address Present) indicating whether the UHR MLD MAC address (or the MAC address for the roaming group) is included in the STA information field.
[0415] - Basically, the link ID indicates the link ID corresponding to N_AP.
[0416] - The Complete profile, as before, refers to the AP's Complete information, i.e., all information included when transmitting a connection response frame. However, since the AP's STA performs MLD roaming, its capabilities or operating parameters may not change. Therefore, in this case, the Complete profile is set to 0.
[0417] - Additionally, it includes information about the MLD roaming timer. For this, the STA control field includes the MLD roaming timer Present field, and the STA information field includes the MLD roaming timer field. This means the time when MLD roaming is completed and no longer operates with the O_AP, but operates with the N_AP. This can utilize the MLD roaming timer information transmitted by the STA, and may not be included if the STA transmitted it and the status code of the response is SUCCESS.
[0418] When the basic ML IE is included in the connection request / response frame, since roaming-related information is not required, 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), Collocation ID, channel switching count, UHR roaming timer, MLD roaming timer, UHR AP MLD ID (or group ID), AP MLD ID and / or channel switching count fields shown in FIG. 41 using the Presence field.
[0419] If each link requires different times to complete a link switch, a channel switch count field can be added to the link information field to indicate the individual timeframe for completing the link switch for each link. If a link switch is requested for only one link through an MLD roaming request, the channel switch count field can be included in either the common information field or the link information field.
[0420] - In addition to the above information, the UHR AP MLD ID (or group ID) and AP MLD ID may be included as follows. The AP MLD ID is the ID of the AP MLD to which the APs to which the non-AP MLD (or STA) will roam belong, and the UHR AP MLD ID (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. If the UHR AP MLD ID (or group ID) is not included in the MLD roaming request frame, it can be known that it is associated / included in the same UHR AP MLD (or roaming group), and thus the UHR AP MLD ID (or group ID) field may not be included. The detailed cases for this are as follows:
[0421] Case 1-1) If included in the common information field
[0422] This can be utilized when the reset multi-link (ML) IE described above is requested in a manner corresponding to case 1-1).
[0423] Similarly, the presence bitmap indicates whether the UHR AP MLD ID (or group ID) and AP MLD ID are included, and accordingly, the UHR AP MLD ID (or group ID) and AP MLD ID are included in the common information field. This can only provide information on APs in the AP MLD where the UHR AP MLD ID (or group ID) = 0 and the Collocation ID≠0.
[0424] Case 1-2) If included in the common information field
[0425] This can be utilized when the reset ML IE described above is requested in a manner corresponding to cases 1-2).
[0426] Similarly, the presence bitmap indicates whether or not the AP MLD ID is included, and accordingly the AP MLD ID is included in the common information field.
[0427] Case 2-1) If included in the link information field - always present
[0428] This can be utilized when the reset ML IE described above is requested in a manner corresponding to case 2-1).
[0429] 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 about multiple APs corresponding to multiple AP MLD IDs, but if provided for the same AP MLD ID, the overhead is greater than indicating it in the common information field.
[0430] Case 2-2) If included in the link information field - always present
[0431] This can be utilized when the reset ML IE described above is requested in a manner corresponding to case 2-2).
[0432] Include the 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 about multiple APs corresponding to multiple AP MLD IDs, but if provided for the same AP MLD ID, the overhead is greater than indicating it in the common information field.
[0433] Case 3-1) If included in the link information field - if it does not always exist
[0434] This can be utilized when the reset ML IE described above is requested in a manner corresponding to case 3-1).
[0435] 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 of the STA control field of the Per-STA profile sub-element. The UHR AP MLD ID (or group ID) and the AP MLD ID can be included in the STA information field or the STA profile field. Similarly, this can provide information about multiple APs corresponding to multiple AP MLD IDs. In particular, when combined with the indication method in the common information field, if only information about APs corresponding to the same AP MLD ID is provided, overhead can be reduced compared to the method of including the UHR AP MLD ID (or group ID) and the AP MLD ID in the link information field by not including them.
[0436] Meanwhile, in the case of setting a unique ID within the collocation set of AP MLD related to the AP MLD ID setting described above, if the collocation ID is 0, the UHR AP MLD ID (or group ID), 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.
[0437] Meanwhile, if the Collocation ID is indicated in the common information field in another way, it may not include the UHR AP MLD ID (or group ID), AP MLD ID, or Collocation ID because it is implicitly recognized that this is information about APs corresponding to the same collocation set. In other words, the UHR AP MLD ID (or group ID) Present and AP MLD ID Present fields may not be included.
[0438] Case 3-2) If included in the link information field - if it does not always exist
[0439] This can be utilized when the reset ML IE described above is requested in a manner corresponding to case 3-2).
[0440] The AP MLD ID Present of the STA Control field of the Per-STA profile sub-element can indicate whether to include the AP MLD ID for the AP corresponding to the link ID. The AP MLD ID can be included in the STA information field or the STA profile field. Similarly, this can provide information about multiple APs corresponding to multiple AP MLD IDs. In particular, when combined with the indication method in the common information field, if only information about APs corresponding to the same AP MLD ID is provided, overhead can be reduced compared to the method of including the AP MLD ID in the link information field by not including it.
[0441] Meanwhile, in the case of setting a unique ID within the collocation set of AP MLD related to the AP MLD ID setting described above, if the collocation ID is 0, the AP MLD ID and collocation ID may be omitted. That is, if the collocation ID does not exist, the AP receiving the request can implicitly recognize that it is a request for information from other APs regarding the AP MLD to which it belongs.
[0442] Meanwhile, if the Collocation ID is indicated in the common information field in another way, it may not include the AP MLD ID or Collocation ID because it is implicitly recognized that this is information about APs corresponding to the same collocation set. That is, the UHR AP MLD ID (or group ID) Present and AP MLD ID Present fields may not be included.
[0443] Step 6: Group key information. Since the group key is different for each link, group key information needs to be provided for N_APs.
[0444] Figure 42 shows an example of a group key information field.
[0445] Referring to Figure 42, the Length field indicates the length of the group key information. The group key information for each N_AP includes the MLO GTK KDE format, MLO IGTK KDE, and MLO BIGTK KDE, which each include the link ID of the N_AP as defined in 802.11be.
[0446] Step 7: Because the total AID (Association Identifier) space is limited, each AP MLD can manage its own AID. This means that AIDs can be assigned when roaming to other AP MLDs. However, AIDs may not be included in the following cases:
[0447] - When roaming to another AP MLD and granting the same AID
[0448] - In case the entire AID space is managed by the UHR AP MLD (or roaming group) as before
[0449] Steps 8 and 9: If included, each AP to which you are roaming must have the same channel, but different from the previously connected APs. However, steps 8 and 9 may or may not be included in the following cases:
[0450] - These IEs are not included as all APs that enable MLD roaming are always on the same channel.
[0451] The channel of an AP to be roamed to may be the same as or different from the channel of the previously connected AP. In this case, a channel switching broadcast IE or an extended channel switching broadcast IE may be included in the link information of the basic multi-link IE in step 5. This is to perform channel switching for each roaming AP.
[0452] Step 10: This can be used to map TIDs in advance for newly connected links through TID-to-link mapping. If separate TID-to-link mapping is not performed, the default mapping can be applied.
[0453] Additionally, an MLD roaming timer can be added to both MLD roaming request / response frames.
[0454] Additionally, the AP MLD may include the MLD roaming timer of the above-mentioned reset ML IE. This can also indicate a specific MLD roaming timer, since the AP MLD can control the current roaming. For example, if the STA does not include an MLD roaming timer or it is inappropriate, the AP MLD can set it and notify the STA. Also, if the STA did not transmit an MLD roaming timer, the AP MLD can set it and notify the STA. The meaning of the MLD roaming timer is the same. That is, it means the time when MLD roaming is completed and no longer operates with the O_AP, but operates with the N_AP.
[0455] When a temporary add request is received, the STA completely disconnects from the O_AP (i.e., temporary deletion or deletion) after the MLD roaming timer expires, and allows it to associate with the N_AP.
[0456] 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 of the MLD roaming timer can be indicated in the common information field through the Presence bitmap.
[0457] - Additionally, the MLD roaming response frame may include information about the MLD roaming timer. For this purpose, the STA control field includes an MLD roaming timer Present field, and the STA information field includes an MLD roaming timer field. This may indicate the remaining time until the STA can receive data from the AP to which it is roaming. This may utilize the MLD roaming timer information transmitted by the STA. This is basically related to the TIM field described above.
[0458] If the MLD roaming timer is applied to all APs, it can be included in the common information field. The presence of the common information field can be indicated via the presence bitmap. Alternatively, it can be included in the body of the MLD roaming probe request frame.
[0459] The operation process of AP and STA performing MLD roaming is as follows.
[0460] Figure 43 illustrates a procedure for determining whether an N_AP is capable of roaming using the Collocation Enabled field.
[0461] Referring to Figure 43, the AP's transmission and reception process is as follows:
[0462] O_AP transmits RNR IE included in the beacon to STA. When O_AP receives MLD roaming request frame from STA, it verifies the link ID, AP MLD ID, and UHR AP MLD ID (or group ID) (optional) of the AP to which STA wants to roam. O_AP transmits to STA whether it accepts the request and information described in the roaming response frame format through MLD roaming response frame.
[0463] Referring to Figure 43, the STA transmission and reception process is as follows:
[0464] When the STA receives a beacon, it checks whether the MLD roaming parameter field exists in the TBTT information field. The STA checks 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=1, UHR AP MLD ID (or group ID)=0, and Collocation Enabled=0. The STA transmits an MLD Roaming Request frame to the O_AP. The STA receives an MLD Roaming Response frame from the O_AP, and if accepted, roams to the N_AP.
[0465] Figure 44 illustrates a procedure for determining whether an N_AP is capable of roaming using a Collocation ID.
[0466] Referring to Figure 44, the transmission and reception process of the AP is as follows:
[0467] O_AP transmits RNR IE included in the beacon to STA. When O_AP receives MLD roaming request frame from STA, it verifies the link ID, AP MLD ID, and UHR AP MLD ID (or group ID) (optional) of the AP to which STA wants to roam. O_AP sends MLD roaming response frame to STA to indicate whether it accepts the request and information described in the roaming response frame format.
[0468] Referring to Figure 44, the STA transmission and reception process is as follows:
[0469] When the STA receives a beacon, it checks whether the MLD roaming parameter field exists in the TBTT information field. The STA checks the MLD Roaming Enabled, UHR AP MLD ID (or group ID), and Collocation ID in the MLD Roaming Parameter field. At this time, MLD Roaming Enabled=1, UHR AP MLD ID (or group ID)=0, and Collocation ID≠0. The STA transmits an MLD Roaming Request frame to the O_AP. The STA receives an MLD Roaming Response frame from the O_AP, and if accepted, roams to the N_AP.
[0470] Figure 45 illustrates the MLD roaming procedure when a UHR AP MLD ID is entered in the reset element.
[0471] Referring to Figure 45, the transmission and reception process of the AP is as follows:
[0472] O_AP transmits information about other APs to STA through beacon. When receiving MLD roaming request frame from STA, STA checks the ID of AP to which it wants to roam through link ID and AP MLD ID. Additionally, if MLD roaming request frame includes UHR AP MLD ID (or group ID), STA also checks UHR AP MLD ID (or group ID). O_AP transmits information on acceptance and response information (e.g., information as exemplified in ) to STA through MLD roaming response frame.
[0473] Referring to Figure 45, the transmission and reception process of STA is as follows.
[0474] The STA receives information about other APs via the beacon from the O_AP. Based on the information about the APs received from the O_AP, the STA determines which AP to roam to. The STA transmits a roaming request frame to the O_AP. The STA receives an MLD roaming response frame from the O_AP, and if accepted, roams to the N_AP.
[0475] Figure 46 illustrates the MLD roaming procedure when the UHR AP MLD ID is not entered in the reset element.
[0476] Referring to Figure 46, the transmission and reception process of the AP is as follows:
[0477] O_AP transmits information about other APs to STAs via beacons. Upon receiving an MLD roaming request frame from an STA, the STA verifies the ID of the AP to which it wishes to roam using the link ID and AP MLD ID. O_AP transmits information regarding acceptance and MLD response information (e.g., information exemplified in Table 5) to the STA via an MLD roaming response frame.
[0478] Referring to Figure 46, the STA transmission and reception process is as follows:
[0479] The STA receives information about other APs via the beacon from the O_AP. Based on the information about the APs received from the O_AP, the STA determines which AP to roam to. The STA transmits a roaming request frame to the O_AP. The STA receives an MLD roaming response frame from the O_AP, and if accepted, roams to the N_AP.
[0480] Figure 47 shows an example of a collocated AP set.
[0481] Figure 47 shows an example of determining whether to roam based on collocation information when a non-AP MLD moves while it is already connected to AP 2. Collocation information can be obtained through the Collocation Enabled field or Collocation ID field of the RNR IE. Although AP 4 and AP 5, which are associated with AP MLD 2, exist around the non-AP MLD, they are included in the same collocated AP set as the currently connected AP 2, so the non-AP MLD does not make a roaming request to AP 4 and AP 5. On the other hand, the non-AP MLD can make a roaming request to AP 6, AP 7, and AP 8, which are included in a different collocated AP set from AP 2. By defining a collocated AP set in this way, unnecessary roaming can be prevented by informing information about APs that are physically close and do not need to roam.
[0482] Figure 48 illustrates Example 1 for the MLD roaming procedure. Example 1 corresponds to a case where only some STAs roam to the AP first.
[0483] Referring to Figure 48, rather than all STAs roaming to APs in different AP MLDs at once, only some STAs roam to APs first. For example, STA 1 roams from AP 1 to AP 3 first, and then STA 2 roams from AP 3 to AP 5.
[0484] In this example, there are two STAs in the non-AP MLD, but even if there are three STAs, only two STAs can roam first and the remaining STAs can roam next.
[0485] In this example, STA 1 and AP 1, as presented above, can first exchange MLD roaming request / response. STA 1 will indicate the (optional) UHR AP MLD ID (or group ID), AP MLD ID, and link ID for AP 4 in the MLD roaming request, and AP 1 will include information about AP 4 in the basic multi-link IE along with whether to accept it. Next, STA 2 and AP 3 will perform the same procedure for AP 5. At this time, the procedure can also be performed for AP 4, to which STA 1 is connected, instead of STA 2.
[0486] This example can be effective for data reception. While AP 1 and STA 1 are undergoing a roaming procedure, AP 2 and STA 3 can exchange data, and while AP 3 and STA 2 are undergoing a roaming procedure, AP 4 and STA 1 can exchange data. In this case, all TIDs must be mapped to the links exchanging data. However, this example is difficult to apply to STAs other than MLD or when there is only one STA in MLD, and it can incur relatively high frame exchange overhead.
[0487] Figure 49 shows the operation process of Example 1 for the MLD roaming procedure.
[0488] Referring to Figure 49, the transmission and reception process of the AP is as follows:
[0489] AP 1 receives a roaming request frame from STA 1. The STA determines the ID of the AP to which it wishes to roam using the link ID, AP MLD ID, and UHR AP MLD ID (or group ID) (optional). AP 1 transmits to STA 1 whether it accepts the request and response information for APs 4 and 5 (e.g., information exemplified in Table 5) via an MLD roaming response frame.
[0490] Referring to Figure 49, the STA transmission and reception process is as follows:
[0491] STA 1 sends an MLD roaming request frame to AP 1 for APs 4 and 5. STA 1 roams to AP 4 based on the information about AP 4 it received from AP 1 upon receiving roaming acceptance through an MLD roaming response frame. After STA 1's roaming is complete, STA 2 also roams to AP 4 based on the acceptance of AP 5 it received from STA 1 and the information about APs 4 and 5.
[0492] Figure 50 illustrates Example 2 for the MLD roaming procedure. Example 2 can handle the case where all STAs are transferred to APs in different groups at once.
[0493] Referring to Figure 50, all STAs can simultaneously roam to APs in different groups. For example, STA 1 roams from AP 1 to AP 3, and STA 2 roams from AP 3 to AP 5.
[0494] In this example, STA 1 and AP 1 or STA 2 and AP 3 presented above can exchange MLD roaming request / response. At this time, the MLD roaming request will indicate the UHR AP MLD ID (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 basic multi-link IE along with whether to accept it.
[0495] This example can reduce frame overhead compared to Example 1 and reduce data delay depending on the AP MLD roaming domain structure. However, data reception may be interrupted when the channel is different. To prevent data reception from being interrupted, the UHR AP MLD (or group management AP MLD) manages data reception and MLD roaming. If it accepts an MLD roaming request, the data path can be set for roaming in advance. This example only shows the case where two links are switched, but if multiple links are switched, a roaming request can be sent to 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 reset multi-link element, or if the frame is not a frame requesting addition or deletion, it can mean a frame requesting a link switch. When an MLD roaming request / response frame is transmitted and received between an AP MLD and a non-AP MLD, if a number of beacons equal to the value of the deletion timer in the reset ML IE or the channel switching count in the default ML IE is received from the previous AP MLD, a link switch is performed to the new roaming AP MLD.
[0496] Figure 51 shows the operation process of Example 2 for the MLD roaming procedure.
[0497] Referring to Figure 51, the transmission and reception process of the AP is as follows.
[0498] AP 1 receives a roaming request frame from STA 1. The STA determines the ID of the AP to which it wishes to roam through the link ID, AP MLD ID, and UHR AP MLD ID (or group ID) (optional). AP 1 transmits to STA 1 whether it accepts the request and roaming response information for APs 4 and 5 (e.g., information exemplified in Table 5) through an MLD roaming response frame.
[0499] Referring to Figure 51, the transmission and reception process of STA is as follows.
[0500] STA 1 sends an MLD roaming request frame to AP 1 for APs 4 and 5. STA 1 roams to AP 4 based on the information about AP 4 it received from AP 1 upon receiving roaming acceptance through an MLD roaming response frame. After STA 1's roaming is complete, STA 2 also roams to AP 4 based on the acceptance of AP 5 it received from STA 1 and the information about APs 4 and 5.
[0501] Figure 52 shows Example 3 for the MLD roaming procedure.
[0502] Figure 52 is an example in which STA 1 first temporarily adds AP 4 and STA 2 temporarily adds AP 5, and then deletes AP 1 and AP 3, respectively.
[0503] In this example, for the temporary addition presented above, first, STA 1 and AP 1 or STA 2 and AP 3 can exchange MLD roaming request / response. At this time, the MLD roaming request will indicate the UHR AP MLD ID (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 basic ML IE along with whether to accept it. When this process is completed, STA 1 will be temporarily connected to AP 1 and AP 4, and STA 2 will be connected to AP 3 and AP 5. STA 1 can transmit or receive data from AP 1 and AP 4. That is, when exchanging frames with AP 1, it cannot exchange frames with AP 4. Next, STA 1 performs a temporary deletion (or, erase) operation on AP 1, STA 2 and AP 3. Through this procedure, STA 1 completes roaming to AP 4, and STA 2 completes roaming to AP 5.
[0504] The above example is a procedure for performing temporary addition and deletion, respectively. If a timer is used here, these procedures can be performed simultaneously. For example, STA 1 and AP 1, or STA 2 and AP 3, can exchange MLD roaming request / response. At this time, in the MLD roaming request, AP 1 and AP 3 are simultaneously requested to be deleted (or temporarily deleted), and AP 4 and AP 5 are simultaneously requested to be temporarily added. At this time, the MLD roaming timer presented above is set. As mentioned above, this can be set by non-AP MLD or AP MLD through the MLD roaming response. After the MLD roaming response is successfully transmitted, the timer starts to run, and when the timer expires, the link to AP 1 is deleted from STA 1, and AP 4 is fully connected, and AP 3 is deleted from STA 2, and AP 5 is fully connected.
[0505] Figure 53 shows Example 4 for the MLD roaming procedure.
[0506] Referring to Figure 53, first, STA 1 deletes (or temporarily deletes) AP 4 and STA 2 deletes (or temporarily adds) AP 1 and AP 2, respectively.
[0507] In this example, for the delete presented 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 indicate (Optional) UHR AP MLD, AP MLD ID, and Link ID for AP 4 and AP 5, and AP 1 or AP 2 will include information about AP 4 and AP 5 in the Basic Multi-link IE along with whether to accept it. After this process is complete, STA 1 or STA 2 can disconnect from AP 1 and AP 3. Even when one link is deleted, if data arrives from the AP that performed the link deletion, the STA that has not yet deleted the link can receive it instead, or the UHR AP MLD can send it to the AP to which it will roam after roaming. Next, STA 1 performs an add operation for AP 4, STA 2, and AP 5. Through this procedure, STA 1 completes roaming to AP 4, and STA 2 completes roaming to AP 5.
[0508] The above example is a procedure to perform temporary add and delete respectively. If a timer is used here, these procedures can be performed simultaneously. For example, STA 1 and AP 1 or STA 2 and AP 2 can exchange MLD Roaming Request / Response. At this time, in the MLD Roaming Request, AP 1 and AP 2 can request Delete (or Temporary Delete), and AP 4 and AP 5 can request Add (or Temporary Add) simultaneously or individually. At this time, the MLD Roaming Timer presented above is set. As mentioned above, this can be set by non-AP MLD or AP MLD through the MLD Roaming Response. After the MLD Roaming Response is successfully transmitted, the timer starts running, and when the timer expires, the AP 1 link is deleted from STA 1, and AP 4 is fully connected, and STA 2 deletes AP 3, and AP 5 is fully connected.
[0509] Figure 53 shows Example 4 for the MLD roaming procedure.
[0510] Referring to Figure 53, first, STA 1 deletes (or temporarily deletes) AP 4 and STA 2 deletes (or temporarily adds) AP 1 and AP 2, respectively.
[0511] In this example, for the deletion presented above, first, STA 1 and AP 1 or STA 2 and AP 2 can exchange MLD roaming request / response. At this time, the MLD roaming request will indicate (optional) UHR AP MLD ID (or group ID), AP MLD ID and link ID for AP 4 and AP 5, and AP 1 or AP 2 will include information about AP 4 and AP 5 in the basic ML IE along with whether to accept it. After this process is completed, STA 1 or STA 2 can disconnect from AP 1 and AP 3. Even when one link is deleted, if data comes from the AP that has deleted the link, the STA that has not yet deleted the link can receive it instead, or the UHR AP MLD can send it to the AP to which it will roam after roaming. Next, STA 1 performs the operation of adding AP 4, STA 2 and AP 5. Through this procedure, STA 1 completes roaming to AP 4, and STA 2 completes roaming to AP 5.
[0512] The above example is a procedure for performing temporary addition and deletion, respectively. If a timer is used here, these procedures can be performed simultaneously. For example, STA 1 and AP 1, or STA 2 and AP 2, can exchange MLD roaming request / response. At this time, in the MLD roaming request, deletion (or temporary deletion) for AP 1 and AP 2, addition (or temporary addition) for AP 4 and AP 5 can be requested simultaneously or individually. At this time, the MLD roaming timer presented above is set. As mentioned above, this can be set by non-AP MLD or AP MLD through the MLD roaming response. After the MLD roaming response is successfully transmitted, the timer starts, and when the timer expires, the link to AP 1 is deleted from STA 1, and AP 4 is fully connected, and AP 3 is deleted from STA 2, and AP 5 is fully connected.
[0513] Figure 54 shows the operation process of Examples 3 and 4 for the MLD roaming procedure.
[0514] Referring to Figure 54, the transmission and reception process of the AP is as follows.
[0515] AP 1 receives a roaming request frame from STA 1. The STA identifies the AP to which it wants to roam through the link ID, AP MLD ID, and UHR AP MLD ID (or group ID) (optional). AP 1 sends STA 1 whether to accept the request and roaming response information for APs 4 and 5 (e.g., information illustrated in Table 5) through an MLD roaming response frame. AP 1 sets the MLD roaming timer. At this time, when the MLD roaming timer times out / expires, the existing connection is completely deleted and the roamed AP is completely connected.
[0516] Referring to Figure 54, the transmission and reception process of STA is as follows.
[0517] STA 1 sends an MLD roaming request frame for APs 4 and 5 to AP 1. If STA 1 receives roaming acceptance from AP 1 by receiving an MLD roaming response frame, STA 1 roams to AP 4 based on the information about AP 4 received. After STA 1's roaming is finished, STA 2 also roams to AP 4 based on the acceptance of AP 5 received from STA 1 and the information about APs 4 and 5. STA 1 sets the MLD roaming timer. At this time, when the MLD roaming timer times out / expires, the existing connection is completely deleted and the roamed AP is completely connected.
[0518] Figure 55 illustrates an example of how to set the type field of an MLD roaming request frame when simultaneously transmitting requests for link addition and deletion.
[0519] Referring to FIG. 55, in order for a non-AP MLD to roam to a new AP MLD (AP MLD 2), it first requests link addition, and then a connection is created between STA 1 and AP 4, and then requests deletion of the connection with AP 1, which was previously connected to STA 1. When requesting link addition and deletion, the link ID and AP MLD ID can be used to request the AP to which the request is sent. When the deletion request is sent and the connection between STA 1 and AP 1 is completely deleted, STA 1 cannot transmit and receive data with AP MLD 1, but STA 2 of the non-AP MLD is connected to AP 3 of AP MLD 1, so the non-AP MLD and AP MLD 1 can transmit and receive data. Therefore, data discontinuity can be reduced during roaming. After the link change of STA 1 is completed, STA 2 can also request to add a link to AP 5 and then disconnect from AP 3 to completely roam to the new AP MLD 2. At this time, since AP MLD 1 and AP MLD 2 are associated with the same UHR AP MLD (or AP MLD for continuous roaming) (or are included in the same roaming group), the data queued in AP MLD 1 can be passed on to AP MLD 2.
[0520] Figure 56 illustrates another example of how to set the type field of an MLD roaming request frame when simultaneously transmitting requests for link addition and deletion.
[0521] The roaming procedure in FIG. 56 is largely the same as the roaming procedure in FIG. 55, except that the link is first deleted and then the link with AP MLD 2 is added.
[0522] When adding and deleting a link (e.g., FIG. 55) or when deleting and adding a link (e.g., FIG. 56), two requests can be made by transmitting the MLD roaming request frame separately, or both operations can be requested simultaneously through a single frame transmission. When requesting both addition and deletion simultaneously and wanting to add a new link first and delete an existing link later (e.g., FIG. 55), the MLD roaming request frame can be configured in the corresponding method described above. When requesting both addition and deletion simultaneously and wanting to delete an existing link first and add a new link later (e.g., FIG. 56), the MLD roaming request frame can be configured in the corresponding method described above. That is, the link information field can include two Per-STA profiles (one Per-STA profile for addition and one Per-STA profile for deletion). When requesting addition and deletion separately, the MLD Roaming Request frame sending the addition / deletion request can be configured so 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 link information field of the body of the MLD Roaming Request frame or the reset ML IE, as described above. Thereafter, a response to the request is received as an MLD Roaming Response frame, and the status code indicates whether the MLD Roaming Request frame is accepted or rejected.
[0523] Additionally, in order for STA 1 to completely transition from AP 1 to AP 4, processes such as those in FIGS. 57 and 58 are required.
[0524] Figure 57 shows an example of MLD roaming using TIM.
[0525] AP 1 can notify STA 1 via TIM whether it has DL data to transmit via beacon. At this time, STA 1 transmits an MLD roaming request to add AP 4 for roaming. This example only describes STA 1, but it can also request link addition for the link between STA 2 and AP 5 as shown in FIG. 48. AP 1 confirms this and responds with acceptance to AP 4. However, STA 1 may have received information that it is not currently buffering DL data from the latest beacon of AP 1, or may have buffered it but not yet received it. Therefore, AP 1 can notify STA 1 that AP 4 or UHR AP MLD has the DL data. In other words, when switching to AP 4, STA 1 can immediately receive DL data from AP 4 via PS-poll transmission without waiting for the beacon to be received. To achieve this, additional information needs to be indicated in the MLD Roaming Response frame, which is as follows:
[0526] - TIM (Traffic Indication Map) field (e.g., 1 bit): This indicates that the corresponding AP or AP MLD is buffering DL data for the currently requesting STA.
[0527] From an MLD-level perspective, if the UHR AP MLD indicates that it is buffering DL data for the requesting STA, the TIM field may be included in the MLD roaming response frame body or the common information field.
[0528] From the perspective of the AP, the TIM field can be included in the link information field, for example, to indicate that AP 4 has DL data before switching to AP 4.
[0529] Meanwhile, an STA (e.g., STA 1) can additionally use the MLD roaming timer in the MLD roaming response frame to determine the time to switch. For example, if there is still a lot of time left until it receives data from the AP to which it is currently roaming (e.g., AP 4) before switching, STA 1 can first receive DL data from the currently connected AP (e.g., AP 1) through PS-Poll (if necessary) and then switch. Alternatively, if there is still time to receive data from AP 4 even if it switches immediately, STA 1 can switch immediately.
[0530] Figure 58 shows the operation process for the MLD roaming procedure using TIM.
[0531] Referring to Figure 58, the transmission and reception process of the AP is as follows:
[0532] AP 1 notifies STA 1 via TIM whether it has DL data to transmit via beacon. Upon receiving the roaming request, AP 1 responds with acceptance to AP 4 (+AP 5). AP 1 then informs who has the DL data. The AP with the DL data or the UHR AP MLD transmits the DL data to STA 1 (+STA 2). Upon receiving a connection deletion request from an STA, AP 1 (+AP 3) deletes the existing connection.
[0533] Referring to Figure 58, the STA transmission and reception process is as follows:
[0534] STA 1 performs roaming and sends an MLD roaming request to add AP 4. At this time, it can also request the addition of a link for AP 5 to STA 2. STA 1 receives information about DL data. STA 1 (+STA 2) performs roaming to AP 4 (+AP 5). STA 1 (+STA 2) transmits a PS-Poll to AP 4 (+AP 5) and receives the corresponding DL data. STA 1 (+STA 2) requests link deletion to AP 1 (+AP 3).
[0535] The technical features of the present disclosure described above can be applied to various devices and methods. For example, the technical features of the present disclosure described above can be performed / supported by the devices of FIG. 1 and / or FIG. 5. For example, the technical features of the present disclosure described above can be applied only to a portion of FIG. 1 and / or FIG. 5. For example, the technical features of the present disclosure described above can 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.
[0536] For example, the processor (111), the processing chip (114) of FIG. 1, and / or the processor (510) of FIG. 5 may be configured to execute instructions stored in the memory (112, 520) to implement a method performed by an STA in the present disclosure. The method includes: performing an association procedure with an access point (AP); receiving, from the AP, a link reconfiguration notify frame including a list of links for which link modification is recommended for roaming, each link in the list of links for which link modification is recommended being associated with a corresponding AP in a roaming group; transmitting, to the AP, a roaming request frame for requesting link modification of at least one link in the list of links for which link modification is recommended; performing link modification of the at least one link based on receiving a roaming response frame for the roaming request frame; And based on the link modification of at least one link, a step of performing roaming from a first AP included in the roaming group to a second AP included in the roaming group.
[0537] For example, the processor (121) and / or the processing chip (124) of FIG. 1 may be configured to execute instructions stored in the memory (122) to implement a method performed by an AP in the present disclosure. The method includes: performing an association procedure with a station (STA); transmitting, to the STA, a link reconfiguration notify frame including a list of links for which link modification is recommended for roaming, wherein each link in the list of links for which link modification is recommended is associated with a corresponding AP in a roaming group; receiving, from the STA, a roaming request frame for requesting link modification of at least one link in the list of links for which link modification is recommended; and transmitting, to the STA, a roaming response frame for link modification of the at least one link, wherein roaming of the STA is performed from a first AP included in the roaming group to a second AP included in the roaming group based on the link modification of the at least one link.
[0538] The technical features of the present disclosure can be implemented based on a computer-readable medium (CRM). For example, the CRM proposed by the present disclosure is at least one computer-readable recording medium containing instructions that are executed by at least one processor.
[0539] For example, the CRM may be the memory (112) of FIG. 1, the memory (520) of FIG. 15, and / or a separate external memory / storage medium / disk. The CRM may store commands for implementing a method performed by an STA in the present disclosure based on being executed by a processor (e.g., the processor (111), the processing chip (114) of FIG. 1, and / or the processor (510) of FIG. 5). The method comprises: performing an association procedure with an access point (AP); receiving, from the AP, a link reconfiguration notify frame including a list of links for which link modification is recommended for roaming, each link in the list of links for which link modification is recommended being associated with a corresponding AP in a roaming group; transmitting, to the AP, a roaming request frame for requesting link modification of at least one link in the list of links for which link modification is recommended; A step of performing link modification of at least one link based on receiving a roaming response frame for the roaming request frame; and a step of performing roaming from a first AP included in the roaming group to a second AP included in the roaming group based on the link modification of the at least one link.
[0540] 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 commands for implementing a method performed by an AP in the present disclosure based on being executed by a processor (e.g., the processor (121) and / or the processing chip (124) of FIG. 1). The method comprises: performing an association procedure with a station (STA); transmitting, to the STA, a link reconfiguration notify frame including a list of links for which link modification is recommended for roaming, wherein each link in the list of links for which link modification is recommended is associated with a corresponding AP in a roaming group; receiving, from the STA, a roaming request frame for requesting link modification of at least one link in the list of links for which link modification is recommended; And a step of transmitting a roaming response frame for link modification of the at least one link to the STA, wherein roaming of the STA is performed from a first AP included in the roaming group to a second AP included in the roaming group based on the link modification of the at least one link.
[0541] The technical features of the present disclosure described above are applicable to various applications and business models. For example, the technical features described above can be applied to wireless communication in devices that support artificial intelligence (AI).
[0542] Artificial intelligence (AI) is the study of artificial intelligence or the methodologies for creating it, while machine learning (ML) defines various problems in the field of AI and studies the methodologies for solving them. Machine learning is also defined as an algorithm that improves performance on a task through consistent experience.
[0543] An artificial neural network (ANN) is a model used in machine learning. It can refer to a model with problem-solving capabilities, consisting of artificial neurons (nodes) formed by the connection of synapses to form a network. An ANN can be defined by the connection patterns between neurons in different layers, the learning process that updates model parameters, and the activation function that generates output values.
[0544] An artificial neural network may include an input layer, an output layer, and optionally one or more hidden layers. Each layer contains one or more neurons, and the artificial neural network may include synapses connecting neurons. In an artificial neural network, each neuron can output a function value of an activation function based on input signals, weights, and biases received through the synapses.
[0545] Model parameters are parameters determined through learning, including synaptic connection weights and neuron biases. Hyperparameters are parameters that must be set before learning in machine learning algorithms, including the learning rate, number of iterations, mini-batch size, and initialization function.
[0546] The goal of artificial neural network training can be seen as determining model parameters that minimize a loss function. The loss function can be used as an indicator for determining optimal model parameters during the artificial neural network training process.
[0547] Machine learning can be classified into supervised learning, unsupervised learning, and reinforcement learning depending on the learning method.
[0548] Supervised learning refers to a method for training an artificial neural network when given labels for the training data. The labels can refer to the correct answer (or output value) that the artificial neural network must infer when the training data is input to the artificial neural network. Unsupervised learning can refer to a method for training an artificial neural network when the training data is not given labels. Reinforcement learning can refer to a learning method in which an agent defined within a given environment is trained to select actions or action sequences that maximize the cumulative reward in each state.
[0549] Machine learning implemented with a deep neural network (DNN) containing multiple hidden layers among artificial neural networks is also called deep learning, and deep learning is a subset of machine learning. Hereinafter, the term "machine learning" is used to encompass deep learning.
[0550] Additionally, the above-described technical features can be applied to wireless communication of robots.
[0551] A robot can be defined as a machine that automatically performs or operates a given task based on its own capabilities. Specifically, a robot capable of perceiving its environment, making independent judgments, and performing actions can be called an intelligent robot.
[0552] Robots can be categorized into industrial, medical, household, and military applications based on their intended use or field. Robots are equipped with actuators or motors, enabling them to perform various physical actions, such as moving robot joints. Furthermore, mobile robots incorporate wheels, brakes, and propellers into their actuators, enabling them to move on the ground or fly in the air.
[0553] Additionally, the above-described technical features can be applied to devices that support extended reality.
[0554] Extended reality is a general term for virtual reality (VR), augmented reality (AR), and mixed reality (MR). VR technology presents real-world objects and backgrounds as CG images only, AR technology presents virtual CG images over images of real objects, and MR technology is a computer graphics technology that blends and combines virtual objects with the real world.
[0555] MR technology is similar to AR in that it presents both real and virtual objects simultaneously. However, while AR uses virtual objects to complement real objects, MR uses virtual and real objects on an equal footing.
[0556] XR technology can be applied to HMD (Head-Mount Display), HUD (Head-Up Display), mobile phones, tablet PCs, laptops, desktops, TVs, digital signage, etc., and devices to which XR technology is applied can be called XR devices.
[0557] The present disclosure may have various advantageous effects.
[0558] For example, a UHR AP MLD can use a link reconfiguration notification frame to inform a non-AP MLD STA of the APs it proposes for roaming and the preferences for the proposals. Furthermore, a non-AP MLD STA can first request an AP proposal for roaming by first sending a link reconfiguration notification request frame to the UHR AP MLD.
[0559] The beneficial effects that can be achieved through specific embodiments of the present disclosure are not limited to the beneficial effects listed above. For example, various technical effects may be understood and / or derived from the present disclosure by those skilled in the art. Therefore, the specific effects of the present disclosure are not limited to those explicitly described herein, but may include various effects that can be understood or derived from the technical features of the present disclosure.
[0560] The claims set forth in this disclosure may be combined in various ways. For example, the technical features of the method claims of this disclosure may be combined and implemented as a device, and the technical features of the device claims of this disclosure may be combined and implemented as a method. Furthermore, the technical features of the method claims of this disclosure and the technical features of the device claims of this disclosure may be combined and 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 and implemented as a method.
Claims
1. A step in which a STA (station) performs a connection procedure with an AP (access point); A step in which the STA receives a link reconfiguration notify frame from the AP, the link reconfiguration notify frame including a list of links for which link modification is recommended for roaming, wherein each link in the list of links for which link modification is recommended is associated with a corresponding AP in a roaming group; A step in which the STA transmits a roaming request frame to the AP to request link modification of at least one link from a list of links for which link modification is proposed; A step in which the STA performs link modification of at least one link based on receiving a roaming response frame for the roaming request frame; and A method comprising the step of the STA performing roaming from a first AP included in the roaming group to a second AP included in the roaming group based on a link modification of at least one link.
2. A method according to claim 1, wherein the link modification of at least one link comprises at least one of link deletion of a link associated with the first AP or link addition of a link associated with the second AP.
3. A method according to claim 1, wherein information about a list of links for which link modification is proposed is included in a reset ML (multi-link) IE (information element) of the link reset notification frame.
4. In claim 3, the reset ML IE includes one or more STA profiles, Each of the above one or more STA profiles indicates whether link modification of the corresponding link is proposed, A method wherein the list of links for which link modification is proposed includes links corresponding to STA profiles indicating that link modification is proposed.
5. In claim 4, a method in which each STA profile in the reset ML IE is positioned in the order in which link modifications are proposed, such that the STA profile corresponding to the link for which link modification is most proposed is positioned first.
6. In claim 3, the reset ML IE includes a list of modified link IDs, The above modified link ID list is a method including a link ID of each link in the list of links for which link modification is proposed.
7. In claim 6, a method in which each link ID in the modified link ID list is listed in the order in which link modifications are proposed, such that the link ID corresponding to the link for which link modification is most proposed is listed first.
8. In claim 3, the list of links for which the link modification is proposed includes a link associated with at least one AP associated with a first AP MLD (multi-link device) and a link associated with at least one AP associated with a second AP MLD different from the first AP MLD. A method wherein the above reset ML IE includes a common information field for the first AP MLD and a subsequent common information field for the second AP MLD after the common information field.
9. A method according to claim 8, wherein the STA information field for at least one AP associated with the first AP MLD in the reset ML IE includes a Last Per-STA Info field indicating whether a subsequent common information field for the second AP MLD exists after the STA information field.
10. A method according to claim 8, wherein the common information field for the first AP MLD in the reset ML IE includes at least one of a number of per-STA profiles field indicating whether a subsequent common information field for the second AP MLD exists, or a more common info field.
11. In claim 1, before receiving the link reset notification frame, the STA further includes a step of transmitting a link reset notification request frame to the AP, The above link reset notification frame is a response frame to the above link reset notification request frame.
12. A method according to claim 11, wherein the link reset notification request frame includes a list of links for which the STA proposes link modification.
13. A method according to claim 11, wherein at least one of the link re-establishment notification frame or the link re-establishment notification request frame includes a roaming reason code indicating a reason for requesting link modification for roaming.
14. A method according to claim 13, wherein the list of links for which link modification is proposed is determined based on the roaming cause code.
15. In a wireless local area network (LAN) system, at a STA (station), Transmitter and receiver; memory; and At least one processor functionally coupled with the transceiver and the memory, The above memory stores instructions that perform operations based on being executed by the at least one processor, the operations being: An action that performs a connection procedure with an AP (access point); An action of receiving a link reconfiguration notify frame from the AP, the link reconfiguration notify frame including a list of links for which link modification is recommended for roaming, each link in the list of links for which link modification is recommended being associated with a corresponding AP in the roaming group; An action of transmitting a roaming request frame to the AP to request link modification of at least one link from a list of links for which link modification is proposed; An operation of performing link modification of at least one link based on receiving a roaming response frame for the roaming request frame; and An STA including an operation of performing roaming from a first AP included in the roaming group to a second AP included in the roaming group based on a link modification of at least one link.
16. In a device configured to operate in a wireless local area network (LAN) system, at least one processor; and comprising at least one memory functionally coupled with at least one processor; The at least one memory stores instructions that perform operations based on being executed by the at least one processor, the operations comprising: An action that performs a connection procedure with an AP (access point); An action of receiving a link reconfiguration notify frame from the AP, the link reconfiguration notify frame including a list of links for which link modification is recommended for roaming, each link in the list of links for which link modification is recommended being associated with a corresponding AP in the roaming group; An action of transmitting a roaming request frame to the AP to request link modification of at least one link from a list of links for which link modification is proposed; An operation of performing link modification of at least one link based on receiving a roaming response frame for the roaming request frame; and A device comprising an operation for performing roaming from a first AP included in the roaming group to a second AP included in the roaming group based on a link modification of at least one link.
17. A non-transitory computer readable medium (CRM) storing program code implementing instructions that perform operations based on being executed by at least one processor, said operations comprising: An action that performs a connection procedure with an AP (access point); An action of receiving a link reconfiguration notify frame from the AP, the link reconfiguration notify frame including a list of links for which link modification is recommended for roaming, each link in the list of links for which link modification is recommended being associated with a corresponding AP in the roaming group; An action of transmitting a roaming request frame to the AP to request link modification of at least one link from a list of links for which link modification is proposed; An operation of performing link modification of at least one link based on receiving a roaming response frame for the roaming request frame; and A CRM comprising an operation of performing roaming from a first AP included in the roaming group to a second AP included in the roaming group based on a link modification of at least one link.
18. A step in which an AP (access point) performs a connection procedure with a STA (station); The step of the AP transmitting a link reconfiguration notify frame to the STA, the link reconfiguration notify frame including a list of links for which link modification is recommended for roaming, each link in the list of links for which link modification is recommended is associated with a corresponding AP in the roaming group; The step of the AP receiving a roaming request frame from the STA for requesting link modification of at least one link from the list of links for which link modification is proposed; and The step of the AP transmitting a roaming response frame for link modification of the at least one link to the STA, A method in which roaming of the STA is performed from a first AP included in the roaming group to a second AP included in the roaming group based on link modification of at least one link.
19. In a wireless local area network (LAN) system, at the AP (access point), Transmitter and receiver; memory; and At least one processor functionally coupled with the transceiver and the memory, The above memory stores instructions for performing operations based on being executed by the at least one processor, the operations being: An action that performs a connection procedure with a STA (station); An action of transmitting, to the STA, a link reconfiguration notify frame including a list of links for which link modification is recommended for roaming, wherein each link in the list of links for which link modification is recommended is associated with a corresponding AP in the roaming group; An operation of receiving, from the STA, a roaming request frame for requesting link modification of at least one link from a list of links for which link modification is proposed; and Including an operation of transmitting a roaming response frame for link modification of at least one link to the STA; An AP in which roaming of the STA is performed from a first AP included in the roaming group to a second AP included in the roaming group based on link modification of at least one link.
20. In claim 19, the operations further include an operation in which the STA transmits a link reset notification request frame to the AP before receiving the link reset notification frame, The above link reset notification frame is an AP response frame to the above link reset notification request frame.
Citation Information
Patent Citations
Enhanced wi-fi fast roaming transition for mobile devices
US20220116833A1
Enhanced handover for moving wi-fi multi-link devices
US20230147311A1