Appliance, client device, and wireless communication method
Patent Information
- Application Number
- CN202510502258.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-21
- Publication Date
- 2026-10-30
AI Technical Summary
在建立与目标AP的关联之前,不能执行STA与连接到网络的AP之间的服务数据传输,从而导致传输延迟和数据分组丢失
[0015]根据本公开的实施方案,改进的用于无线通信的漫游机制可以通过上下文转移来实现。
Smart Images

Figure CN123021264A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to wireless communications, and more particularly to access point (AP) devices, client devices, methods, systems, and computer program products for facilitating seamless roaming in wireless networks. Background Technology
[0002] Wireless LAN (WLAN) roaming or Wi-Fi roaming refers to the process of a wireless terminal, station (STA), or client moving from one access point (AP) to another. During WLAN or Wi-Fi roaming, the IP address obtained by the client in the initial stage of connecting to the network remains unchanged, ensuring uninterrupted service.
[0003] When a STA roams from one AP to another, it first disconnects from the currently connected AP before associating with the target AP. Service data transmission between the STA and the APs connected to the network cannot occur until an association with the target AP is established, resulting in transmission delays and data packet loss. Therefore, there is a need to improve the Wi-Fi roaming process. Summary of the Invention
[0004] In view of the above problems, this disclosure provides access point (AP) devices, client devices, methods, systems and computer program products for facilitating seamless roaming in wireless networks.
[0005] According to embodiments of this disclosure, a wireless communication method is provided for implementation at an access point (AP) device, the AP device being a current AP device serving a client device. The method may include: receiving a first request from the client device, the first request indicating a transfer of the communication context between the current AP device and the client device from the current AP device to a target AP device to which the client device is to roam; and, according to a dynamic transfer mode, transferring a first context containing static parameters for roaming association to the target AP device during a roaming preparation process, and transferring a second context containing dynamic parameters for roaming association to the target AP device during a roaming association process.
[0006] According to another embodiment of this disclosure, a wireless communication method for implementation at a client device is provided. The method may include: determining that the context transfer mode for communication between a current access point (AP) device currently serving the client device and the client device is a dynamic transfer mode for a target AP device to which the client device is to roam; and sending a first request to the current AP device, the first request including an indication of the dynamic transfer mode; wherein the dynamic transfer mode indicates that the current AP device transfers a first context containing static parameters for roaming association to the target AP device during a roaming preparation process, and that the target AP device transfers a second context containing dynamic parameters for roaming association during the roaming association process.
[0007] According to another embodiment of this disclosure, a wireless communication method is provided for implementation at an access point (AP) device, which is a target AP device for which a client device is to roam and associate. The method may include: receiving, during a roaming preparation process, a first context of communication between the current AP device and the client device from a current AP device currently serving the client device, the first context including static parameters for roaming association; and receiving, during the roaming association process, a second context of communication between the current AP device and the client device from the current AP device, the second context including dynamic parameters for roaming association.
[0008] According to embodiments of this disclosure, an access point (AP) device is provided, the AP device being a current AP device serving a client device. The current AP device includes: one or more processors; a memory coupled to at least one of the one or more processors; and a set of computer program instructions stored in the memory. When executed by at least one of the one or more processors, the set of computer program instructions causes the current AP device to perform the following operations: receiving a first request from the client device, the first request indicating the transfer of the communication context between the current AP device and the client device from the current AP device to a target AP device for which the client device is to roam; and, according to a dynamic transfer mode, transferring a first context containing static parameters for roaming association to the target AP device during a roaming preparation process, and transferring a second context containing dynamic parameters for roaming association to the target AP device during a roaming association process.
[0009] According to another embodiment of this disclosure, a client device is provided. The client device may include: one or more processors; a memory coupled to at least one of the one or more processors; and a set of computer program instructions stored in the memory. When executed by at least one of the one or more processors, the set of computer program instructions may cause the client device to perform the following operations: determine that the context transfer mode for communication between the current access point (AP) device currently serving the client device and the client device is a dynamic transfer mode for a target AP device to which the client device is to roam; and send a first request to the current AP device, the first request including an indication of the dynamic transfer mode. The dynamic transfer mode indicates that the current AP device transfers a first context containing static parameters for roaming association to the target AP device during a roaming preparation process, and that the target AP device transfers a second context containing dynamic parameters for roaming association during the roaming association process.
[0010] According to another embodiment of this disclosure, an access point (AP) device is provided, the AP device being a target AP device to which a client device is to roam. The target AP device includes: one or more processors; a memory coupled to at least one of the one or more processors; and a set of computer program instructions stored in the memory. When executed by at least one of the one or more processors, the set of computer program instructions can cause the target AP device to perform the following operations: during a roaming preparation process, receiving from a current AP device currently serving the client device a first context of communication between the current AP device and the client device, the first context including static parameters for roaming association; and during a roaming association process, receiving from the current AP device a second context of communication between the current AP device and the client device, the second context including dynamic parameters for roaming association.
[0011] According to embodiments of this disclosure, a computer program product is provided. The computer program product may include computer instructions that, when executed by a processor, implement a wireless communication method at an access point (AP) device, the AP device being a current AP device serving a client device. The method may include: receiving a first request from the client device, the first request indicating a transfer of the communication context between the current AP device and the client device from the current AP device to a target AP device to which the client device is to roam; and, according to a dynamic transfer mode, transferring a first context containing static parameters for roaming association to the target AP device during a roaming preparation process, and transferring a second context containing dynamic parameters for roaming association to the target AP device during a roaming association process.
[0012] According to another embodiment of this disclosure, a computer program product is provided. The computer program product may include computer instructions that, when executed by a processor, implement a wireless communication method implemented at a client device. The method may include: determining that the context transfer mode for communication between a current access point (AP) device currently serving the client device and the client device is a dynamic transfer mode for a target AP device to which the client device is to roam; and sending a first request to the current AP device, the first request including an indication of the dynamic transfer mode. The dynamic transfer mode indicates that the current AP device transfers a first context containing static parameters for roaming association to the target AP device during a roaming preparation process, and that the target AP device transfers a second context containing dynamic parameters for roaming association during the roaming association process.
[0013] According to another embodiment of this disclosure, a computer program product is provided. The computer program product may include computer instructions that, when executed by a processor, implement a wireless communication method at an access point (AP) device, the AP device being a target AP device to which a client device is to roam. The method may include: receiving, during a roaming preparation process, a first context of communication between the current AP device and the client device from a current AP device currently serving the client device, the first context including static parameters for roaming association; and receiving, during a roaming association process, a second context of communication between the current AP device and the client device from the current AP device, the second context including dynamic parameters for roaming association.
[0014] According to embodiments of this disclosure, a wireless communication system is provided. The wireless communication system may include at least a client device, a current access point (AP) device currently serving the client device, and a target AP device to which the client device is to roam. The client device may be configured to perform the following operations: determine that the context transfer mode for communication between the current AP device and the client device to the target AP device is a dynamic transfer mode; and send a first request to the current AP device, the first request including an indication of the dynamic transfer mode. The current AP device may be configured to perform the following operations: receive the first request; and, according to the dynamic transfer mode, transfer a first context containing static parameters for roaming association to the target AP device during a roaming preparation process, and transfer a second context containing dynamic parameters for roaming association to the target AP device during the roaming association process. The target AP device may be configured to perform the following operations: receive the first context from the current AP device during the roaming preparation process; and receive the second context from the current AP device during the roaming association process.
[0015] According to embodiments of this disclosure, the improved roaming mechanism for wireless communication can be implemented through context transfer. Attached Figure Description
[0016] The above and other objects, features, and advantages of this disclosure will become more apparent from a more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to provide a further understanding of the embodiments of this disclosure and form part of the specification. The drawings, together with the embodiments of this disclosure, are used to interpret this disclosure and do not constitute a limitation thereof. In the drawings, unless expressly indicated, like reference numerals generally represent like parts, steps, or elements.
[0017] Figure 1 An exemplary architecture 100 of a wireless communication system according to an embodiment of the present disclosure is illustrated;
[0018] Figure 2 A multi-link reference model 200 for a multi-link (ML) device according to an embodiment of this disclosure is illustrated;
[0019] Figure 3 An exemplary multi-link communication arrangement 300 according to an embodiment of the present disclosure is illustrated;
[0020] Figure 4 A schematic diagram illustrating a roaming process 400 according to an embodiment of the present disclosure is shown;
[0021] Figure 5A schematic diagram illustrating a roaming preparation process 500 according to an embodiment of the present disclosure is shown;
[0022] Figure 6 A schematic diagram illustrating a roaming preparation process 600 according to another embodiment of the present disclosure is shown;
[0023] Figure 7 A schematic diagram illustrating a detection process 700 according to an embodiment of the present disclosure is shown;
[0024] Figure 8 A schematic diagram illustrating a BSS handover management process 800 according to an embodiment of the present disclosure is shown;
[0025] Figure 9 A schematic diagram illustrating a BSS handover management process 900 according to another embodiment of this disclosure is shown;
[0026] Figure 10 A schematic diagram illustrating a roaming process 1000 according to an embodiment of the present disclosure is shown;
[0027] Figure 11 A schematic diagram illustrating a downlink data transfer process 1100 according to an embodiment of the present disclosure is shown;
[0028] Figure 12 A schematic diagram illustrating an uplink data transfer process 1200 according to an embodiment of the present disclosure is shown;
[0029] Figure 13 A schematic diagram illustrating the frame format of a context transfer request frame 1300 according to an embodiment of the present disclosure is shown;
[0030] Figure 14 A schematic diagram illustrating the frame format of a context transfer request frame 1400 according to another embodiment of the present disclosure is shown;
[0031] Figure 15 A schematic diagram illustrating the format of the reduced neighbor report element 1500 according to an embodiment of this disclosure is shown;
[0032] Figure 16 A schematic diagram illustrating the format of a neighbor report element 1600 according to an embodiment of this disclosure is shown;
[0033] Figure 17 A flowchart illustrating a computer implementation method 1700 for wireless communication implemented at a current AP device of a current serving client device according to an embodiment of the present disclosure is shown;
[0034] Figure 18A flowchart illustrating a computer implementation method 1800 for wireless communication implemented at a client device according to an embodiment of the present disclosure is shown;
[0035] Figure 19 A flowchart illustrating a computer implementation method 1900 for wireless communication implemented at a target AP device to which a client device is to roam, according to an embodiment of this disclosure; and
[0036] Figure 20 This is an exemplary block diagram illustrating a computing device 2000 according to some embodiments of the present disclosure.
[0037] Those skilled in the art will understand that the elements in the accompanying drawings are illustrated for simplicity and clarity and are not necessarily drawn to scale. For example, the dimensions of some elements in the illustrations, block diagrams, or flowcharts may be exaggerated relative to other elements to aid in the accurate understanding of this embodiment. Detailed Implementation
[0038] The following detailed description is illustrated in the accompanying drawings. While several exemplary embodiments are described herein, modifications, adaptations, and other implementations are possible. For example, components and steps illustrated in the drawings may be replaced, added, or modified, and the exemplary methods described herein may be modified by replacing, reordering, deleting, or adding steps to the disclosed methods. Therefore, the following detailed description is not limited to the disclosed embodiments and examples. Rather, the appropriate scope of the invention is determined by the appended claims.
[0039] In the detailed description below, numerous specific details are set forth in order to provide a thorough understanding of certain aspects. However, those skilled in the art will understand that some aspects can be practiced without these specific details. In other instances, well-known methods, procedures, components, units, and / or circuits have not been described in detail to avoid obscuring the discussion.
[0040] As used herein, discussions of terms such as “receive,” “send,” “determine,” “maintain,” “roaming association,” “transfer,” “request,” “update,” “execute,” “trigger,” “establish,” “re-establish,” or similar terms may refer to the operation and / or processing of a computer, computing platform, computing system, or other electronic computing device that manipulates and / or converts data represented as physical (e.g., electronic) quantities in computer registers and / or memory into physical quantities in computer registers and / or memory or other information storage media that may store instructions for performing the operation and / or processing.
[0041] The use of terms such as “on one aspect,” “an aspect,” “example aspect,” and “various aspects” indicates that an aspect described in this way may include a specific feature, structure, or characteristic, but not every aspect necessarily includes the implementation of that specific feature, structure, or characteristic. Furthermore, the repeated use of the phrase “on one aspect” does not necessarily refer to the same aspect, although it may.
[0042] As used herein, unless otherwise stated, ordinal adjectives such as “first,” “second,” “third,” etc., are used to describe general objects only to indicate different instances of similar objects mentioned, and are not intended to imply that the objects described must have a given order in time, space, sequence, or any other way. Similarly, articles such as “a,” “an,” or “the” do not indicate a quantity limitation, but rather that at least one exists. Words such as “connection” and “link” are not limited to physical or mechanical connections, but also include direct or indirect electrical or communication connections.
[0043] Furthermore, the technical features involved in the different embodiments of this disclosure described below can be combined with each other, provided that there is no conflict between them.
[0044] In this disclosure, an AP, interchangeably referred to as a Wireless Access Point (WAP), is a communication device capable of communicating with non-access point (non-AP) devices (e.g., stations (STAs) or client devices) in a WLAN and allowing non-APs to connect to a wired network. An AP is typically connected to a router as a standalone device (e.g., via a wired network), but it can also be integrated with or used within a router. Similarly, in this disclosure, a non-AP (e.g., a client device or station, interchangeably referred to as a STA) is a communication device capable of communicating with an AP to obtain various communication services (such as voice, video, packet data, messaging, broadcasting, etc.). An STA can be any device containing a Media Access Control (MAC) and Physical Layer (PHY) interface compliant with the IEEE 820.11 standard to the wireless medium (WM). For example, an STA can be a laptop computer, desktop personal computer (PC), personal digital assistant (PDA), access point, or Wi-Fi phone in a WLAN environment. STAs can be fixed or mobile. In a WLAN environment, the terms "STA," "client device," "wireless client," "user," and "user equipment" are generally used interchangeably.
[0045] In this disclosure, a STA in a WLAN can function as an AP in different scenarios, and vice versa. This is because communication devices in the context of IEEE 820.11 (Wi-Fi) technology may include both STA and AP hardware components. In this way, the communication device can switch between STA mode and AP mode based on the actual WLAN conditions and / or requirements. In the various embodiments described below, a non-AP STA may refer to a STA in a WLAN that is not implemented as an AP.
[0046] Figure 1 An exemplary architecture 100 of a wireless communication system according to an embodiment of the present disclosure is illustrated. For example... Figure 1 As shown, the wireless communication system includes multiple AP devices (e.g., Figure 1 The system includes two access points (AP devices 101 and 102) and one client device 103, and can be used in an IEEE 802.11 WLAN network. The AP devices provide services to the client devices, and the client devices can communicate with the AP devices. Figure 1 The number of AP devices and client devices is just an example.
[0047] As discussed above, the AP can establish WLAN communication with client device 103, enabling the client device to connect to a wired network. This allows client device 103 to access various communication services from the Internet, including voice, video, packet data, messaging, and broadcasting. The client device in the embodiments of this disclosure has wireless transceiver functionality, supports the 802.11 family of protocols, and can communicate with the AP or another client device. After client device 103 successfully associates with the AP through the 802.11 association process, data transmission can begin between client device 103 and the AP. This allows client device 103 to send data packets to and receive data packets from the network via the AP. A client device is any user communication device that allows a user to communicate with the AP and thus with the WLAN. For example, a client device can be a user device that can connect to a network, including but not limited to, smartphones, tablets, desktop computers, laptops, notebooks, ultra-portable personal computers, handheld computers, netbooks, personal digital assistants, and other devices capable of connecting to the Internet; it can be an IoT node in the Internet of Things (IoT) or an in-vehicle communication device in the Internet of Vehicles (IoV). The AP device in the embodiments of this application is a device that serves client devices and can support the 802.11 series of protocols. For example, the AP device can be a communication entity such as a communication server, router, switch, or bridge, or the AP device can include various forms of macro base stations, micro base stations, repeaters, etc. Of course, the AP device can alternatively be a chip and processing system in various forms of devices to implement the methods and functions of the embodiments of this disclosure.
[0048] Figure 1 The architecture shown is illustrative only and does not impose any limitations on any implementation of this disclosure. Multiple access points (APs) in a WLAN network can serve a specific set of associated client devices, and the number of client devices in each service set can be greater than the single client device shown in the figure, depending on application requirements and overall network constraints.
[0049] The IEEE 802.11be standard introduced Multi-Link Operation (MLO) technology, in which a single device (i.e., a Multi-Link (ML) Device (MLD)) implements a logical entity consisting of multiple stations. Stations can use the 802.11 protocol to communicate with another MLD station on a corresponding communication link, thereby establishing a multi-link communication session to exchange data units (e.g., MPDUs). Therefore, an MLD can transmit messages simultaneously on multiple links to improve throughput.
[0050] In this article, “multilink device”, “ML device (MLD)”, “multilink logical entity”, “ML logical entity (MLE)”, “multilink set” and “ML set” can be used interchangeably.
[0051] A multi-link device is a device with wireless communication capabilities. This device can be an entire device or a chip, processing system, etc., installed within an entire device. Devices with these chips or processing systems installed can be controlled by these chips or processing systems to implement the methods and functions of the embodiments of this disclosure. In some embodiments of this disclosure, the AP device (e.g., Figure 1 The AP devices 101 and 102 described herein may be AP ML devices, and the client devices (e.g., Figure 1 The client device 103 depicted may be a non-AP ML device. Multilink devices can implement wireless communication compliant with the IEEE 802.11 family of protocols. For example, a multilink device may be a station compliant with or compatible with IEEE 802.11be and offering extremely high throughput to enable communication with other devices.
[0052] Figure 2 An exemplary multi-link reference model 200 for a multi-link (ML) device according to an embodiment of the present disclosure is illustrated.
[0053] Figure 2 The ML device illustrated can be an AP ML device or a non-AP ML device, and can be an initiator ML device (i.e., a device that sends data) or a receiver ML device (i.e., a device that receives data from an initiator ML device).
[0054] like Figure 2 As shown, the ML device includes a physical (PHY) layer 210, a MAC layer 220, a logical link control (LLC) layer 240, and an upper layer 250. The upper layer 250 may include applications that generate service data transmitted over multiple links by the MAC and PHY layers, or applications that use service data received over multiple links by the MAC and PHY layers. The PHY layer 210 includes multiple PHY layer blocks 212, 214, and 216 for the respective multiple links. The MAC layer 220 also includes multiple blocks 222, 224, and 226 for the respective multiple links.
[0055] The IEEE 802.11be standard focuses on the 802.11 physical layer (PHY) and MAC layer components in multi-link devices. For example... Figure 2As shown, MAC layer 220 also includes a Unified Upper MAC (UMAC) 230. UMAC 230 is responsible for link-independent MAC procedures such as segmentation, sequence number allocation, MPDU encryption / decryption, duplicate detection, dynamic link switching, and block acknowledgment scoring. It provides UMAC interfaces with link-specific blocks 222, 224, and 226 (forming a lower MAC sublayer, hence called LMAC), and provides a UMAC Service Access Point (SAP) to LLC layer 240 and upper layer 250. In other words, multiple STAs attached to a multi-link device share a single high MAC layer, while the low MAC layer and PHY layer are independent. It can be understood that multiple STAs attached to a multi-link device can alternatively be independent at the low MAC and PHY layers, or they can be independent at the high MAC layer.
[0056] although Figure 2 Three LMAC blocks and three PHY blocks are shown, but depending on the number of links the ML device can manage, another number of blocks may be considered. As an example, LMAC block 222 can be associated with, for example, a 2.4 GHz link via PHY block 212, LMAC layer 224 can be associated with, for example, a 5 GHz link via PHY block 214, and LMAC layer 226 can be associated with, for example, a 6 GHz link via PHY block 216. That is, each link can have associated LMAC blocks 222 / 224 / 226 that perform link-specific characteristics (such as channel access).
[0057] Figure 3 An exemplary multi-link communication device 300 according to an embodiment of the present disclosure is illustrated. For example... Figure 3 As shown, the multi-link AP logical entity 310 (e.g., AP MLD) may include multiple affiliated APs, such as AP STA 312, AP STA 314, and AP STA 316. Furthermore, as... Figure 3As shown, a multi-link non-AP logical entity 320 (e.g., a non-AP MLD) may include multiple associated non-AP STAs, such as non-AP STA 322, non-AP STA 324, and non-AP STA 326. The multi-link AP logical entity 310 and the multi-link non-AP logical entity 320 may be configured to form multiple communication channels or links, set up multiple communication channels or links, and / or communicate through multiple communication channels or links, such as link 332 between STA 312 and STA 322 (as shown in link 1), link 334 between STA 314 and STA 324 (as shown in link 2), and / or link 336 between STA 316 and STA 326 (as shown in link 3). The term "link" is used for better consistency with the IEEE 802.11 standard. AP STA 312, 314, 316 and non-AP STA 3222, 324, 326 operate in accordance with one or more IEEE 802.11 standards and other wireless communication standards.
[0058] like Figure 3 As shown in the exemplary embodiments, AP STAs 312, 314, 316 (and thus the corresponding non-AP STAs 322, 324, 326) can operate in different frequency bands (shown as X, Y, Z). For example, X = 2.4 GHz, Y = 5 GHz, Z = 6 GHz. Alternatively, two or more stations can use the same frequency band, for example, y = z = 6 GHz.
[0059] although Figure 3 The diagram illustrates the establishment of an ML communication session using an AP MLD and non-AP MLDs, but two non-AP MLDs can also establish such an ML communication session. Similarly, although... Figure 3 The example shown consists of an MLD with three stations, but MLDs with other numbers of affiliated stations can be considered using the same teachings. Furthermore, MLDs can have different numbers of affiliated stations.
[0060] To reduce service interruption time when client devices switch between access points in traditional Wi-Fi roaming mechanisms, the IEEE 802.11r amendment initially proposed the Fast Basic Service Set (BSS) Transfer (FT) roaming mechanism, employing both Over-the-Air and Over-the-DS methods. However, existing roaming mechanisms, including the FT roaming mechanism, still require further improvement, as described below.
[0061] Figure 4 A schematic diagram illustrating a roaming process according to an embodiment of this disclosure is shown. Figure 4 As shown, the STA initially connects with the AP device (i.e., Figure 4 The current AP in the network, which can also be called the Home AP (HAP), is associated with the network and communicates with the network by successfully having a session and transmitting data with the current AP.
[0062] When the STA determines that it must switch to another AP device for various reasons (i.e., Figure 4 When the target AP in the network is a stranger AP (FAP), it will directly send a roaming request to the target AP, such as... Figure 4 As shown in step S402, this is done over-the-air. In some implementations (e.g., FT roaming), along with the roaming request, the security key PMK-R1 is sent to the target AP. Upon receiving the roaming request, the target AP can generate and install the corresponding security key PTK based on the information contained therein and the security key PMK-R1, and simultaneously start a reassociation timer. Then, as... Figure 4 As shown in step S404, the target AP sends a roaming response to the STA. Upon receiving the roaming response, the STA generates and installs the security key PTK. Then, the STA sends a roaming association request to the target AP, as follows: Figure 4 The steps are shown in step S406.
[0063] Upon receiving the roaming association request, the target AP cancels the reassociation timer and sends a roaming association response to the STA, such as... Figure 4 As shown in step S408, after receiving the roaming association response, the STA completes roaming, thereby establishing a successful session and data transmission with the target AP to communicate with the network.
[0064] and Figure 4 The Over-the-Air roaming process shown is similar; the Over-the-DS roaming process (not shown) also includes... Figure 4 The difference between steps S406-S408 and steps S402-S404 is that during Over-the-DS roaming, the STA sends a roaming request to the current AP, which forwards the roaming request to the target AP via the distributed system (DS). Similarly, the target AP sends a roaming response to the current AP via the DS, and the current AP forwards the roaming response to the STA.
[0065] When the client device (e.g., Figure 4 STA) and AP devices (e.g., Figure 4When a new AP (currently associated with a target AP) is associated with a client device, for downlink (DL) data transmission from the AP to the client device, data packets are first buffered in the AP device, and then the buffered data packets in the AP device are transmitted to the client device. In this document, the term "data packet" may refer to "data frame," etc. During roaming, when the STA sends a roaming request to the target AP, DL data transmission may be interrupted, and some data packets buffered in the current AP may not be transmitted to the STA. Figure 4 The target AP can only send data packets to the STA after establishing an association with it; that is, the STA re-associates with the new AP. It can be seen that during the roaming process, DL data transmission to the STA is interrupted, causing data transmission delays and loss of buffered data. Furthermore, after the STA associates with the new AP, its service requirements necessitate re-establishing some service states with the new AP (i.e., service negotiation) before data transmission can occur, resulting in transmission delays. Those skilled in the art will recognize that transmission delays and buffered data loss exist in traditional roaming mechanisms, including but not limited to FT roaming mechanisms and many other roaming mechanisms conforming to the IEEE 802.11 protocol.
[0066] To mitigate transmission latency and buffered data loss during roaming, this disclosure proposes an improvement to the current roaming mechanism, which ensures accurate and low-latency data transmission during roaming through context transfer. Specifically, the STA selects different transfer modes (e.g., static transfer mode and dynamic transfer mode) based on actual conditions (e.g., service requirements and communication conditions) to transfer the context from the current AP to which the STA is currently associated, to the target AP to which the STA intends to associate. The context is the communication context between the STA and the current AP. The STA triggers the context transfer and notifies the target AP which transfer mode to use. Based on the received transfer mode instruction, the current AP transfers the context to the target AP. By transferring service information as context in advance, the time required for the STA and the target AP to re-establish the necessary service negotiation is reduced, thereby reducing roaming latency. Furthermore, by transferring information about transmitted data as context in advance, the correct data packets are sent, thus mitigating data packet loss issues.
[0067] Figure 5 A schematic diagram illustrating a roaming preparation process 500 according to an embodiment of this disclosure is shown. Figure 5 As shown, there exists a non-AP MLD, a current AP MLD, a target AP MLD, and a distributed system (DS). The non-AP MLD, current AP MLD, and target AP MLD can be adopted with reference to... Figure 2The described multi-link reference model 200 is essentially similar to the multi-link reference model, and the non-AP MLD can be compared with the reference model. Figure 3 The described multi-link communication arrangement 300 is essentially a multi-link communication arrangement with either the current AP MLD or the target AP MLD. Furthermore, similar references... Figure 4 The described roaming process, non-AP MLD (which is similar to Figure 4 STA in the initial and current AP MLD (and its Figure 4 (Similar to the current AP in the context), that is, it is served by the current AP MLD.
[0068] like Figure 5 As shown, the non-AP MLD initially associates with the current AP MLD and interacts with the distributed system (DS) for uplink (UL) and downlink (DL) data through the current AP MLD. For example, after the non-AP MLD and the current AP MLD learn that the link connection between them is poor, either the non-AP MLD or the current AP MLD can determine that the non-AP MLD needs to be switched to another AP device, for example... Figure 5 The target AP MLD. In some embodiments of this disclosure, a non-AP MLD can actively choose which AP MLD it roams to. Additionally or alternatively, the current AP MLD can send a Basic Service Set (BSS) Transition Management (BTM) message to trigger roaming of a non-AP MLD, for example, to notify the non-AP MLD which AP MLD it roams to.
[0069] When determining the target AP MLD, the non-AP MLD can also determine the transfer mode of the context for transferring communication between the non-AP MLD and the current AP MLD from the current AP MLD to the target AP MLD. After determining that the non-AP MLD will switch to the target AP MLD, the non-AP MLD can send a roaming preparation request frame to the current AP MLD, such as... Figure 5 As shown in step S502, the current AP MLD is triggered to transfer the context to the target AP MLD. In some embodiments, a roaming preparation request frame can trigger the roaming preparation process. In some embodiments of this disclosure, the roaming preparation request frame may include an indication of the determined transfer mode. In some embodiments of this disclosure, the roaming preparation request frame may include an Add Block Acknowledgment (ADDBA) context transfer request element indicating whether an ADDBA context transfer is to be performed. In some embodiments of this disclosure, the roaming preparation request frame may be a roaming request frame (e.g., an FT request frame).
[0070] Upon receiving a roaming preparation request frame, the current AP MLD transfers the communication context between the current AP MLD and the non-AP MLD to the target AP MLD according to the determined transfer mode, such as... Figure 5 The steps are shown in step S506. In some embodiments of this disclosure, the context transfer mode may include a simple context transfer mode and an advanced context transfer mode. In some embodiments, in response to the determined transfer mode being a simple context transfer mode, the current AP MLD may transfer a first context containing static parameters to the target AP MLD in step S506. Therefore, the simple context transfer mode may also be called a static transfer mode. In some embodiments of this disclosure, the static parameters may only correspond to the parameters that need to be negotiated during the initial association process between the target AP MLD and the non-AP MLD, and do not include the parameters that are dynamically updated during subsequent data communication processes between the non-AP MLD and the current AP MLD. In some embodiments of this disclosure, the static parameters may include, but are not limited to: Block Acknowledgment (BA) establishment parameters, Flow Classification Service (SCS) / Mirror Flow Classification Service (MSCS) establishment parameters, or Target Wake-up Time (TWT) establishment parameters, etc.
[0071] In some embodiments of this disclosure, the first context containing static parameters may be referred to as a context transfer request frame. Figure 13 A schematic diagram illustrating the frame format of a context transfer request frame 1300 according to an embodiment of this disclosure is provided. (See reference...) Figure 13The context transfer request frame 1300 may include a category field, a context transfer action field, a roaming token field, and an ADDBA static context transfer parameter field. The category field indicates the service category. The context transfer action field indicates whether this frame is a context transfer request frame or a context transfer response frame. The roaming token field indicates whether roaming is performed. The ADDBA static context transfer parameter field may include a non-AP MLD media access control (MAC) address, a peer static DL ADDBA context field, and a peer static UL ADDBA context field. In some implementations, the DL ADDBA context field may include a start sequence number subfield to indicate the sequence number of the first or next data unit to be transmitted via the downlink. The peer static DL ADDBA context field may include a DL Block Ack Parameter Set field and a DL Block Ack Timeout Value field. The peer-to-peer static UL ADDBA context fields may include a UL Block Ack Parameter Set field, a UL Block Ack Timeout Value field, etc. In some implementations, the UL ADDBA context fields may include a start sequence number subfield to indicate the sequence number of the first or next data unit to be transmitted via the uplink. In some implementations, the UL ADDBA parameter set fields may include an A-MSDU (Aggregate MAC Service Data Unit) Supported field, a Block Ack Policy field, a Service Identifier (TID) field, a Buffer Size field, etc. The A-MSDU Supported field indicates whether A-MSDUs are supported in Quality of Service (QoS) data frames transmitted under the BA protocol.The BA policy field indicates the block acknowledgment mechanism, such as Normal Ack, Implicit Block Ack, Explicit Block Ack, Delayed Block Ack, Immediate Block Ack, and High Throughput Immediate Block Ack (HT-immediate block ack). The Service Identifier (TID) field indicates the service category or service flow requesting the current BA frame. The Buffer Size field indicates the amount of buffer available for this specific TID. In static transfer mode, because the transfer context does not contain information such as the next sequence number (SN) that changes with data transmission, the information content of the transfer context is low. The sequence number (SN) of data transmitted between a non-AP MLD and the current AP MLD may be discontinuous with the SN of data transmitted between a non-AP MLD and the target AP MLD. The target AP MLD resets the start sequence number (SSN) before starting data transmission.
[0072] In other embodiments, in response to the determined transfer mode being a higher-order context transfer mode, in addition to transferring a first context containing static parameters to the target AP MLD in step S506, the current AP MLD can also transfer a second context containing dynamic parameters to the target AP MLD during the roaming process (e.g., during roaming execution). Therefore, the higher-order context transfer mode can also be referred to as a dynamic transfer mode. During roaming, as data packets are transmitted between the current AP MLD and the non-AP MLD, the dynamic parameters regarding the transmission of data packets are continuously updated between the non-AP MLD and the current AP MLD. In some embodiments of this disclosure, the dynamic parameters may correspond to parameters that are dynamically updated during roaming as data communication occurs between the non-AP MLD and the current AP MLD. In some embodiments of this disclosure, the dynamic parameters may include, but are not limited to, the sequence number (SN) of the data packet to be transmitted, the bitmap of the data packet, etc.
[0073] In some embodiments of this disclosure, the second context containing dynamic parameters may also be referred to as a context transfer request frame. Figure 14 A schematic diagram illustrating the frame format of a context transfer request frame 1400 according to another embodiment of this disclosure is shown. (See reference) Figure 14The context transfer request frame 1400 may include a category field, a context transfer action field, a roaming token field, and an ADDBA dynamic context transfer parameter field. The category field indicates the service category. The context transfer action field indicates whether the frame is a context transfer request frame or a context transfer response frame. The roaming token field indicates whether roaming is performed. The ADDBA dynamic context transfer parameter field may include a non-AP MLD MAC address, a Peer Dynamic DL ADDBA context field, and a Peer Dynamic UL ADDBA context field. The Peer Dynamic DL ADDBA context field may include a Specific Service Identifier (TID), a Next Sequence Number (Next SN), etc. The Peer Dynamic UL ADDBA context field may include a Specific Service Identifier (TID), a Next Sequence Number (Next SN), a scoreboard, etc. The Specific Service Identifier indicates the Service Identifier (TID) to align with the TID in the ADDBA static context transfer parameter field. The Next Sequence Number indicates the next data packet to be transmitted. The scoreboard includes an acknowledgment bitmap that contains the current reception status of data units in the BA protocol. In dynamic transfer mode, due to the dynamic transfer of dynamic parameters such as the next SN and bitmap-related information and the forwarding of data, the target AP MLD can continue using the SN currently used by the AP MLD, ensuring data reliability before and after roaming.
[0074] After receiving the first context in step S506, the target AP MLD can send a context transfer response frame to the current AP MLD, such as... Figure 5 As shown in step S508, the context transfer response frame indicates the transfer status of the sent context. The context transfer status can indicate that the first context was transferred successfully in its entirety, a portion of the first context was transferred successfully (i.e., a portion was not transferred successfully), or the first context was transferred unsuccessfully in its entirety.
[0075] Upon receiving a context transfer response frame indicating that the first context transfer was successful, the current AP MLD can send a roaming preparation response frame to the non-AP MLD, such as... Figure 5 The step S504 is shown. The roaming preparation response frame is generated at least in part based on the context transfer response frame. After receiving the roaming preparation response, the non-AP MLD simultaneously establishes a link with the current AP MLD and a link with the target AP MLD.
[0076] If the received context transfer response frame indicates that a portion of the first context failed to transfer, since the roaming preparation process is still ongoing, communication between the non-AP MLD and the current AP MLD will continue, thus preventing data interruption. The current AP MLD can then send the portion of the first context that failed to transfer to the target AP MLD, such as... Figure 6 The steps are as follows: After receiving the portion of the first context that failed to transfer in step S610, the target AP MLD can send a context transfer response back to the current AP MLD, such as... Figure 6 The steps are shown in step S612. Figure 6 A schematic diagram illustrating a roaming preparation process 600 according to another embodiment of the present disclosure is shown, wherein steps S602-S608 are... Figure 5 Steps S502-S508 shown are similar and will not be repeated here. Although Figure 6 Compared to Figure 5 Only steps S610-S612 have been added; however, those skilled in the art will understand that the context transfer response frame received in step S612 may still indicate that a portion of the context transfer was unsuccessful. In this case, steps S610-S612 can be repeated. In some implementations, the current AP MLD can also record the number of times a retransmission fails to completely transfer the first context. If this number exceeds a preset threshold, seamless roaming selection is exited, and the service for which the parameters included in the first context are renegotiated after roaming ends. In other implementations, if this number exceeds a preset threshold, seamless roaming selection is exited, and another more suitable candidate AP MLD is selected for roaming.
[0077] exist Figure 5 and Figure 6 In the illustrated implementation, the current AP MLD interacts directly with the target AP MLD over-the-air. For example, the current AP MLD sends a context to the target AP MLD in steps S506, S606, and S610, and the target AP MLD sends a context transfer response frame to the current AP MLD in steps S508, S608, and S612. Alternatively, the current AP MLD can interact with the target AP MLD over-the-DS, i.e., via a distributed system (DS).
[0078] As described above, before sending a roaming preparation request frame to the current AP MLD, the non-AP MLD needs to determine the context transfer mode for transferring communication between the non-AP MLD and the current AP MLD from the current AP MLD to the target AP MLD. Since different communication service types have different service requirements, the context transfer mode can be selected according to these requirements.
[0079] In some application scenarios (e.g., high-definition live streaming, augmented reality (AR) / virtual reality (VR), etc.), the requirements for communication services are high traffic volume (e.g., communication traffic volume exceeds a first traffic threshold), low latency (e.g., latency requirement is less than or equal to a first latency threshold), and relatively low reliability requirements (e.g., reliability requirement is less than or equal to a first reliability threshold). For this type of communication service (which can be referred to as Type 1 in this paper), it is necessary to prioritize high-traffic, low-latency roaming. Therefore, non-AP MLDs can choose a static transfer mode as the transfer mode for transferring the communication context between the current AP MLD and non-AP MLDs, completing the roaming as quickly as possible.
[0080] In some application scenarios (e.g., video downloads), the communication service requirements are high traffic volume (e.g., traffic volume exceeds a second traffic threshold), high reliability (e.g., reliability requirements exceed a second reliability threshold), and relatively low latency requirements (e.g., latency requirements exceed a second latency threshold). For this type of communication service (which can be referred to as the second type in this paper), it is necessary to prioritize high-traffic, high-reliability roaming. Therefore, to ensure reliability during roaming, non-AP MLDs can choose a dynamic transfer mode as the transfer mode for transferring the communication context between the current AP MLD and the non-AP MLD.
[0081] In other application scenarios (e.g., online games), the requirements for communication services are low traffic (e.g., communication traffic less than or equal to the third traffic threshold), low latency (e.g., latency requirement less than or equal to the third latency threshold), and high reliability (e.g., reliability requirement greater than the third reliability threshold). For this type of communication service (which can be referred to as the third type in this paper), it is necessary to prioritize high-reliability, low-latency roaming. Therefore, to ensure reliability during roaming, non-AP MLDs can choose a dynamic transfer mode as the transfer mode for transferring the context of communication between the current AP MLD and the non-AP MLD.
[0082] Those skilled in the art should understand that the first flow threshold, the second flow threshold, and the third flow threshold may be the same or different values, the first delay threshold, the second delay threshold, and the third delay threshold may be the same or different values, and the first reliability threshold, the second reliability threshold, and the third reliability threshold may be the same or different values.
[0083] Note that the context transfer capabilities supported by the current AP MLD and the target AP MLD may differ. For example, if the block acknowledgment (BA) policy established between the current AP MLD and a non-AP MLD uses a cache size of 1024 data packets, but the target AP MLD does not support a BA policy with a cache size of 1024 data packets, the context transfer will fail. In this case, the non-AP MLD may need to renegotiate the BA policy with the target AP MLD or select another AP MLD that supports the current BA policy after the context transfer fails. However, both of these methods occur after the context transfer fails, resulting in significant latency. Some embodiments of this disclosure propose that the non-AP MLD obtain the capability information of neighboring AP MLDs during the discovery phase, thereby enabling the non-AP MLD to select the most suitable neighboring AP MLD as the target AP MLD based on the neighboring AP MLD's capability information, minimizing performance degradation caused by roaming.
[0084] To expedite the discovery process, non-AP MLDs no longer perform off-channel scanning but instead directly obtain information about their neighboring AP MLDs from the current AP MLD. Furthermore, since the information carried in the beacon is already excessive and adding more content is not advisable, some embodiments of this disclosure propose that non-AP MLDs obtain information about their neighboring AP MLDs from the current AP MLD through a probing or BTM process.
[0085] Figure 7 A schematic diagram illustrating a detection process 700 according to an embodiment of this disclosure is shown. Figure 7 As shown, there exist non-AP MLDs, current AP MLDs, neighboring AP MLDs, and a distributed system (DS). Non-AP MLDs, current AP MLDs, and neighboring AP MLDs can be adopted with reference to... Figure 2 The described multi-link reference model 200 is essentially similar to the multi-link reference model, and non-APMLD can be compared with the reference model. Figure 3 The described multi-link communication arrangement 300 is essentially a similar multi-link communication arrangement to either the current AP MLD or the target AP MLD.
[0086] In step S702, a non-AP MLD sends a neighbor probe request to the current AP MLD to request information about neighboring AP MLDs. In some embodiments, in response to receiving a neighbor probe request, the current AP MLD may send a capability probe request to one or more neighboring AP MLDs, step S706; then in step S708, the neighboring AP MLD that received the capability probe request sends capability feedback indicating its capabilities to the current AP MLD. Those skilled in the art will understand that the current AP MLD sending capability probe requests to neighboring AP MLDs and the neighboring AP MLDs sending capability feedback to the current AP MLD can be done via Over-the-Air or Over-the-DS methods. In response to a neighbor probe request, for example, after receiving capability feedback from one or more neighboring AP MLDs, the current AP MLD sends a neighbor probe response to a non-AP MLD, step S704. Figure 7 As shown, steps S706 and S708 are optional. For example, in some embodiments, in response to receiving a neighbor probe request, in step S704, the current AP MLD sends the cached neighbor AP information therein to the non-AP MLD via a neighbor probe response. The cached neighbor AP information is previously obtained by the current AP MLD, for example, through a method similar to steps S706 and S708. In embodiments without steps S706 and S708, the neighbor probe response is faster, reducing the time required for the discovery process, but the cached neighbor AP information may be outdated. In embodiments including steps S706 and S708, although the neighbor probe response is slower, the provided neighbor AP information is more timely and therefore more accurate.
[0087] In some embodiments of this disclosure, a neighbor probe request sent by a non-AP MLD to the current AP MLD includes an indication of the response speed to the neighbor probe response. In some embodiments, the neighbor probe request includes a fast response indication or a precise response indication. In some examples, if the received neighbor probe request includes a fast response indication, the current AP MLD will include cached neighbor AP information in the neighbor probe response. In other examples, if the received neighbor probe request includes a precise response indication, the current AP MLD will include information about the neighbor AP MLD probed to the neighbor AP MLD in response to the neighbor probe request in the neighbor probe response. In some embodiments, the neighbor probe request includes an indication of the expiration time of the neighbor probe response. In some examples, if the expiration time of the neighbor probe response is less than or equal to a preset time threshold, the current AP MLD will include cached neighbor AP information in the neighbor probe response. In other examples, if the expiration time of the neighbor probe response is greater than a preset time threshold, the current AP MLD will include information about the neighbor AP MLD probed to the neighbor AP MLD in response to the neighbor probe request in the neighbor probe response.
[0088] In current IEEE 802.11 standards, the Neighbor Probe Response (NPPR) frame includes a Reduced Neighbor Report (RNR) element to transmit information about the neighboring AP MLD. To select the optimal neighboring AP MLD as the target AP MLD for roaming association, the RNR element can be modified, for example, by adding additional information.
[0089] Figure 15 A schematic diagram illustrating the format of an RNR element 1500 according to an embodiment of this disclosure is shown. Figure 15 As shown, RNR element 1500 includes an element ID field, a length field, and a Neighbor AP Information Fields field. The Neighbor AP Information Fields field contains one or more neighbor AP information fields, each corresponding to information about a single neighbor AP. Each neighbor AP information field includes a target beacon transmission time (TBTT) packet header subfield, an operation level subfield, a channel number subfield, and a TBTT information set subfield. For simplicity, content in RNR element 1500 that is identical to that in the current IEEE 802.11 standard's RNR elements will not be repeated here. Figure 15The difference between RNR element 1500 in RNR element 1500 and the RNR element in the current IEEE 802.11 standard is that the BSS parameter subfield of the TBTT information set subfield has an added Same Seamless Mobility Domain (SMD) bit. When the Same SMD bit is "1", it indicates that the reported AP MLD (i.e., the neighboring AP MLD corresponding to the TBTT information set subfield) and the reporting AP MLD (i.e., the current AP MLD) are in the same SMD; otherwise, they are in different SMDs. Furthermore, the TBTT information set subfield of RNR element 900 has an added SMD parameter subfield. If the Same SMD bit is "1", the SMD parameter subfield must contain supporting information indicating the roaming-related capabilities of the reported AP MLD, such as the AP inter-AP data forwarding capability support bit and the resource reservation capability support bit.
[0090] In addition, the TBTT Information Set subfield of NR element 1500 adds an Authentication and Key Management (AKM) Suite Bitmap subfield, which identifies the AKM suites supported by the reported AP MLD, such as Enterprise Key Suite, Pre-Shared (PSK) Key Suite, Open Source Key Suite, Wi-Fi Protected Access (WPA) Key Suite, WPA2 Key Suite, WPA3 Key Suite, Wired Equivalent Privacy (WEP) Key Suite, etc., where the index of the bitmap represents the value of the suite type in the AKM Suite Selector. AKM suites identify the security capabilities of the reported AP MLD. In some embodiments, the security level of AKM suites is: Enterprise Key Suite > PSK Key Suite > Open Source Key Suite; WPA3 Key Suite > WPA2 Key Suite > WPA Key Suite > WEP Key Suite.
[0091] SMD-related capabilities and AKM suites required for roaming, such as SMD bits and SMD parameter subfields, are inherent capabilities of the reported AP MLD and do not change over a long period. In addition, there are frequently changing parameters that help non-AP MLDs determine the latest operational status of the reported AP MLD and can be referred to as dynamic information. Therefore, a dynamic parameter subfield has been added to the TBTT information set subfield of NR element 1500. In some embodiments of this disclosure, the dynamic parameter subfield may include BSS operating bandwidth, channel utilization, site count, association permission, and a timestamp of the information. The BSS operating bandwidth indicates the bandwidth currently operating on the reported AP MLD; the channel utilization indicates the congestion status of the channel currently operating on the reported AP MLD; the site count indicates the number of clients currently connected to the reported AP MLD; the association permission indicates whether the reported AP MLD allows association; and the timestamp of the information indicates the generation time of the dynamic parameters so that non-AP MLDs or the current AP MLD can determine whether the acquired dynamic parameters have expired.
[0092] As mentioned above, non-AP MLDs can also obtain information about neighboring AP MLDs through the BSS handover management (BTM) process. Figure 8 A schematic diagram illustrating a BTM process 800 according to an embodiment of this disclosure is shown. Figure 8 As shown, there exist non-AP MLDs, current AP MLDs, neighboring AP MLDs, and a distributed system (DS). Non-AP MLDs, current AP MLDs, and neighboring AP MLDs can be adopted with reference to... Figure 2 The described multi-link reference model 200 is essentially similar to the multi-link reference model, and the non-AP MLD can be compared with the reference model. Figure 3 The described multi-link communication arrangement 300 is essentially a similar multi-link communication arrangement to either the current AP MLD or the target AP MLD.
[0093] In step S802, the non-AP MLD sends a BTM query request to the current AP MLD to request information about neighboring AP MLDs. In some embodiments, the BTM query request may include a BSS handover candidate list item field to indicate the non-AP MLD's handover preferences. This field includes zero or more Neighbor Report (NR) elements, each NR element corresponding to a neighboring AP MLD. In some embodiments, in response to receiving the BTM query request, the current AP MLD may send a capability probe request to one or more neighboring AP MLDs (step S806); then in step S808, the neighboring AP MLD that received the capability probe request sends capability feedback indicating its capabilities to the current AP MLD. Those skilled in the art will understand that the current AP MLD sending capability probe requests to neighboring AP MLDs and the neighboring AP MLDs sending capability feedback to the current AP MLD can be done via Over-the-Air or Over-the-DS methods. In response to the BTM query request, for example, after receiving capability feedback from one or more neighboring AP MLDs, the current AP MLD sends a BTM request to the non-AP MLD (step S804). In some embodiments, the current AP MLD can recommend one or more neighboring AP MLDs from the set of neighboring AP MLDs as candidate AP MLDs for the non-AP MLD to roam with, based on the acquired capability information of neighboring APs. The neighbor BTM request can include a BSS handover candidate list item field to indicate the recommended candidate AP MLD; this field includes zero or more NR elements. In response to the BTM request, the non-AP MLD sends a BTM response to the non-AP MLD, in step S805, indicating the target AP MLD it wants to roam with.
[0094] Similarly, such as Figure 8 As shown, steps S806 and S808 are optional. For example, in some embodiments, in response to receiving a BTM query request, in step S804, the current AP MLD sends the cached neighbor AP information therein to the non-AP MLD via a neighbor probe response. The cached neighbor AP information is previously obtained by the current AP MLD, for example, through a method similar to steps S806 and S808. In embodiments without steps S806 and S808, the neighbor probe response is faster, reducing the time required for the discovery process, but the cached neighbor AP information may be outdated. In embodiments including steps S806 and S808, although the neighbor probe response is slower, the provided neighbor AP information is more timely and therefore more accurate.
[0095] In some embodiments of this disclosure, a BTM query request sent by a non-AP MLD to the current AP MLD includes an indication of the response speed to the neighbor probe response. In some embodiments, the BTM query request includes a fast response indication or a precise response indication. In some examples, if the received BTM query request includes a fast response indication, the current AP MLD will include cached neighbor AP information in the BTM request. In other examples, if the received BTM query request includes a precise response indication, the current AP MLD will include information about the neighbor AP MLD probed to the neighbor AP MLD in response to the BTM query request in the BTM request. In some embodiments, the BTM query request includes an indication of the expiration time of the BTM request. In some examples, if the expiration time of the BTM request is less than or equal to a preset time threshold, the current AP MLD will include cached neighbor AP information in the BTM request. In other examples, if the expiration time of the BTM request is greater than a preset time threshold, the current AP MLD will include information about the neighbor AP MLD probed to the neighbor AP MLD in response to the BTM query request in the BTM request.
[0096] In current IEEE 802.11 standards, BTM query frames include a BSS handover query reason field, which contains a reason code for the BSS handover management query. Values 0-20 in the BSS handover query reason field are used, while values 21-255 are reserved. In some embodiments of this disclosure, value 21 (or other values from 21-255) of the BSS handover query reason field can be defined as a neighbor report query to indicate that the purpose of the BTM query frame is to query information about the neighbor AP MLD. Additionally or alternatively, two values from 21-255 of the BSS handover query reason field can be defined as a fast neighbor report query and a precise neighbor report query, respectively, corresponding to the fast response indication and precise response indication mentioned above.
[0097] Figure 9 A schematic diagram illustrating a BTM process 900 according to another embodiment of this disclosure is shown. Figure 8 Unlike other methods, the current AP MLD can send an unsolicited BTM request to a non-AP MLD without receiving a BTM query request, step S904. Apart from this, steps S904, S906, and S908 in BTM process 900 are similar to steps S804, S806, and S808 in BTM process 800, and will not be repeated here.
[0098] In current IEEE 802.11 standards, as mentioned above, the BTM request frame includes an NR element to transmit information about candidate AP MLDs. To select the optimal neighboring AP MLD as the target AP MLD for roaming association, the NR element in the BTM request frame can be improved, for example, by adding additional information.
[0099] Figure 16 A schematic diagram illustrating the format of a neighbor reporting element 1600 according to an embodiment of this disclosure is shown. Figure 16 As shown, NR element 1600 includes an element ID field, a length field, a BSSID field, a BSSID information field, an operation level field, a channel number field, a PHY type field, and optional sub-element fields. For the sake of brevity, the contents of NR element 1600 that are the same as those in the current IEEE 802.11 standard NR element will not be repeated here. Figure 16The difference between NR element 1600 in the current IEEE 802.11 standard and NR element 1600 is that the BSSID information field adds a Same Seamless Mobility Domain (SMD) bit. When the Same SMD bit is "1", it indicates that the reported AP MLD (i.e., the neighboring AP MLD corresponding to NR element 1600) and the reporting AP MLD (i.e., the current AP MLD) are in the same SMD; when the Same SMD bit is "0", it indicates that the reported AP MLD and the reporting AP MLD are in different SMDs. If the Same SMD bit is "1", the optional sub-element fields add an SMD parameter sub-field, an Authentication and Key Management (AKM) suite bitmap sub-field, and a dynamic parameter sub-field. The SMD parameter sub-field identifies roaming-related information of the reported AP MLD within the SMD, such as the AP inter-AP data forwarding capability support bit and resource reservation capability support bit. If the Same SMD bit is "0", the optional sub-element fields add an SMD sub-field to identify the SMD ID of the reported AP MLD and roaming-related information within the SMD. The AKM kit bitmap subfield and dynamic parameter subfield in NR element 1600 are similar to those in RNR element 1500, and will not be described again here.
[0100] As described above, in response to a BTM request, a non-AP MLD sends a BTM response to another non-AP MLD, indicating that it wants to roam to the associated target AP MLD. In some embodiments of this disclosure, when the communication service of a non-AP MLD belongs to the first type mentioned above (i.e., high traffic, low latency, and relatively low reliability requirements), the non-AP MLD selects a neighboring AP MLD with stronger AP MLD-level capabilities as the target AP MLD. In some embodiments, the target AP MLD selected by the non-AP MLD meets one or more of the following criteria: the target AP MLD is a candidate AP MLD recommended by the current AP MLD; the target AP MLD belongs to the same seamless mobility domain as the current AP MLD; the target AP MLD has a higher security level compared to other neighboring AP MLDs in the neighboring AP MLD set; the target AP MLD supports more Spatial Streams (NSS) compared to other neighboring AP MLDs in the neighboring AP MLD set; or the target AP MLD has a smaller communication load compared to other neighboring AP MLDs in the neighboring AP MLD set, etc.
[0101] Furthermore, in some embodiments of this disclosure, when the communication service of the non-AP MLD belongs to the second type mentioned above (i.e., high traffic, high reliability, and relatively low latency requirements), context transfer places higher demands on the interaction capabilities of the two AP MLDs. The non-AP MLD selects a neighboring AP MLD with stronger SMD-level capabilities and better dynamic capabilities as the target AP MLD. In some embodiments, the target AP MLD selected by the non-AP MLD meets one or more of the following criteria: the target AP MLD belongs to the same seamless mobility domain as the current AP MLD; the target AP MLD supports data transmission between APs; the target AP MLD supports resource reservation; the target AP MLD supports more NSS compared to other neighboring AP MLDs in the neighboring AP MLD set; or the target AP MLD has a smaller communication load compared to other neighboring AP MLDs in the neighboring AP MLD set, etc.
[0102] Furthermore, in some embodiments of this disclosure, when the communication service of the non-AP MLD belongs to the third type mentioned above (i.e., low traffic, high reliability, low latency), context transfer places higher demands on the interaction capabilities of the two AP MLDs. The non-AP MLD selects a neighboring AP MLD with stronger SMD level capabilities and better dynamic capabilities as the target AP MLD. In some embodiments, the target AP MLD selected by the non-AP MLD meets one or more of the following criteria: the target AP MLD belongs to the same seamless mobility domain as the current AP MLD; the target AP MLD supports data transmission between APs; the target AP MLD supports resource reservation; the target AP MLD is a candidate AP MLD recommended by the current AP MLD; the target AP MLD supports higher security levels compared to other neighboring AP MLDs in the neighboring AP MLD set; the target AP MLD has a smaller communication load compared to other neighboring AP MLDs in the neighboring AP MLD set; or the target AP MLD supports more NSS compared to other neighboring AP MLDs in the neighboring AP MLD set, etc.
[0103] As referenced above Figure 5 and Figure 6 As described, during the roaming preparation process, the non-AP MLD establishes a link with both the current AP MLD and the target AP MLD. After the non-AP MLD establishes a link with the target AP MLD, roaming from the current AP MLD to the target AP MLD can be initiated. Figure 10 A schematic diagram illustrating a roaming process 1000 according to an embodiment of this disclosure is shown. Figure 10As shown, there exists a non-AP MLD, a current AP MLD, a target AP MLD, and a distributed system (DS). The non-AP MLD, current AP MLD, and target AP MLD can be adopted with reference to... Figure 2 The described multi-link reference model 200 is essentially similar to the multi-link reference model, and the non-AP MLD can be compared with the reference model. Figure 3 The described multi-link communication arrangement 300 is essentially a similar multi-link communication arrangement to either the current AP MLD or the target AP MLD.
[0104] Similar to a reference Figure 4 In the described step S406, the non-AP MLD sends a roaming association request to the current AP MLD, such as... Figure 10 The steps are as follows: S1002. A roaming association request can trigger the roaming association process, and the roaming association request can be implemented by a roaming request or a roaming association request message / frame. In some implementations, the non-AP MLD and the current AP MLD learn during the roaming preparation process that the context transfer mode is dynamic transfer mode; additionally, in some implementations, the roaming association request includes an indication of the dynamic transfer mode. During the roaming association process, in response to the context transfer mode being dynamic transfer mode, the transmission of UL data between the non-AP MLD and the current AP MLD can be suspended. In some implementations, when sending the roaming association request, the non-AP MLD suspends sending UL data to the current AP MLD. In some implementations, after receiving the roaming association request, the current AP MLD suspends receiving UL data from the non-AP MLD. On the other hand, during the roaming association process, the transmission of DL data from the current AP MLD to the non-AP MLD is not suspended. For the DL data cached in the current AP MLD, some DL data has been assigned a sequence number (SN), and some DL data has not been assigned a SN. For DL data with an assigned SN, the current AP MLD will continue to send it to non-AP MLDs. By having the current AP MLD continue sending DL data with an assigned SN, data interruption time during roaming can be reduced.
[0105] Upon receiving a roaming association request, the current AP MLD can send a second context, as described previously and containing dynamic parameters (e.g., next SN and bitmap), to the target AP MLD, as shown in step S1004. In some implementations, the second context is sent in response to a dynamic transfer mode. Figure 10 In the illustrated embodiment, the second context may include ADDBA dynamic context transition parameters.
[0106] In step S1006, the current AP MLD forwards the cached UL data and the DL data without assigned SN to the target AP MLD. For ease of explanation, Figure 10 The example shows step S1006 following step S1004. Those skilled in the art will understand that step S1006 can be performed simultaneously with step S1004, or it can begin before step S1004. By forwarding the UL data cached in the current AP MLD to the target AP MLD, the loss of UL data during roaming is minimized.
[0107] Before switching the mapping associations stored in the distributed system (DS), the DS still records the mapping relationship between the current AP MLD and the non-AP MLD. Therefore, the DS will send the new DL data to the current AP MLD, as shown in step S1008. After receiving the DL data in step S1008, the current AP MLD will forward the received new DL data to the target AP MLD for caching, as shown in step S1010. Similarly, Figure 10 The exemplary illustration shows steps S1008 and S1010 following steps S1004 and S1006. Those skilled in the art should understand that steps S1008 and S1010 can be performed simultaneously with steps S1004 and S1006, or can begin before steps S1004 and S1006.
[0108] Then, in step S1012, the target AP MLD sends a DS mapping to the DS, indicating the mapping relationship between the non-AP MLD and the target AP MLD. As an example, the target AP MLD can send a mapping request to the DS, for example, a DS-STA-Notify.request primitive carrying mapping information between the target AP MLD and the non-AP MLD. The DS-STA-Notify.request primitive is used to notify the DS of the STA-AP mapping information. This is because each non-AP MLD can be associated with only one AP MLD. The DS must know which AP MLD serves the non-AP MLD and then deliver data packets whose destination address is the MAC address of the non-AP MLD to the corresponding AP MLD. In other words, the DS can deliver data packets whose destination address is the MAC address of the non-AP MLD to the target AP MLD after it knows that the target AP MLD serves the non-AP MLD.
[0109] In some embodiments of this disclosure, the DS-STA-Notify.request primitive may carry the Service Access Point (SAP) MAC address of a non-AP MLD and an update type. The update type may include three types: ADD, MOVE, and DELETE. ADD is used in the DS-STA-Notify.request primitive sent by the AP MLD when the non-AP MLD is first associated with a specific AP MLD. DELETE is used in the DS-STA-Notify.request primitive sent by the AP MLD when the non-AP MLD is first unassociated with a specific AP MLD. MOVE is used in the DS-STA-Notify.request primitive sent by the AP MLD when the non-AP MLD switches from a specific AP MLD to a new AP MLD.
[0110] It can be seen that, in Figure 10 In the implementation scheme, the update type carried in the DS-STA-Notify.request primitive sent by the target AP MLD is MOVE. When the client is not an AP MLD, the MAC address in the DS-STA-Notify.request primitive sent by the target AP MLD is the SAP MAC address of the non-AP MLD.
[0111] During the DS mapping change, since the link between the non-AP MLD and the current AP MLD still exists, the current AP MLD continues to transmit the DL data with the assigned SN to the non-AP MLD until the DL data transmission with the assigned SN is completed, at which point the non-AP MLD will suspend DL data transmission with the current AP MLD. However, due to the DS mapping switch, UL data cannot be transmitted from the current AP MLD to the DS. Therefore, to prevent excessive data packet loss, as mentioned above, UL data transmission is suspended during the roaming association from the non-AP MLD to the target AP MLD. In some embodiments of this disclosure, from the perspective of the non-AP MLD, the non-AP MLD can suspend UL data transmission after sending the roaming association request in step S1002. In some embodiments of this disclosure, the current AP MLD can suspend receiving UL data from the non-AP MLD after receiving the roaming association request from the non-AP MLD or after sending the roaming association request to the target AP MLD.
[0112] After the DS mapping change is completed, in some embodiments, the DS can send an acknowledgment response (not shown) to the target AP MLD for the changed mapping to notify the target AP MLD that the DS mapping change is complete.
[0113] After the DS mapping change is completed, the DL data from the upper layer will be cached in the target AP MLD, as shown in step S1014. All data cached in the target AP MLD will be populated with SN and reordered by the target AP MLD.
[0114] In some implementations, after the DS mapping change is completed, the target AP MLD may send a roaming association response (not shown) to the current AP MLD. In some embodiments, the target AP MLD may send a roaming association response to the current AP MLD in response to an acknowledgment response for the changed mapping. Upon receiving the roaming association response, the current AP MLD replies to the non-AP MLD with a roaming association response for the roaming association request, as shown in step S1016, completing the roaming association process. In some implementations, the current AP MLD determines the data caching status, and the roaming association response sent by the current AP MLD to the non-AP MLD in step S1016 may be based on the target AP MLD reporting to the current AP MLD that it has completed SN filling and reordering of the cached data. For example, after completing the transmission of cached DL data with assigned SNs (i.e., all sent to the non-AP MLD) and completing the forwarding of cached UL data and DL data without assigned SNs, the current AP MLD replies to the non-AP MLD with a roaming association response. Alternatively or additionally, the current AP MLD determines whether a preset roaming association period has expired. If the preset roaming association period has expired, the current AP MLD sends a roaming association response to the roaming association request received in step S1002 to the non-AP MLD, regardless of whether the transmission of cached DL data therein has been completed. In some embodiments, the roaming association response sent in step S1016 includes an indication that the data transmission cached in the current AP MLD has been completed or that the preset roaming association period has expired. Afterward, the non-AP MLD can communicate with the target AP MLD for UL data and DL data. By forwarding unassigned SN DL data to the target AP MLD via the current AP MLD, which then reorders and continues transmission, data packet loss is reduced and data transmission latency during roaming is optimized.
[0115] Figure 11 A schematic diagram illustrating a downlink (DL) data transfer process 1100 according to an embodiment of this disclosure is shown. Figure 11 As shown, before the roaming process, because the DS mapping indicates the mapping relationship between the non-AP MLD and the current AP MLD, the DS caches the DL data from the upper layer into the current AP MLD. For example... Figure 11As shown in the table at the top left, these DL data have group indices: 61, 62, ..., M, ..., N. The current AP MLD will (e.g., when generating MPDU) assign corresponding sequence numbers SN to the DL data to be sent: 101, 102, ..., 100+M. The current AP MLD includes transmit buffer control, which uses WinStart. O As the starting sequence number of the sending window, WinSize O The number of caches negotiated in the block confirmation protocol and WinEnd O The WinEnd sequence number is used to suggest the DL data to be sent, where WinEnd is the end sequence number of the sending window. O =WinStart O +WinSize O -1. In Figure 11 In the example, since the previous BA indicated that the data packet at packet index 62 was not successfully transmitted, the transmission in this sending window starts from the data packet at packet index 62 (i.e., WinStart). O =62), data packets with packet indices M+1 to N represent data packets buffered in the current AP MLD but not assigned a SN, and packet index L represents the last transmitted data packet (e.g., MPDU) or the data packet sent in the last A-MPDU. Furthermore, transmit buffer control releases the transmit buffer upon receiving a BA frame from a non-AP MLD. For example... Figure 10 As shown, during roaming, for DL data with an assigned SN, the current AP MLD continues to send it to the non-AP MLD. As the DL data with an assigned SN in the current AP MLD is transmitted to the non-AP MLD, the non-AP MLD sends a BA frame (not shown) to the current AP MLD. With each received BA frame, the current AP MLD's transmission window slides upwards.
[0116] The non-AP MLD, acting as the receiver of DL data, will maintain a block acknowledgment record, i.e., the scoreboard context. The scoreboard context includes a bitmap indexed by the SN, WinStart... R WinEnd R and WinSize R The bitmap indicates the data reception status in the current transmission window, WinStart R Represents the lowest sequence number in the current transfer window (i.e., the bitmap), WinSize R Indicates the maximum window size of the current transmission window, WinEnd R This indicates the highest sequence number in the current transmission window. Non-AP MLDs will change the corresponding SN flag in the bitmap based on data reception, such as... Figure 11As shown in the table at the bottom left, the last column of the table indicates whether the data packet indicated by the SN was received, where "√" indicates successful reception (flag bit "1") and "×" indicates unsuccessful reception (flag bit remains "0"). BA frames sent from a non-AP MLD to the current AP MLD contain this bitmap. Figure 11 In the example, data packets from packet indices 61 to L (SN=101 to 100+L) were transmitted successfully, except for data packets from packet indices 62 and 64 (SN=102 and 104) which failed to be transmitted (indicated by "×" in the last column of the table). Data packets from packet indices L+1 to M (SN=100+L to 100+M) have not yet been sent. Data packets from packet indices M+1 to N are DL data cached in the current AP MLD and data to be sent by the DS.
[0117] Similar to a reference Figure 10 The DS mapping described in step S1012, in Figure 11 In the illustrated embodiment, after the DS mapping switch, new DL data packets from the upper layer ( Figure 11 The grouping indices (N+1, ...) will be cached in the target AP MLD, for example, refer to Figure 10 As described in step S1014. As described above, the dynamic DL ADDBA context may include a Specific-TID, a Next SN, etc., where the Specific-TID corresponds to its service ID and is associated with a TID included in the static parameters sent, for example, in step S506, step S606, or step S610, and the Next SN is... Figure 11 The middle value is M+1.
[0118] For reference Figure 10 As described, during the roaming process, for DL data with an assigned SN, the current AP MLD will continue to send it to non-AP MLDs; Figure 11 In this process, data packets with packet indices 2, 4, L+1 to M will continue to be sent from the current AP MLD to the non-AP MLD. Additionally, as referenced... Figure 10 As described in step S1006, during the roaming process, the current AP MLD forwards the cached DL data of the unassigned SN to the target AP MLD; Figure 11 In this process, data packets with packet indices M+1 to N will be forwarded by the current AP MLD to the target AP MLD for caching. Additionally, as referenced... Figure 10 As described in steps S1008 and S1010, before the DS mapping switch, the current AP MLD forwards DL data packets from the DS to the target AP MLD for caching.
[0119] Figure 12 A schematic diagram illustrating an uplink data transfer process 1200 according to an embodiment of this disclosure is provided. Figure 12 As shown, before the roaming process, because the DS mapping indicates the mapping relationship between the non-AP MLD and the current AP MLD, the non-AP MLD sends UL data to the current AP MLD for buffering before sending it to the upper layer (e.g., via DS). Figure 12 As shown in the table at the bottom left, the UL data to be transmitted by the non-AP MLD has a group index: 1, 2, ..., L, ..., M. The non-AP MLD will assign a corresponding sequence number SN to the UL data to be transmitted: 101, 102, ..., 100+L, ..., 100+M. In some implementations, similar to the current AP MLD transmitting DL data, the non-AP MLD includes transmit buffer control, which uses WinStart. O As the starting sequence number of the sending window, WinSize O The number of caches negotiated in the block confirmation protocol and WinEnd O The WinEnd sequence number is used to submit the UL data for transmission. O =WinStart O +WinSize O -1. In Figure 12 In the example, before the roaming association process, the last sending window starts sending data from the data packet at packet index 1, WinStart O =1, where the packet index L represents the last data packet sent (e.g., MPDU) or the data packet sent in the last A-MPDU.
[0120] The current AP MLD, acting as the receiver of UL data, maintains a block acknowledgment record, i.e., the scoreboard context. The scoreboard includes a bitmap indexed by the SN, indicating the data reception status within the current transmission window, where WinStart... R Represents the lowest sequence number in the bitmap, WinSize R Indicates the maximum window size of the current transmission window, WinEnd R This indicates the highest sequence number in the current transmission window. The current AP MLD will change the flag bit corresponding to the SN in the bitmap based on the data reception status, such as... Figure 12The table in the upper left corner shows the data packet reception status indicated by the SN in the third column, where "√" indicates successful reception and "×" indicates unsuccessful reception. The fourth column shows the data bitmap. It can be seen that the data packets with packet indices 2 and 4 have a reception status of unsuccessful reception, with the corresponding bit in the bitmap being "0". Successfully received data packets have a value of "1" in the bitmap, and the data packets to be sent by the sending end also have a value of "0" in the bitmap. After the non-AP MLD completes WinEnd transmission... R (exist Figure 12 In the example, after the data packet (SN=100+M), the current AP MLD will send a BA frame to the non-AP MLD to report the data transmission status, and determine the SSN of the next UL transmission window based on the SSN carried in the BA frame.
[0121] like Figure 10 As shown, during roaming, non-AP MLDs will suspend UL data transmission. Figure 12 If data packets with packet indices L+1 to M have not yet been sent by a non-AP MLD, the corresponding values in the bitmap remain zero. Furthermore, since non-AP MLDs will pause UL data transmission during roaming, Figure 12 The WinStart on the current AP MLD side is shown in the image. R It will remain at the position where the first packet loss occurred in the last UL sending window. Figure 12 In the example, except for the data packets with packet indices 2 and 4 (SN=2 and 4) which failed to be transmitted successfully, all other data packets in packet indices 1 to L (SN=1 to L) were transmitted successfully; in other words, the first packet loss position of the last UL BA session between the current AP MLD and the non-AP MLD before roaming was SN=102. Therefore, the current AP MLD needs to cache UL data packets with packet indices 2 to L (SN=102 to 100+L), so the UL data packets with packet indices 2 to L (SN=102 to 100+L) cached in the current AP MLD are not transmitted to the upper layer. As described above, the dynamic UL ADDBA context can include a Specific-TID, a Next Serial Number (NextSN, i.e., WinStart), and a WinStart sequence number. R WinSize R WinEnd R And scoreboard (including bitmap), etc., where a specific TID corresponds to its service ID and corresponds to the TID contained in the static parameters sent in, for example, step S506, step S606 or step S610, and WinStart R exist Figure 12 The value in the middle is 2, and the WinSize is...R For M-1, the scoreboard = [0, 1, 0, 1, 1, 1, 1, ..., 0, 0, 0, ...]. Additionally, see reference... Figure 10 As described in step S1006, during the roaming process, the current APMLD forwards the cached UL data therein to the target AP MLD; Figure 11 In the process, data packets with indexes 2 to M will be forwarded by the current AP MLD to the target AP MLD for caching. Packets 2 and 4 were not successfully received, causing the corresponding bitmap positions to be set to zero.
[0122] After the non-AP MLD roams and is associated with the target AP MLD, the non-AP MLD will send data packets with packet indices 2, 4 and L+1 to M (SN=102, 104 and 101+L to 100+M) to the target AP MLD. At the same time, due to the dynamic context sent in step S1004, the scoreboards of the non-AP MLD and the target AP MLD are aligned, and a BA session can be performed.
[0123] Those skilled in the art should understand that, although Figures 5-12 The improved roaming technology described above is based on the MLO (Mean Loop) technology description, but the improved roaming technology is applicable to non-MLO technologies; in other words, the improved roaming technology is applicable to... Figure 5-12 The non-AP MLD and AP MLD are not multi-link devices.
[0124] Figure 17 A flowchart illustrating a computer implementation method 1700 for wireless communication implemented at an AP device of a current serving client device according to an embodiment of the present disclosure is shown.
[0125] For a detailed description of Method 1700, please refer to the reference above. Figures 1 to 16 The content described. For example, method 1700 can be referenced. Figures 1 to 16 The architecture is described and used as per the reference. Figures 1 to 16 (For example, Figures 5-12 The improved roaming mechanism described herein is performed through interactions between the client device, the current AP device, the target AP device, neighboring AP devices, and the DS during roaming. Furthermore, each step of method 1700 can be performed by one or more processing units (such as the central processing unit of the current AP device).
[0126] refer to Figure 17Method 1700 includes steps S1710-S1730. In step S1710, the current AP device (which may also be referred to as the current AP or the current AP MLD) of the current serving client device receives a first request from the client device, the first request indicating that the communication context between the current AP device and the client device be transferred from the current AP device to the target AP device (which may also be referred to as the target AP or the target AP MLD) associated with the client device for roaming. Figure 17 The client device described herein can also be referred to as a STA, a non-AP device, or a non-AP MLD. Figure 17 In the implementation scheme, the first request may correspond to Figure 5 Step S502 or Figure 6 The roaming preparation request is sent in step S602 of the process.
[0127] In step S1720, the current AP device transfers a first context containing static parameters for roaming association to the target AP device during the roaming preparation process, according to a dynamic transfer mode. According to some embodiments, the dynamic transfer mode may be indicated by a first request. According to some embodiments, the static parameters may include a static DL ADDBA context and a static ULADDBA context.
[0128] In step S1730, the current AP device transfers a second context containing dynamic parameters for roaming association to the target AP device during the roaming association process according to a dynamic transfer mode. According to some embodiments, the dynamic parameters may include a dynamic DL ADDBA context and a dynamic UL ADDBA context.
[0129] The current AP device can receive roaming association requests from client devices. During the roaming association process, the roaming association request includes an instruction to associate the client device with the target AP device. Figure 17 In the implementation scheme, roaming association requests from client devices can correspond to Figure 10 The roaming association request is sent in step S1002. During the roaming association process, the current AP device may send downlink (DL) data with the assigned sequence number (SN) cached in the current AP device to the client device. According to some implementations, step S1730 may be performed in response to receiving the roaming association request.
[0130] According to some implementation schemes, the method may further include: in response to the completion of sending DL data of the allocated SN cached in the current AP device, the current AP device sends a roaming association response to the client device in response to the roaming association request. Figure 17 In the implementation plan, the roaming association response sent to the client device can correspond to Figure 10The roaming association response is sent in step S1016.
[0131] According to some implementation schemes, the method may also include: forwarding cached UL data and unassigned DL data in the current AP device to the target AP device. Figure 17 In the implementation scheme, the forwarded cached UL data and the DL data without assigned SN can correspond to Figure 10 The roaming association request is sent in step S1006.
[0132] According to some implementation schemes, the method may also include: suspending the reception of uplink UL data from the client device after receiving a roaming association request from the client device.
[0133] According to some implementations, the method may further include: receiving a transfer response from a target AP device for a first context, the transfer response indicating the transfer status of the first context; and in response to the transfer status indicating that the first context has been successfully transferred, sending a first response to a client device for a first request, the first response including an indication of the transfer status.
[0134] According to some implementations, the method may further include: in response to a transfer status indication that a portion of the first context has not been successfully transferred, sending the portion of the first context that has not been successfully transferred to the target AP device.
[0135] Figure 18 A flowchart illustrating a computer implementation method 1800 for wireless communication implemented at a client device according to an embodiment of the present disclosure is shown.
[0136] For a detailed description of Method 1800, please refer to the above reference. Figures 1 to 16 The content described. For example, method 1800 can be referenced. Figures 1 to 16 The architecture is described and used as per the reference. Figures 1 to 16 (For example, Figures 5-12 The improved roaming mechanism described herein is performed through interactions between the client device, the current AP device, the target AP device, neighboring AP devices, and the DS during roaming. Furthermore, each step of method 1800 can be performed by one or more processing units, such as the central processing unit of the client device.
[0137] refer to Figure 18Method 1800 includes steps S1810-S1820. In step S1810, the client device (which may also be referred to as a STA, a non-AP device, or a non-AP MLD) can determine that the context transfer of communication between the current AP device (which may also be referred to as the current AP or the current AP MLD) of the current serving client device and the client device is a dynamic transfer mode for the transfer mode of the target AP device (which may also be referred to as the target AP or the target AP MLD) that the client device wants to roam with. Figure 18 The client device described herein may also be referred to as a STA, a non-AP device, or a non-AP MLD.
[0138] In step S1820, the client device sends a first request to the current AP device, the first request including an indication of the dynamic handover mode. Figure 18 In the implementation scheme, the first request may correspond to Figure 5 Step S502 or Figure 6 Step S602 sends a roaming preparation request. The dynamic transfer mode can instruct the current AP device to transfer a first context containing static parameters for roaming association to the target AP device during the roaming preparation process, and a second context containing dynamic parameters for roaming association to the target AP device during the roaming association process. According to some embodiments, the static parameters may include a static DL ADDBA context and a static UL ADDBA context, and the dynamic parameters may include a dynamic DL ADDBA context and a dynamic UL ADDBA context.
[0139] According to some implementation schemes, the method may also include: sending a roaming association request to the current AP device, the roaming association request containing an instruction to roam and associate the client device with the target AP device. Figure 15 In the implementation plan, sending a roaming association request to the current AP device can correspond to Figure 9 Step S902 sends a roaming association request.
[0140] According to some implementation schemes, the method may further include: the client device receiving DL data of the assigned SN cached therein from the current AP device; and the client device receiving a roaming association response from the current AP device in response to a roaming association request, the roaming association response being sent in response to the completion of sending the DL data of the assigned SN cached in the current AP device. Figure 18 In the implementation scheme, the roaming association response received from the current AP device can correspond to Figure 10 Step S1016 sends the roaming association response.
[0141] According to some implementation schemes, the method may also include: pausing the transmission of uplink UL data to the current AP device after sending a roaming association request to the current AP device.
[0142] Figure 19 A flowchart illustrating a computer implementation method 1900 for wireless communication implemented at an AP device to which a client device is to roam, according to an embodiment of the present disclosure.
[0143] For a detailed description of Method 1900, please refer to the reference above. Figures 1 to 16 The content described. For example, method 1900 can be referenced. Figures 1 to 16 The architecture is described and used as per the reference. Figures 1 to 16 (For example, Figures 5-12 The improved roaming mechanism described herein is performed through interactions between the client device, the current AP device, the target AP device, neighboring AP devices, and the DS during roaming. Furthermore, each step of method 1900 can be performed by one or more processing units, such as the central processing unit of the target AP device.
[0144] refer to Figure 19 Method 1900 includes steps S1910-S1920. In step S1910, the client device receives a first context of communication between the current AP device and the client device from the current AP device (which may also be referred to as the current AP or the current AP MLD) of the currently serving client device during the roaming preparation process. The first context includes static parameters for roaming association. Figure 19 The client device described herein can also be referred to as a STA, a non-AP device, or a non-AP MLD. Figure 19 In the implementation scheme, the first request may correspond to Figure 5 Step S502 or Figure 6 The roaming preparation request is sent in step S602. According to some implementations, static parameters may include a static downlink DL add block acknowledgment (ADDBA) context and a static uplink UL ADDBA context.
[0145] In step S1920, the target AP device receives a second context for communication between the current AP device and the client device during the roaming association process. This second context includes dynamic parameters used for roaming association. According to some implementations, the dynamic parameters include a dynamic DL ADDBA context and a dynamic UL ADDBA context.
[0146] According to some implementation schemes, the method may also include: receiving uplink UL data and DL data with unassigned sequence number SN cached in the current AP device.
[0147] According to some implementations, the method may further include: sending a transfer response for a first context to the current AP device, the transfer response indicating the transfer status of the first context; and receiving the unsuccessfully transferred portion of the first context from the current AP device if the transfer status of the first context indicates that a portion of the first context has not been successfully transferred.
[0148] Figure 20 This is an exemplary block diagram illustrating a computing device according to some embodiments of the present disclosure.
[0149] It should be noted that Figure 20 The computing devices depicted in the text can correspond to, for example, Figures 1 to 19 The current AP, current AP device, current AP MLD, client, client device, STA, non-AP device, non-AP MLD, neighboring AP, neighboring AP device, neighboring AP MLD, target AP, target AP device, target AP MLD are one or more of these, and can be used to perform actions involved in the roaming mechanism, such as methods 1700-1900 as described above.
[0150] like Figure 20 As shown, computing device 2000 may include processor 2010 and memory 2020. Processor 2010 is communicatively coupled to memory and configured to perform the methods discussed above.
[0151] Examples of processors 2010 include microprocessors, microcontrollers, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described in this disclosure.
[0152] Processor 2010 can execute software. Software should be broadly interpreted as instructions, instruction sets, code, code segments, program code, programs, subroutines, software modules, application programs, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, etc., regardless of whether it is referred to as software, firmware, middleware, microcode, hardware description languages, or otherwise. The software may reside on memory 2020.
[0153] The memory 2020 may be a non-transitory computer-readable medium. Non-transitory computer-readable media include, for example, magnetic storage devices (e.g., hard disks, floppy disks, magnetic stripes), optical disks (e.g., optical discs (CDs) or digital versatile optical discs (DVDs)), smart cards, flash memory devices (e.g., cards, memory cards, or key drives), random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), registers, removable disks, and any other suitable medium for storing software and / or instructions that can be accessed and read by a computer. The memory 2020 may reside in, be external to, or be distributed across multiple entities including the processor 2010. The memory 2020 may be embodied in a computer program product. For example, a computer program product may include a computer-readable medium in packaging material. Those skilled in the art will recognize how the functions described throughout this disclosure can be implemented based on the specific application and overall design constraints imposed on the overall system.
[0154] Furthermore, according to another embodiment of this disclosure, a computer program product for wireless communication is disclosed. As an example, the computer program product includes a non-transitory computer-readable storage medium containing program instructions executable by a processor. When executed, the program instructions cause the processor to perform one or more of the processes described above; details are omitted here for brevity.
[0155] This invention can be a system, method, and / or computer program product at any possible level of integration technical detail. The computer program product may include computer-readable program instructions for causing a processor to perform various aspects of this disclosure.
[0156] Unless otherwise stated, an element mentioned in the singular is not intended to mean "one and only one," but rather "one or more." Similarly, a plural reference to an element does not mean "more than one," but rather "one or more," unless otherwise stated or contradicting description elsewhere. Terms such as "if," "when," and "although" should be interpreted as "under the condition of," rather than implying an immediate temporal relationship or response. That is, these phrases, such as "when," do not imply an immediate action in response to an action occurring or during an action, but merely imply that an action will occur if the condition is met, but does not require a specific or immediate time constraint for the action to occur. Combinations, such as "at least one of A, B, or C," "one or more of A, B, or C," "at least one of A, B, and C," "one or more of A, B, and C," and "A, B, C, or any combination thereof," include any combination of A, B, and / or C, and may include multiple A, multiple B, or multiple C. Combinations such as “at least one of A, B or C”, “one or more of A, B or C”, “at least one of A, B and C”, “one or more of A, B and C” and “A, B, C or any combination thereof” can be only A, only B, only C, A and B, A and C, B and C or A, B and C, wherein any such combination may contain one or more members of A, B or C.
[0157] It should be noted that the flowcharts and block diagrams in the accompanying drawings illustrate the possible structure, function, and operation of the methods and apparatus according to various embodiments of this application. In this respect, each block in the flowchart or block diagram may represent a module, a program segment, or a portion of code containing at least one executable instruction for implementing a specified logical function. It should also be noted that in some alternative embodiments, the functions described in a block may occur in a different order than those described in the accompanying drawings. For example, two blocks shown consecutively may actually be executed in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, may be implemented by a dedicated hardware system that performs the specified function or operation, or by a combination of dedicated hardware and computer instructions.
[0158] The various embodiments described in this disclosure are for illustrative purposes and are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein is chosen to best explain the principles of the embodiments, their practical application, or improvements to techniques found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.
[0159] Throughout the description and claims of this specification, the word “comprising” and variations thereof, such as “comprising” and “including,” means “including, but not limited to,” and are not intended to exclude, for example, other additives, components, integers, or steps. “Exemplary” means “an example of a preferred or ideal implementation and is not intended to convey its indication.” “Like” is not used in a limiting sense but for interpretative purposes.
Claims
1. A wireless communication method implemented at an access point (AP) device, wherein the AP device is the current AP device of a current serving client device, the method comprising: Receive a first request from the client device, the first request indicating that the communication context between the current AP device and the client device should be transferred from the current AP device to the target AP device associated with the client device for roaming; According to the dynamic transfer mode, a first context containing static parameters for roaming association is transferred to the target AP device during the roaming preparation process, and a second context containing dynamic parameters for roaming association is transferred to the target AP device during the roaming association process.
2. The method according to claim 1, wherein, The dynamic transfer mode is indicated by the first request.
3. The method according to claim 1 or 2, wherein, The static parameters include the static downlink DL add block acknowledgment (ADDBA) context and the static uplink UL ADDBA context; and The dynamic parameters include dynamic DL ADDBA context and dynamic UL ADDBA context.
4. The method according to claim 1 or 2, wherein, The method further includes: Receive a roaming association request from the client device, the roaming association request including an instruction to roam and associate the client device with the target AP device; Send the downlink DL data of the assigned sequence number SN cached in the current AP device to the client device; and In response to the completion of sending the DL data of the assigned SN cached in the current AP device, a roaming association response for the roaming association request is sent to the client device; The transfer of the second context to the target AP device is in response to the roaming association request.
5. The method according to claim 4, wherein, The method further includes: Forward the uplink UL data and unassigned DL data cached in the current AP device to the target AP device.
6. The method according to claim 4, wherein, The method further includes: After receiving the roaming association request from the client device, the reception of uplink UL data from the client device is suspended.
7. The method according to claim 1 or 2, wherein, The method further includes: Receive a transfer response from the target AP device for the first context, the transfer response indicating the transfer status of the first context; In response to the transfer status indicating that the first context has been successfully transferred, a first response to the first request is sent to the client device, the first response including an indication of the transfer status.
8. The method according to claim 7, wherein, The method further includes: In response to the transfer status indicating that a portion of the first context failed to transfer, the portion of the first context that failed to transfer is sent to the target AP device.
9. A wireless communication method implemented at a client device, the method comprising: The context transfer mode for the communication between the current access point AP device and the client device currently serving the client device is determined to be a dynamic transfer mode for the transfer mode of the target AP device that the client device wants to roam to. as well as Send a first request to the current AP device, the first request including an indication of the dynamic transfer mode; The dynamic transfer mode instructs the current AP device to transfer a first context containing static parameters for roaming association to the target AP device during the roaming preparation process, and to transfer a second context containing dynamic parameters for roaming association to the target AP device during the roaming association process.
10. The method according to claim 9, wherein, The static parameters include the static downlink DL add block acknowledgment (ADDBA) context and the static uplink UL ADDBA context; and The dynamic parameters include dynamic DL ADDBA context and dynamic UL ADDBA context.
11. The method according to claim 9 or 10, wherein, The method further includes: Send a roaming association request to the current AP device, the roaming association request including an instruction to roam and associate the client device with the target AP device; Receive downlink DL data with the assigned sequence number SN cached in the current AP device; and Receive a roaming association response from the current AP device in response to the completion of sending DL data of the allocated SN cached in the current AP device.
12. The method according to claim 11, wherein, The method further includes: In response to sending the roaming association request to the current AP device, the sending of uplink UL data to the current AP device is suspended.
13. A wireless communication method implemented at an access point (AP) device, wherein the AP device is a target AP device to which a client device is to roam, the method comprising: During the roaming preparation process, a first context of communication between the current AP device and the client device is received from the current AP device currently serving the client device, the first context including static parameters for roaming association; as well as During the roaming association process, a second context of communication between the current AP device and the client device is received from the current AP device, the second context including dynamic parameters for roaming association.
14. The method according to claim 13, wherein, The static parameters include the static downlink DL add block acknowledgment (ADDBA) context and the static uplink UL ADDBA context; and The dynamic parameters include dynamic DL ADDBA context and dynamic UL ADDBA context.
15. The method according to claim 13 or 14, wherein, The method further includes: Receive uplink UL data and DL data with unassigned serial number SN cached in the current AP device.
16. The method according to claim 13 or 14, wherein, The method further includes: Send a mapping request to the distributed system (DS), the mapping request containing an indication of a mapping between the target AP device and the client; and Receive downlink DL data from the DS.
17. The method according to claim 13 or 14, wherein, The method further includes: Send a transfer response for the first context to the current AP device, the transfer response including an indication of the transfer status of the first context; and If the transfer status of the first context indicates that a portion of the first context has not been successfully transferred, the portion of the first context that has not been successfully transferred is received from the current AP device.
18. An access point (AP) device, wherein the AP device is the current AP device serving the current client device, comprising: One or more processors; Memory coupled to at least one of the one or more processors; as well as A set of computer program instructions stored in the memory, which, when executed by at least one of the one or more processors, causes the current AP device to perform the method according to any one of claims 1 to 8.
19. A client device, comprising: One or more processors; Memory coupled to at least one of the one or more processors; as well as A set of computer program instructions stored in the memory, which, when executed by at least one of the one or more processors, causes the client device to perform the method according to any one of claims 9 to 12.
20. An access point (AP) device, wherein the AP device is a target AP device that a client device needs to roam with, comprising: One or more processors; Memory coupled to at least one of the one or more processors; as well as A set of computer program instructions stored in the memory, which, when executed by at least one of the one or more processors, causes the target AP device to perform the method according to any one of claims 13 to 17.
