Seamless roaming method, terminal and storage medium
By triggering a fallback condition during seamless roaming, the terminal exits the seamless roaming domain and selects to fall back to the target access point using a non-seamless roaming method, thus resolving the issue of abnormal operation during seamless roaming, improving the stability of seamless roaming, and reducing packet loss rate.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- CLOURNEY SEMICONDUCTOR (NANJING)
- Filing Date
- 2026-01-08
- Publication Date
- 2026-07-16
AI Technical Summary
Seamless roaming can be disruptive to normal operations, especially since the handling of seamless roaming failures is not yet clear, leading to a high packet loss rate during handover.
During seamless roaming, when a fallback condition is triggered, the terminal exits the seamless roaming domain and chooses to fall back to the target access point in a non-seamless roaming mode. Conditions include multiple unsuccessful attempts to switch to the target access point, unsuccessful negotiation or transmission context, and unsuccessful data path switching.
It improves the robustness of the seamless roaming process, ensuring effective handling of failures and reducing packet loss during handover.
Smart Images

Figure CN2026071499_16072026_PF_FP_ABST
Abstract
Description
Seamless roaming methods, terminals, and storage media Cross-reference to related applications
[0001] This application is based on and claims priority to Chinese Patent Application No. 202510037332.5, filed on January 9, 2025, the entire contents of which are hereby incorporated herein by reference. Technical Field
[0002] This application relates to the field of wireless communication technology, and in particular to a seamless roaming method, terminal, and storage medium. Background Technology
[0003] With the emergence of numerous new applications, while enjoying the high data rates offered by communication devices, people also have increasingly stringent requirements regarding latency and packet loss rates during handover. Therefore, seamless roaming handover has emerged as a solution to reduce packet loss during handover and is currently a hot topic of discussion.
[0004] Specifically, access points (or access point multi-connection devices) supporting seamless roaming constitute a seamless roaming domain, within which terminal devices can seamlessly roam (handover). During seamless roaming, the terminal maintains a constant connection with the access point. Therefore, during seamless roaming handover, the authentication and association frames required for traditional access handover are unnecessary. Traditional access handover authentication frames include authentication request frames and authentication response frames, and traditional access handover association frames include association request frames and association response frames. In other words, there is no authentication or association process during seamless roaming handover; the terminal maintains a constant connection with the access point. For the terminal, seamless roaming handover is simply adding a new connection and deleting an old one. On the access point side, multiple access points (or access point multi-connection devices) use a common Media Access Control (MAC) layer to manage the various access points (or access point multi-connection devices) within the seamless roaming domain.
[0005] The inventors have discovered at least the following problems in the related technologies: Although seamless roaming has made some progress in the field, some details remain unclear. Addressing the various problems that may arise during seamless handover, especially how to handle situations where the seamless roaming process fails to function properly, remains a technological gap in this field. Summary of the Invention
[0006] The purpose of this application is to provide a seamless roaming method, terminal, and storage medium, which provides corresponding countermeasures for situations that may affect the normal operation of seamless roaming during the process, thereby improving the robustness of the seamless roaming process.
[0007] To address the aforementioned technical problems, embodiments of this application provide a seamless roaming method, comprising: during seamless roaming, when a seamless roaming fallback condition is triggered, the terminal exits the seamless roaming domain and selects to fall back to a non-seamless roaming mode to access the target access point; or, when the terminal initially accesses the seamless roaming domain, when a seamless roaming fallback condition is triggered, it selects to fall back to a non-seamless roaming mode to access the target access point; wherein, the seamless roaming fallback condition includes: multiple attempts to switch from the original access point to the target access point in a seamless roaming manner all fail; multiple negotiations or transmissions of context to the target access point all fail; attempts to switch from the original access point to multiple target access points in a seamless roaming manner all fail; and data path switching fails.
[0008] Embodiments of this application also provide a terminal, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the seamless roaming method described above.
[0009] The embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the seamless roaming method described above.
[0010] In this embodiment, during seamless roaming, when a seamless roaming fallback condition is triggered, the terminal exits the seamless roaming domain and chooses to fall back to a non-seamless roaming mode to access the target access point; or, when the terminal initially accesses the seamless roaming domain, when a seamless roaming fallback condition is triggered, it chooses to fall back to a non-seamless roaming mode to access the target access point. Seamless roaming fallback conditions include: multiple unsuccessful attempts to switch from the original access point to the target access point using seamless roaming; multiple unsuccessful attempts to negotiate or transmit context to the target access point; unsuccessful attempts to switch from the original access point to multiple target access points using seamless roaming; and unsuccessful data path switching. This provides corresponding countermeasures for situations affecting the normal operation of seamless roaming, improving the robustness of the seamless roaming process. Attached Figure Description
[0011] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.
[0012] Figure 1 is a schematic diagram of the seamless roaming connection relationship between two connected devices according to an embodiment of this application;
[0013] Figure 2 is a flowchart of a seamless roaming process for two connected devices according to an embodiment of this application;
[0014] Figure 3 is a flowchart of another seamless roaming process for two connected devices according to an embodiment of this application;
[0015] Figure 4 is a schematic diagram of the connection relationship of anchor connection transmission according to an embodiment of this application;
[0016] Figure 5 is a schematic diagram of the connection relationship between backup connections in anchor connection transmission according to an embodiment of this application;
[0017] Figure 6 is a schematic diagram of the structure of a terminal according to another embodiment of this application. Detailed Implementation
[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been presented in the various embodiments of this application to enable readers to better understand this application. However, even without these technical details and various changes and modifications based on the following embodiments, the technical solutions claimed in this application can be implemented. The division of the various embodiments below is for the convenience of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.
[0019] One embodiment of this application relates to a seamless roaming method that can be applied to any non-access point multi-link device (non-AP MLD), such as a mobile phone, computer, or other terminal device (station, STA); it can also be applied to multi-link devices (MLD) or access point devices (AP), such as an access point multi-link device (AP MLD). In this embodiment, during seamless roaming, when a seamless roaming fallback condition is triggered, the terminal exits the seamless roaming domain and chooses to fall back to a non-seamless roaming mode to access the target access point; or, when the terminal initially accesses the seamless roaming domain, when a seamless roaming fallback condition is triggered, it chooses to fall back to a non-seamless roaming mode to access the target access point. Seamless roaming fallback conditions include: multiple attempts to switch from the original access point to the target access point in a seamless roaming manner fail; multiple negotiations or context transfers to the target access point fail; attempts to switch from the original access point to multiple target access points in a seamless roaming manner fail; and data path switching fails. In some cases, these multiple target access points belong to the same seamless roaming domain. After exiting the seamless roaming domain, the connection with the original access point is disconnected, and an attempt is made to establish a connection with the target access point, or the terminal re-accesses the seamless roaming domain. This provides corresponding countermeasures for situations that affect the normal operation of seamless roaming during the seamless roaming process, improving the robustness of the seamless roaming process. The implementation details of the seamless roaming method in this embodiment are described below. The following content is only for the convenience of understanding and is not necessary for implementing this solution.
[0020] During seamless roaming, when the seamless roaming fallback condition is triggered, the terminal exits the seamless roaming domain and chooses to fall back to a non-seamless roaming mode to access the target access point; or, when the terminal initially accesses the seamless roaming domain, when the seamless roaming fallback condition is triggered, it chooses to fall back to a non-seamless roaming mode to access the target access point. The seamless roaming fallback conditions include: multiple attempts to switch from the original access point to the target access point in a seamless roaming manner fail; multiple negotiations or transmissions of context to the target access point fail; attempts to switch from the original access point to multiple target access points in a seamless roaming manner fail; and data path switching fails.
[0021] In one example, when the seamless roaming fallback condition is triggered, a seamless roaming response frame carrying a status code, a seamless roaming initial access response frame carrying a status code, a seamless roaming acknowledgement frame carrying the status code, an association response frame carrying the status code, or a reassociation response frame carrying the status code is sent to or received from the target access point. The status code corresponds to the reason for the target access point's refusal to allow access. For example, if a terminal (non-AP MLD) or the original access point (also referred to as the current access point, hereinafter the same) requests to switch the terminal to the target access point in a seamless roaming manner, and the target access point does not support or agree to the terminal switching to the target access point for unknown reasons, the terminal indicates a refusal in the seamless roaming response frame. The reason for refusal is indicated by the status code.
[0022] In one example, the status code and its corresponding meaning could be: 000, SUCCESS (request frame content successfully requested); 001, REFUSED_REASON_UNSPECIFIED (unknown reason); 010, access point overloaded; 011, REFUSED_CAPABILITIES_MISMATCH (corresponding capability not supported); 100, unsupported TID (corresponding service not supported); 101, STATUS_INVALID_SRE (invalid seamless roaming element); 110, unprotected request frame (unprotected); 111, invalid roaming domain (STATUS_INVALID_SDE, where SDE stands for seamless roaming domain element), indicating that the roaming domain in the seamless roaming request frame does not match the roaming domain of the target access point; optionally, this status code could also indicate a data path switching failure. When a terminal roams, the data path needs to be switched from the original access point to the target access point, and this unsuccessful operation corresponds to the current status code. In some cases, this status code indicates a successful seamless roaming (switching) or a successful initial access.
[0023] In one example, the status code is used during seamless roaming handover or initial seamless roaming access in certain situations. This status code, contained in the initial seamless roaming access response frame or the seamless roaming response frame, is a field called the status code consisting of binary bits, such as 4 bits, 3 bits, or 16 bits. In some cases, the status code uses decimal numbers, for example, starting from 144; for example, 144 Invalid_context; 145 context_reconstruction_failed; 146 invalid / unsuccessful_datapath_switch, and so on. Alternatively, it may start from 139. For example, 139 Invalid context; 140 context reconstruction failed; 141 Invalid seamless roaming element; 142 Invalid roaming domain element (STATUS_INVALID_SDE). If a non-AP MLD fails to connect to a target AP MLD via seamless roaming, the target AP MLD sends a status code to the non-AP MLD, and the connection is readjusted to attempt a seamless roaming handover to that target AP MLD or another AP MLD. In some cases, at least one of these new status code entries is included in Table 9-80—Status codes in a future revision of the 802.11 standard, or in other newly defined tables, or by expanding the content of existing tables. The numbering is not limited to the numbers mentioned above; the numbers are merely illustrative. In some cases, this status code is called a reason code.In some cases, this status code is represented by 16 binary bits and included in seamless roaming-related frames, such as the initial control frame (ICR), initial control response frame (ICR), seamless roaming request frame, seamless roaming response frame, improved link reconfiguration frame for seamless roaming, or seamless roaming acknowledgement frame. In other cases, when a terminal initially accesses the seamless roaming domain, or when a terminal re-accesses the seamless roaming domain (when the terminal leaves the seamless roaming domain and then re-accesses it), this status code is included in the association response frame or the re-association response frame.
[0024] Taking a non-AP MLD as an example, during seamless roaming, if a non-AP MLD attempts to switch to the target access point but fails to establish a connection with the target AP MLD for some reason, the non-AP MLD will attempt to connect to the current access point or try to maintain the connection with the current access point. If the non-AP MLD fails to connect to the original AP MLD, it will fall back to the normal handover method (selecting an access point from the nearby scanned access points to attempt connection) or re-access the seamless roaming domain.
[0025] To facilitate understanding, the following will list various scenarios related to seamless roaming rollback and corresponding countermeasures:
[0026] In certain situations, if a non-AP MLD fails to seamlessly roam to a target AP MLD multiple times, or attempts to switch to at least m target access points, it will fall back to the normal handover method, either reconnecting to the same seamless roaming domain or reconnecting to another seamless roaming domain. Here, m is a positive integer. The specific number of times is a positive integer. Falling back to the normal handover method means that the terminal exits the seamless roaming domain, disconnects from the current access point, and then reconnects, authenticating, associating, and connecting to the target access point. A four-way handshake is then used to negotiate the key and begin data transmission, as described below.
[0027] In some cases, if a non-AP MLD fails to negotiate or transmit its context to the target AP MLD multiple times during seamless roaming handover, or attempts to handover to at least m target access points, it will fall back to the normal handover mode, or reconnect to the seamless roaming domain, or reconnect to another seamless roaming domain.
[0028] In certain situations, if a non-AP MLD fails to seamlessly roam to the target AP MLD multiple times during seamless roaming handover using anchor-based connections, or attempts to switch to at least m target access points, it will fall back to the normal handover method, or reconnect to the seamless roaming domain, or reconnect to another seamless roaming domain.
[0029] In some cases, if seamless roaming fails and the terminal reverts to normal handover, the decision is negotiated within the seamless roaming domain upon the terminal's initial connection, or specified by the access point the terminal initially connected to. In some cases, the terminal includes a fallback bit (or fallback field) in its seamless roaming request frame (or association request frame), where a bit of 0 indicates a fallback to normal handover if seamless roaming fails, and a bit of 1 indicates no fallback. The access point the terminal initially connected to also includes a fallback bit (or fallback field) in its seamless roaming response frame (or association response frame), where a bit of 0 indicates a fallback if seamless roaming fails, and a bit of 1 indicates no fallback. "No fallback" means that even if seamless roaming fails, the terminal continues to attempt to handover to the target access point or another access point using the seamless roaming method.
[0030] During seamless handover, an anchor link is established between the terminal and the current access point to transmit data, preventing packet loss or latency caused by the connected terminal. The following section will explain the possible configurations of buffered data on the anchor link during seamless handover:
[0031] During seamless roaming handover, the anchor link maintains its connection with the original access point, while other connections switch to the target connection. In one example, during seamless roaming, the anchor link relays data transmitted on behalf of other non-anchor connections during the buffered data period. In other words, during the anchor link's buffered data period, the anchor link can relay data on behalf of other connections, but a rule must be followed when data from other connections is relayed to the anchor link. For example, low-latency data is prioritized for transmission. When there is a conflict between data transmitted on the anchor link and data transmitted on other non-anchor connections, the data transmitted on the anchor link and other non-anchor connections are sorted according to priority and transmitted sequentially.
[0032] In one example, before using the anchor connection to relay data transmitted on various non-anchor connections, the data to be transmitted on the anchor connection is filtered and restricted by preset anchor connection transmission restrictions. The preset anchor connection transmission restrictions are based on one or any combination of the following factors: whether the data transmitted on the non-anchor connection is low-latency data, the quality of service requirements of the data transmitted on the non-anchor connection, the latency requirements of the data transmitted on the non-anchor connection, the access type of the data transmitted on the non-anchor connection, whether the service priority is higher than that of the data transmitted on the anchor connection, the bandwidth of the anchor connection, the working bandwidth of the anchor connection, and the spatial stream of the anchor connection.
[0033] In one example, if data that was originally transmitted on various connections is transmitted by the Anchor link during a switch, the Anchor link transmits data in its transmission buffer according to priority, either TID (Traffic ID) or Access category.
[0034] In one example, during the selection of a connection as the anchor connection, data that would otherwise be transmitted on various links can be reassembled during the buffering period. In some cases, the anchor connection is determined or specified by the current AP MLD and notified to the Non-AP MLD via a seamless roaming handover related frame. In other cases, the anchor connection is determined by the non-AP MLD and notified to the current AP MLD via a seamless roaming handover related frame. In some cases, the anchor connection is a 4-bit link ID included in the seamless roaming handover related frame. In some cases, the anchor connection is suggested by the non-AP MLD and notified to the current AP MLD via a seamless roaming handover related frame, and acknowledged by the current AP MLD. If the anchor connection acknowledged by the current AP MLD is different from the connection requested or suggested by the non-AP MLD, the connection that the AP MLD should acknowledge is used as the anchor connection.
[0035] The following example illustrates the anchor link switching process. First, taking two connections as an example, we illustrate a seamless roaming switching process, as shown in Figure 1. In this case, the Non-AP MLD is a non-AP multi-connection device connected to the current AP MLD (access point multi-connection device, also called the original access point), with two connections. Connection 1 is the anchor link. For seamless roaming switching, (1) in Figure 1 represents the disconnection of connection 2 between STA2, attached to the non-AP MLD, and the current AP MLD, and then the establishment of a corresponding connection with the target AP MLD. Then, (2) in Figure 1 represents the disconnection of connection 1 between STA1, attached to the non-AP MLD, and the current AP MLD, and then the establishment of a corresponding connection with the target AP MLD. For cases where there are preparation steps for seamless roaming handover before the handover, the specific handover process is shown in Figure 2. In some cases, the preparation steps for seamless roaming handover, i.e., preparing for roaming handover: context transmission: the step of mapping the data transmitted on the current AP MLD and Connection 2 to Connection 1 is completed by the seamless roaming request frame. Relevant information, such as the context, is contained in the seamless roaming request frame.
[0036] The handover process includes a switch of the data path (or data stream). The data stream switches from the current AP MLD to the target AP MLD. In some cases, this data handover occurs after the target AP MLD receives a handover request (frame) from the non-AP MLD and should agree to accept the non-AP MLD (or after transmitting an acknowledgment frame to the non-AP MLD).
[0037] The handover process includes the switching of non-anchor connections (connections other than the anchor connection), such as in step ii), where connection 2 is disconnected between the terminal and the current AP MLD. Furthermore, a connection is established with the target AP. Before step ii), as shown in step i), data previously transmitted on connection 2 on the current AP MLD is now transmitted via connection 1. During the handover process, data previously transmitted on connection 2 needs to be switched to the anchor connection (connection 1) and transmitted via connection 1. In some cases, connection 2 includes TTLM (TiD-to-link mapping), which maps data transmitted on connections other than the anchor node (corresponding TIDs, where TID stands for Traffic Identifier) to the anchor connection. This step is data mapping, which will be explained below in two cases: explicit and implicit.
[0038] In some cases, this step is completed explicitly via a seamless roaming request frame (or an enhanced link reconfiguration frame) transmitted by the terminal, which includes a TTLM element indicating that all TIDs are mapped to the anchor connection. In other cases, seamless handover-related frames include a field (e.g., 1) indicating that the specific handover method is anchor-based handover. In still other cases, when this bit is 0, it indicates that anchor-based handover is not used, or that a normal handover is used, or that all connections to the current AP MLD are first disconnected before establishing a connection with the target AP MLD.
[0039] In some cases, this step is performed implicitly. The terminal or the current AP MLD initiates a seamless roaming request frame (or an enhanced link reconfiguration frame), triggering all TIDs to be mapped to the anchor connection. In some cases, the seamless handover-related frame contains a field (e.g., a bit set to 1) indicating that the specific handover method is anchor connection-based handover. In this case, if the TTLM element is not included, it means all TIDs are mapped to the anchor connection; the default is that all TIDs are mapped to the anchor connection.
[0040] After STA2, attached to the non-AP MLD, establishes a connection with the target AP MLD, the data path is switched, and step iii) is executed to switch the Ds data path from the current AP MLD to the target AP MLD. In some cases, the process of switching the Ds data path from the current AP MLD to the target AP MLD in step iii) occurs at the beginning of the handover process, as shown in step 1 of Figure 3. Once the data flow handover is complete, STA2, attached to the non-AP MLD, can begin exchanging data with the target AP MLD. Until this point, STA1, attached to the non-AP MLD, continues to exchange data with the current AP MLD through connection 1. Therefore, there is no interruption in data transmission due to the handover, truly achieving seamless operation.
[0041] Next, as shown in step iv) of Figure 2, STA1, attached to the terminal, disconnects from the current AP MLD and establishes a connection with the target AP. In other words, STA1, attached to the non-AP MLD, disconnects from the current access point and establishes a corresponding connection with the target access point. The handover process ends. In some cases, step iv) is triggered by a seamless roaming response frame. This frame is transmitted from the target access point to the non-AP MLD. In some cases, steps ii) and iv) each have two steps: disconnecting the original connection and establishing a new connection, as shown in Figure 3. In Figure 3, roaming handover preparations are also made before the handover begins: context transmission; data transmitted on the current AP MLD and connection 2 is mapped to connection 1. During the handover process, the data path switch is completed first, i.e., step 1, the DS data path is switched from the current AP MLD to the target AP MLD; step 2, the data originally transmitted on connection 2 on the current AP MLD is transmitted on connection 1; step 3, STA2 attached to the terminal disconnects from the current AP; step 4, STA2 attached to the terminal establishes a connection with the target AP; step 5, STA1 attached to the terminal disconnects from the current AP; step 6, STA1 attached to the terminal establishes a connection with the target AP. Seamless handover is achieved.
[0042] The following example illustrates a seamless roaming handover scenario where the anchor connection buffer consists entirely of data from Connection 2: In some cases, based on the anchor connection handover, other connections besides the anchor connection can switch their transmitted data to the anchor connection, thus avoiding interruption or loss of data transmission on the corresponding connection. As shown in Figure 4, there are two connections between a non-AP MLD (not shown) and the current AP MLD. Both Connection 1 and Connection 2 are transmitting data. Connection 1 is the anchor connection. However, compared to the data transmitted on Connection 1, the data transmitted by Connection 2 has a higher priority, or the TID corresponds to a low-latency service, or the QoS latency requirement is lower, or the corresponding access category is AC_VO. Therefore, at the start of seamless roaming, Connection 2 first switches to the target AP MLD. At this time, the data of Connection 2 switches to Connection 1 for continued transmission, and the data previously transmitted on Connection 1 is temporarily stopped. When Connection 2 re-establishes a connection with the target AP MLD, the data transmitted on Connection 2 is resumed on the new connection of the target AP MLD. Next, Connection 1 between the non-AP MLD and the current AP MLD switches to the target AP MLD. Because the data priority on Connection 1 is higher than that on Connection 2, the data on Connection 1 cannot be transferred via a newly established connection on the target AP MLD after the handover from Connection 2. Therefore, data from the original Connection 1 can only continue to be transmitted after the handover to the target AP MLD is complete.
[0043] The following example illustrates a situation where the anchor connection buffer's data for Connection 2 is limited during seamless roaming handover: In some cases, at the start of the seamless roaming, the data transmission duration or the amount of data that can be transmitted on Connection 2 is limited. Because Connection 1 (the anchor connection) has limited bandwidth and data transmission capacity, the amount of data transmitted during the Connection 2 handover process (the corresponding STA attached to the non-AP MLD disconnects from the current AP MLD and establishes a new connection with the target AP MLD) is limited. Therefore, to ensure that the data transmitted on its own connection (QoS, latency) is not affected, it is necessary to limit the data transmitted on behalf of Connection 2 during the Connection 2 handover process. For example, a maximum transmission duration threshold (e.g., 10ms), or bandwidth (the bandwidth of the anchor connection used to transmit data on behalf of Connection 2 should not exceed half of the anchor connection's operating bandwidth), or spatial stream (e.g., only one spatial stream is used to transmit data on behalf of Connection 2)). In some cases, data on Connection 2 is prioritized for transmission only when the data transmitted on Connection 2 is low-latency data, or has QoS requirements, latency requirements, or an access category higher than that on Connection 1, as shown in Figure 3. In some cases, conversely, if the data transmitted on Connection 1 is low-latency data, or meets QoS requirements, latency requirements, or has a higher access category than the data on Connection 2, there is a margin for transmitting data on Connection 2 while satisfying its own QoS requirements. It is possible to transmit its own data and the data originally transmitted on Connection 2 simultaneously at the start of seamless roaming handover, as shown in Figure 4. Furthermore, after Connection 2 switches to the target AP MLD between the non-AP MLD and the current AP MLD, the data on Connection 2 is restored at the target access point, while simultaneously transmitting the data originally transmitted on Connection 1. Data on Connection 1 is transmitted first, as shown in Figure 5. During seamless handover, Connection 1 and Connection 2 serve as backup connections for each other, transmitting data.
[0044] The following provides supplementary explanations of some signaling: In some cases, the step: the original Connection 1 transmission switches to the corresponding connection of Connection 1 at the target access point, occurring when the target AP MLD transmits a seamless roaming acknowledgment frame to the current access point (or terminal). In some cases, the step: seamless roaming begins, occurring when the terminal or the current AP MLD transmits a seamless roaming request frame to the target AP MLD, which in turn transmits it to the current access point. In some cases, the step: Connection 1 transmission and Connection 2 transmission reply at the target access point, with the target AP MLD (or the current AP MLD) sending a management frame, or control frame, or ACK frame, or batch acknowledgement frame (BAT), or improved ACK frame, or improved batch acknowledgement frame (BAT) containing a specific link ID to the terminal; one purpose is to indicate that the connection has been successfully established and data transmission has begun (or is possible).
[0045] If, during a seamless handover, some data (buffered uplink data and buffered downlink data) is buffered on both the terminal side and the access point side, the following examples illustrate how to handle this situation:
[0046] In one example, uplink and downlink data on a single connection (such as an anchor link) can only be transmitted in a time-sharing manner. For instance, prioritizing uplink data transmission will cause downlink data buffering; similarly, prioritizing downlink data transmission will also cause downlink data buffering. Furthermore, the handover process involves short-term connection switching, which will also cause brief interruptions, resulting in data accumulation in the buffer. Therefore, it is necessary to limit the data length in the buffer during seamless roaming handover, both to ensure fairness in uplink and downlink data transmission and to reduce latency caused by seamless handover.
[0047] In some cases, there is only one anchor link, and uplink and downlink data from other connections on the same MLD device need to be transferred to that connection.
[0048] In one example, during seamless roaming, when uplink and downlink buffered data are transmitted through the same connection, the transmission order of the uplink or downlink buffered data will be determined based on their respective transmission requirements. When uplink and downlink buffered data have the same transmission requirements, it will be determined whether to prioritize the transmission of the uplink or downlink buffered data. Transmission requirements include one or any combination of the following: priority requirements, access category requirements, service identifier requirements, and quality of service requirements. For example, uplink and downlink buffered data may have their own transmission durations or their own transmission time thresholds. Uplink and downlink data each have their own transmission requirements, including at least one of the following: priority, access category, service identifier requirements (which can be understood as service type requirements, or Transaction Identifier, or Quality of Service (QoS) requirements). In one example, transmission can be determined by specifying rules such as: prioritizing uplink data, prioritizing downlink data, or prioritizing data with higher requirements. If the transmission requirements for uplink and downlink data are consistent, either the buffered uplink data or the buffered downlink data will be transmitted first, randomly selected. Alternatively, the priority of uplink or downlink data transmission can be determined through negotiation. In some cases, the indication of priority for uplink or downlink data transmission is a field, domain, or subfield, represented by a single bit: 1 for downlink and 0 for uplink. This indication is included in the Seamless Roaming Request Frame, Seamless Roaming Acknowledgment Frame, or ICF (Initial Control Frame), ICR (Initial Control Response Frame), or in the Enhanced Link Configuration Frame used for seamless handover. The terminal or access point initiates a handover request containing the uplink / downlink priority transmission indication. If the response from the other party contains the same uplink / downlink priority transmission indication, the negotiation is successful. Otherwise, the negotiation fails, and the buffered uplink and downlink data are transmitted using the default method. The default method of transmitting buffered uplink and downlink data means that during seamless handover, uplink-first transmission is used. Within the uplink buffer data transmission time threshold, buffered uplink data is transmitted. Then, within the downlink buffer data transmission time threshold, buffered downlink data is transmitted.Among them, in some cases, the default method of transmitting buffered uplink data and buffered downlink data means that during seamless handover, in accordance with the downlink-priority transmission method first, during seamless handover, the buffered downlink data is transmitted within the downlink buffered data transmission duration threshold. Then, within the uplink buffered data transmission duration threshold, the buffered uplink data is transmitted. Here, the uplink buffered data transmission duration threshold refers to the maximum duration of buffered data transmission. If the buffered uplink data is transmitted before this threshold, the uplink data transmission ends提前结束上行传输数据传输. Similarly, the downlink buffered data transmission duration threshold refers to the maximum duration of buffered data transmission. If the buffered downlink data is transmitted before this threshold, the downlink data transmission ends提前结束下行传输数据传输.
[0049] In one example, both the uplink buffered data and the downlink buffered data have their respective buffer data thresholds. During seamless roaming, when the amount of uplink buffered data or downlink buffered data in the buffer exceeds their respective corresponding buffer data thresholds, the excess data beyond their respective buffer data thresholds continues to be buffered, or only the data within their respective buffer thresholds is transmitted during seamless roaming. Because the mobile access point (mobile AP) has only one connection as the primary connection and is responsible for the transmission of some secondary connections (beacon). At certain times, the buffer data threshold is different from the general buffer threshold, and the buffer data threshold can be set shorter. Or there can also be separate buffer data volume thresholds for the uplink and downlink respectively, or there can also be buffer duration thresholds for the uplink and downlink.
[0050] In some cases, the buffer data threshold is related to the data type. Different data types define different thresholds. For example, according to different access types, during seamless handover, the buffer data thresholds for the corresponding buffered data to be transmitted have the following relationship: Th_AC_VO < Th_AC_VI < Th_AC_BE < Th_AC_BK. AC_VO < AC_VI < AC_BE < AC_BK, corresponding to the following service types respectively: AC_VO (Voice) for high-quality voice calls, AC_VI (Video) for high-quality videos, AC_BE (Best-effort) for the default wireless traffic type, such as web browsing data traffic, and AC_BK (Background). In some cases, low-latency services are classified into the AC_VO service type, and there is a dedicated threshold for low-latency services, thus resulting in a lower buffer time and a lower handover delay.
[0051] Context is information about a terminal that remains unchanged or partially unchanged during seamless handover, transmitted from the terminal or current access point to the target access point to ensure a rapid handover. Alternatively, some information may be reconstructed at the target access point. In some cases, the duration threshold of uplink buffer data is a type of context. In other cases, the duration threshold of downlink buffer data is a type of context. In some situations, either the uplink or downlink buffer data duration threshold is included in the context information, which is transmitted from the terminal or current access point to the target access point via seamless roaming-related frames to assist in seamless roaming.
[0052] In some cases, the duration threshold for uplink or downlink transmission buffer data is determined when the terminal initially accesses the seamless roaming domain. Upon initial or re-accession to the seamless roaming domain, the terminal negotiates the uplink and downlink transmission buffer data duration thresholds with the target access point. These thresholds are included in the probe request and probe response frames or association request and association response frames. In some cases, the uplink and downlink transmission buffer data duration thresholds are determined by the manufacturer and set at the factory as a capability of the device. In some cases, the uplink and downlink transmission buffer data duration thresholds are at the MLD (multi-link device) level. Each MLD has one uplink and one downlink transmission buffer data duration threshold. In some cases, the uplink and downlink transmission buffer data duration thresholds are at the STA (station) level associated with the MLD. Each STA associated with an MLD has a time limit value for uplink transmission buffer data and a time limit value for downlink transmission buffer data.
[0053] In one example, when a device does not support having more than one connection to both the original access point and the target access point simultaneously during seamless roaming, it will achieve seamless roaming by caching the data transmitted between itself and the original access point and establishing a connection with the target access point. In other words, when a terminal, with only one connection, or supporting only one connection, or a multi-connection device with only one auxiliary STA, performs a seamless roaming handover: first, the original connection to the current access point is deleted, and then a new connection to the new access point is added. During the handover process, the terminal may interrupt transmission at some point or for a certain period of time (caching buffered data). Because of its own limitations, the terminal cannot connect to multiple connections simultaneously (more than one connection), or cannot simultaneously connect to the original connection to the current access point and the new connection to the target access point. Therefore, the terminal cannot use the handover method of adding one connection and then deleting another for seamless roaming. The terminal can only perform seamless roaming by first deleting the connection to the current access point and then establishing a connection with the target access point. In some cases, when the downlink data stream switches from the original access point to the target access point, some data or data packets are repeatedly transmitted. For example, before the handover, the data stream at the original access point AP1 was transmitted up to packet number 1200. After the data stream handover, transmission continues at the target access point starting from packet number 1201. In some cases, transmission starts from packets 1201-n, where n is a natural number. In some cases, these packets are MPDUs. In some cases, these packet numbers are sequence numbers (SNs). In some cases, n can be configured and determined through negotiation between the original and target access points, or between the terminal and the target access point, and is included in the seamless roaming negotiation frame. In some cases, the same n is used within a seamless roaming domain.
[0054] The following discussion will address the scenario where non-simultaneous transmission and reception (NSTR) mobile access points may occur during seamless roaming:
[0055] In one example, whether an NSTR Mobile AP is allowed to join a seamless roaming domain can be directly configured. In some cases, NSTR Mobile APs are not allowed to join a seamless roaming domain during seamless handover. This is dynamically configurable. If the field or domain `SeamlessRoamingEnabled` in the device is `true` or `1`, it indicates that joining any seamless roaming domain is allowed; otherwise, it is not. This field or domain is contained in the Physical Layer Capability element (PHY capability element) or the MAC Capability element (MAC Capability element) within the Ultra-Higher Layer Operation element (UHR operation element), or in the Management Information Base (MIB).
[0056] In one example, during seamless roaming, the selection of seamless roaming handover methods will be restricted based on whether the original access point and / or the target access point are non-simultaneous mobile access points. Seamless roaming handover methods include: Over-the-Air method, Over-the-DS method, and anchor-connection-based handover method, etc. Among them, the anchor-connection-based handover method will specify the primary connection of the simultaneous mobile access points as the anchor connection.
[0057] If non-simultaneous transmitting and receiving mobile access points (NSTR Mobile APs) appear in the seamless roaming domain, there are three scenarios: First, the original access point is a regular AP (or AP MLD), and the destination access point is an NSTR Mobile AP; second, the original access point is an NSTR Mobile AP, and the destination access point is a regular AP (or AP MLD); third, both the original and destination access points are NSTR Mobile APs. Examples of these three scenarios will be provided below.
[0058] In a seamless roaming domain, a terminal switches from a regular AP (or AP MLD) to an NSTR Mobile AP. The target AP has a primary connection and a secondary connection. In some cases, the device supports both Over-the-air and Over-the-DS seamless roaming handover methods, which are not limited or restricted by the terminal switching from a regular AP (or AP MLD) to an NSTR Mobile AP, and are not limited to only one handover method. The terminal establishes a primary connection with the target access point first, then a secondary connection, or simultaneously establishes both primary and secondary connections. Seamless handover-related frames are transmitted on the primary connection with the target access point. The regular AP is a non-NSTR Mobile AP, an access point, or an access point with multiple connections. In some cases, a terminal switches from a regular AP (or AP MLD) to an NSTR Mobile AP. The terminal can only interrupt data transmission during the connection process, like a single-connection device. The terminal interrupts transmission on the current access point connection and then switches to the target access point to establish a connection. In some cases, a terminal switches from a regular AP (or AP MLD) to an NSTR Mobile AP using an anchor-based handover method. As shown in Figure 4 or Figure 5, the anchor connection is responsible for transmitting data between the terminal and the current access point during the handover process. Then, a primary connection is established between the terminal and the target access point, followed by a secondary connection.
[0059] In a seamless roaming domain, handover from an NSTR Mobile AP to a regular AP supports both Over-the-air and Over-the-DS seamless handover methods. The primary connection acts as the anchor connection. This regular AP is a non-NSTR mobile AP, an access point, or an access point with multiple connections. In some cases, a terminal switches from an NSTR Mobile AP to a regular AP (or AP MLD). The terminal can only interrupt data transmission during the connection process, acting like a single-connection device. The terminal interrupts transmission on its connection to the current access point and then switches to the target access point to establish a connection. In other cases, a terminal switches from an NSTR Mobile AP to a regular AP (or AP MLD) using an anchor-based handover method. The primary connection between the terminal and the current NSTR Mobile AP is the anchor link. As shown in Figure 4 or Figure 5, the anchor link is responsible for transmitting data between the terminal and the current access point during the handover process. Then, the terminal establishes a primary connection with the target access point first, followed by a secondary connection.
[0060] In a seamless roaming domain, handover from one NSTR Mobile AP to another supports both Over-the-air and Over-the-DS seamless handover methods. The primary connection acts as the anchor connection. The regular AP is a non-NSTR mobile AP, an access point, or an access point with multiple connections. In some cases, a terminal switches from an NSTR Mobile AP to a regular AP (or AP MLD). The terminal can only interrupt data transmission during the connection process, like a single-connection device. The terminal interrupts transmission on its connection with the current access point and then switches to the target access point to establish a connection. In some cases, a terminal switches from an NSTR Mobile AP to a regular AP (or AP MLD) using an anchor-based handover method. The primary connection between the terminal and the current NSTR Mobile AP is the anchor link. As shown in Figure 4 or Figure 5, the anchor link is responsible for transmitting data between the terminal and the current access point during the handover process. Then, the terminal establishes a primary connection with the target access point first, followed by a secondary connection.
[0061] In some cases, when a terminal switches from one NSTR Mobile AP to a regular AP (or another NSTR Mobile AP) via seamless roaming, the primary connection between the terminal and the NSTR Mobile AP serves as the anchor link. If, in some cases, the specified anchor link is not the primary link (the anchor link is configured or specified as another link), then during the handover process, the primary link is forced to be used (or forced to be specified) as the anchor link.
[0062] In some cases, a command is a field, which is contained in the roaming request frame (ICF) and roaming response frame (ICR) to indicate that the current access point is a mobile AP and can only use its primary link as the anchor link.
[0063] In certain situations, during seamless roaming initiated by an access point (NPT), if the NSTR mobile AP is involved, only the primary link can be used as the anchor link. This anchor link indication is included in the seamless roaming request frame, seamless roaming proposal frame, seamless roaming response frame, or enhanced link reconfiguration frame. In some cases, this anchor link indication is included in the seamless roaming element or the enhanced multi-link element.
[0064] In some cases, during seamless roaming initiated by the terminal, if the target access point is a mobile AP, the primary link of the mobile AP can be used as the anchor link for seamless roaming.
[0065] In some cases, NSTR Mobile APs (with the primary connection being an anchor connection) can only use Over-the-DS handover. The primary connection is an anchor connection, transmitting data signaling (seamless roaming request frames) with the current AP. This primary connection is eventually disconnected from the current AP, and a subordinate connection is first established with the target access point. It is important to note that a single connection cannot receive signaling from two APs simultaneously.
[0066] In some cases, the secondary connection between the terminal and the current NSTR Mobile AP serves as the anchor link. The terminal and the target access point exchange seamless roaming-related frames (Seamless Roaming Request Frame, Seamless Roaming Response Frame, ICF, ICR) via the primary connection. In some cases, when the terminal is seamlessly roaming, the current access point (or target access point) is an NSTR Mobile AP, and the terminal can only use Over-the-Air handover (or the terminal can only use Over-the-DS handover). In the above cases, even if the terminal and the current access point (or target access point) are capable of supporting Over-the-Air handover (the corresponding configuration or capability is configured to 1, or enabled), the terminal can only use Over-the-Air handover (or the terminal can only use Over-the-DS handover).
[0067] In some cases, during seamless roaming initiated via an access point, if that access point is an NSTR mobile AP, the primary link is used to transmit the data path (data stream, or data in a buffer), and this connection is the last to be disconnected among all connections between the terminal and the current access point device. During seamless handover, the connection between the terminal and the current access point (or a multi-connection access point device) is responsible for transmitting buffered downlink data and management frames, action frames, or control frames.
[0068] In this implementation, by clearly defining the handover process and specifying the data transmission method on the anchor connection, the seamless roaming handover initiator (terminal or current AP MLD) can adjust its own settings (or parameters) to complete the handover quickly and effectively. It also adds contingency plans for various situations such as connection failures, thus providing corresponding solutions for situations that may affect the normal operation of seamless roaming and improving the robustness of the seamless roaming process.
[0069] The steps described above are for clarity only. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.
[0070] Another embodiment of this application relates to a terminal, as shown in FIG6, including at least one processor 501; and a memory 502 communicatively connected to the at least one processor; wherein the memory 502 stores instructions executable by the at least one processor 501, the instructions being executed by the at least one processor 501 to enable the at least one processor 501 to perform the seamless roaming method as described above.
[0071] The memory 502 and processor 501 are connected via a bus, which can include any number of interconnecting buses and bridges. The bus connects various circuits of one or more processors 501 and memory 502 together. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. A bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by processor 501 is transmitted over a wireless medium via an antenna, which further receives data and transmits it to processor 501.
[0072] Processor 501 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory 502 can be used to store data used by processor 501 during operation.
[0073] Another embodiment of this application relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the method embodiments described above.
[0074] That is, those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.
[0075] Those skilled in the art will understand that the above embodiments are specific implementations of this application, and in practical applications, various changes can be made in form and detail without departing from the spirit and scope of this application.
Claims
1. A seamless roaming method applied to a terminal, the method comprising: During seamless roaming, when the seamless roaming fallback condition is triggered, the terminal exits the seamless roaming domain and chooses to fall back to a non-seamless roaming mode to access the target access point; or, When the terminal initially accesses the seamless roaming domain, if the seamless roaming fallback condition is triggered, it can choose to fall back to a non-seamless roaming mode to access the target access point. The seamless roaming rollback conditions include: Multiple attempts to switch from the original access point to the target access point in a seamless roaming manner failed; multiple attempts to negotiate or transmit the context to the target access point failed; attempts to switch from the original access point to multiple target access points in a seamless roaming manner failed; and data path switching failed.
2. The seamless roaming method according to claim 1, wherein, The method further includes: Receive a seamless roaming response frame carrying a status code, or a seamless roaming initial access response frame carrying the status code, or a seamless roaming confirmation frame carrying the status code from the target access point. The status code is the encoding corresponding to the reason for the target access point's refusal to access, and its length is 16 bits.
3. The seamless roaming method according to claim 2, wherein, The status code is a decimal code used to expand the status code table in wireless communication standards.
4. The seamless roaming method according to claim 1, wherein, The method further includes: During seamless roaming, during the data buffering period, anchor connections are used to transmit data on behalf of each non-anchor connection; When there is a conflict between the data transmitted on the anchor connection and the data transmitted on each non-anchor connection, the data transmitted on the anchor connection and the data transmitted on each non-anchor connection are sorted according to priority and then transmitted in sequence.
5. The seamless roaming method according to claim 4, wherein, The method further includes: Before using anchor connections to transmit data on behalf of various non-anchor connections, preset anchor connection transmission restrictions are used to filter and restrict the data to be transmitted on behalf of the anchor connections. The preset anchor connection transmission constraints will be based on one or any combination of the following elements: Whether the data transmitted on the non-anchor connection is low-latency data, the quality of service requirements for the data transmitted on the non-anchor connection, the latency requirements for the data transmitted on the non-anchor connection, the access type of the data transmitted on the non-anchor connection, whether the service priority is higher than that of the data transmitted on the anchor connection, the bandwidth of the anchor connection, the working bandwidth of the anchor connection, and the spatial stream of the anchor connection.
6. The seamless roaming method according to claim 1, wherein, The method further includes: During seamless roaming, when uplink buffered data and downlink buffered data are transmitted through the same connection, the transmission order of the uplink buffered data or downlink buffered data will be determined according to their respective transmission requirements. When there are uplink buffered data and downlink buffered data with the same transmission requirements, determine whether to prioritize the transmission of uplink buffered data or downlink buffered data. The transmission requirements include one or any combination of the following: Priority requirements, access type requirements, service identifier requirements, and service quality requirements.
7. The seamless roaming method according to claim 6, wherein, Both the uplink buffered data and the downlink buffered data have their own data thresholds to be transmitted. The method further includes: During seamless roaming, if the amount of uplink or downlink buffered data in the buffer exceeds the corresponding threshold for data to be transmitted, the data exceeding the threshold will continue to be buffered, or only the data within the threshold will be transmitted during seamless roaming.
8. The seamless roaming method according to claim 1, wherein, The method further includes: When a device does not support having more than one connection with both the original access point and the target access point during seamless roaming, it will achieve seamless roaming by caching the data transmitted between itself and the original access point and establishing a connection with the target access point.
9. The seamless roaming method according to claim 1, wherein, The method further includes: During seamless roaming, the selection of seamless roaming handover mode will be restricted based on whether the original access point and / or the target access point are non-simultaneous mobile access points. The seamless roaming handover methods include: Over-the-Air method, Over-the-DS method, and anchor-based handover method; In the anchor-connection-based switching method, the primary connection of the simultaneous sending and receiving mobile access points is designated as the anchor connection.
10. A terminal, comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the seamless roaming method as described in any one of claims 1 to 9.
11. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the seamless roaming method according to any one of claims 1 to 9.