Roaming deadline updating method and related product

Abstract

The invention discloses a roaming deadline updating method and a related product. The method comprises the steps that a non-AP MLD generates a first frame, the first frame comprises first information, and the first information is used for requesting to update the roaming deadline of the non-AP MLD; and transmitting the first frame. And the target AP MLD receives the first frame, and updates the roaming deadline of the non-AP MLD according to the first frame. By adopting the method provided by the embodiment of the invention, the roaming deadline of the non-AP MLD can be updated, so that the non-AP MLD can achieve roaming more flexibly without causing resource waste.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and in particular to a roaming deadline update method and related products. Background Technology

[0002] When an access point (AP) provides service to a station (STA) (or a non-AP STA), the signal quality decreases with the distance between the AP and the STA. When the signal quality of the connection between the AP and the STA deteriorates to a certain level, the STA is no longer suitable to associate with that AP and will want to roam to another AP with better signal quality to maintain normal data transmission.

[0003] During roaming from the current AP to the target AP, re-establishing the connection requires additional time, leading to increased latency. Simultaneously, data continuity is affected due to the data path switching, potentially causing an increase in packet loss. To achieve ultra-high reliability (UHR), which includes reducing data loss and latency and improving data transmission continuity, seamless roaming was proposed. In essence, various methods can effectively shorten the re-association process between the STA and the target AP and enhance data continuity during this process, thus achieving seamless roaming. The introduction of multi-link devices (MLDs) in IEEE 802.11be effectively improved data transmission throughput. Correspondingly, the focus of seamless roaming shifted to the roaming of non-AP MLDs from the current AP MLD to the target AP MLD.

[0004] In the two existing seamless roaming architectures, the roaming deadline is selected in a single way. The advantage of this approach is its simplicity and directness, but the disadvantage is a lack of flexibility, making it difficult to choose a suitable deadline. If the deadline is too short, many non-AP MLDs in the seamless roaming domain may be unable to send roaming requests in time, thus failing to achieve successful roaming. If the deadline is too long, the AP MLD needs to cache the pairwise transient keys (PTKs) of non-AP MLDs preparing for roaming for an extended period and reserve roaming resources for them. This also results in the AP MLD needing to prepare for roaming for a large number of non-AP MLDs, leading to a waste of resources. Summary of the Invention

[0005] This application provides a roaming deadline update method and related products, which can update the roaming deadline of non-AP MLDs, enabling non-AP MLDs to achieve roaming more flexibly without wasting resources.

[0006] The present application is described below from different aspects. It should be understood that the different implementation methods and beneficial effects described below can be referenced from each other.

[0007] In a first aspect, this application provides a roaming deadline update method, the method comprising: generating a first frame, the first frame including first information, the first information being used to request an update of the roaming deadline of a non-access point multi-link device (non-AP MLD); and sending the first frame. The method of the first aspect can be applied to a non-AP MLD or to chips or functional modules configured in a non-AP MLD.

[0008] In this application, a first frame is sent from the non-AP MLD to the target AP MLD to request the target AP MLD to update the roaming deadline of the non-AP MLD. This includes extending the roaming deadline or terminating it early, making the roaming deadline a flexible and adaptable option rather than a single choice. This ensures successful roaming while avoiding resource waste due to excessively long roaming times, thus improving the reliability of the non-AP MLD roaming process.

[0009] In one possible implementation, the method further includes receiving a second frame, the second frame including second information for indicating an update of the roaming deadline for the completed non-AP MLD.

[0010] In this embodiment, the target AP MLD sends a second frame to the non-AP MLD so that the non-AP MLD can determine that the update of the non-AP MLD's roaming deadline has been completed. This avoids the non-AP MLD waiting or resending an update request due to uncertainty about whether the roaming deadline has been updated, thus improving the reliability of the non-AP MLD in determining that the roaming deadline has been updated.

[0011] Secondly, this application provides a roaming deadline update method, the method comprising: receiving a first frame, the first frame including first information, the first information being used to request an update of the roaming deadline of a non-access point multi-link device (non-AP MLD); and updating the roaming deadline of the non-AP MLD.

[0012] The second approach can be applied to AP MLDs or chips or functional modules configured in AP MLDs.

[0013] In one possible implementation, the method further includes sending a second frame, the second frame including second information for indicating an update of the roaming deadline for the completed non-AP MLD.

[0014] In one possible implementation, the first information is used to request an update to the roaming deadline of the non-AP MLD, including: the first information is used to request an extension of the roaming deadline of the non-AP MLD.

[0015] In one possible implementation, the first information includes a first roaming deadline, the duration of which is greater than the duration of the roaming deadline; or the first information includes an extension duration.

[0016] In one possible implementation, the first information is used to request an update to the roaming deadline of the non-AP MLD, including: the first information is used to request an early termination of the roaming deadline of the non-AP MLD.

[0017] In one possible implementation, the first information includes a second roaming deadline, the duration of which is shorter than the duration of the previous roaming deadline; or it includes a request for the roaming deadline to be extended.

[0018] In one possible implementation, the first information is carried in the timeout interval element TIE.

[0019] In this embodiment, the first frame carries an existing TIE to represent the first information for updating the roaming deadline (or the third information for terminating roaming in advance), which allows the existing element structure to be reused to realize the transmission of the first information, reducing the design complexity and reading complexity of the frame content, and improving the transmission and reading efficiency of the first information.

[0020] In one possible implementation, before generating the first frame, the method further includes: determining that the number of times the first information is sent is less than a preset number; and / or determining that the extended roaming deadline is less than or equal to a preset duration.

[0021] In one possible implementation, the preset number of times and / or preset duration are agreed upon in the protocol.

[0022] In one possible implementation, the preset number of times and / or preset duration are configured for the target AP MLD.

[0023] In one possible implementation, a preset number of attempts and / or a preset duration are carried in the beacon frames and / or roaming probe response frames sent by the target AP MLD.

[0024] In one possible implementation, the preset duration is determined based on the validity period of the paired temporary keys of the non-AP MLD and the target AP MLD.

[0025] In one possible implementation, before sending the first frame, the method further includes receiving a roaming preparation response frame, which indicates that roaming preparation for the non-AP MLD has been completed.

[0026] In this embodiment, the method for updating the roaming deadline is combined with a seamless roaming scenario, enabling the non-AP MLD to obtain the updated roaming deadline before initiating a roaming request, thus allowing it to make the roaming request based on the updated deadline. This ensures the timeliness of updating the roaming deadline, increases the probability of successful roaming, and effectively reduces resource waste of the target AP MLD.

[0027] In one possible implementation, the first frame also includes third information, which is used to request communication resources of the target AP MLD.

[0028] In one possible implementation, the second frame also includes fourth information, which is used to confirm the communication resources of the target AP MLD that accepts the request from the first request information.

[0029] In this embodiment of the application, in the scenario where a non-AP MLD requests resources from a target AP MLD during roaming, a method for updating the roaming deadline is proposed. This allows the non-AP MLD to update the roaming deadline simultaneously with initiating the resource request, ensuring that the update occurs during the roaming preparation phase. This guarantees that the non-AP MLD can complete the roaming process according to the pre-determined roaming deadline, further reducing the impact of the roaming deadline update on the roaming process and improving the reliability of the roaming process.

[0030] In one possible implementation, if the first information is used to indicate an extension of the roaming deadline for the non-AP MLD, the first frame corresponds to the third frame type; if the first information is used to indicate an early termination of the roaming deadline for the non-AP MLD, the first frame corresponds to the fourth frame type.

[0031] In this embodiment, the frames used to request an extension of the roaming deadline and to request an early termination of the roaming deadline are set to two different frame types, which makes the design more flexible. At the same time, when the target AP MLD receives the frame and reads the frame type, it can know what kind of update needs to be made, improving the efficiency of updating the roaming deadline based on the first information.

[0032] Thirdly, this application provides a communication device, which may be a non-AP MLD or a chip or functional module configured in a non-AP MLD, and the communication device includes a processing unit and a transceiver unit.

[0033] The processing unit is used to generate a first frame, which includes first information used to request an update to the roaming deadline of the non-access point multi-link device (non-AP MLD); the transceiver unit is used to send the first frame.

[0034] In one possible implementation, the transceiver unit is also configured to receive a second frame, which includes second information indicating an update to the roaming deadline for the completed non-AP MLD.

[0035] Fourthly, this application provides a communication device, which may be an AP MLD or a chip or functional module configured in an AP MLD, and the communication device includes a transceiver unit and a processing unit.

[0036] The transceiver unit is used to receive a first frame, which includes first information used to request an update of the roaming deadline of the non-access point multi-link device (non-AP MLD); the processing unit is used to update the roaming deadline of the non-AP MLD.

[0037] In one possible implementation, the transceiver unit is also used to send a second frame, which includes second information indicating an update of the roaming deadline for the completed non-AP MLD.

[0038] Fifthly, this application provides a communication device, which is a non-AP MLD, comprising a processor for executing the method shown in any possible implementation of the first aspect or any of the above aspects. Alternatively, the processor is configured to execute a program stored in a memory, wherein when the program is executed, the method shown in any possible implementation of the first aspect or any of the above aspects is executed.

[0039] In conjunction with the fifth aspect, in one possible implementation, the memory is located outside the aforementioned communication device.

[0040] In conjunction with the fifth aspect, in one possible implementation, the memory is located within the aforementioned communication device.

[0041] In this application, the processor and memory can also be integrated into a single device, that is, the processor and memory can be integrated together.

[0042] In conjunction with the fifth aspect, in one possible implementation, the communication device further includes a transceiver for sending BTM request frames.

[0043] Sixthly, this application provides a communication device, which is an AP MLD, comprising a processor for executing the method shown in any possible implementation of the second aspect or any of the above-described aspects. Alternatively, the processor is configured to execute a program stored in a memory, wherein when the program is executed, the method shown in any possible implementation of the second aspect or any of the above-described aspects is executed.

[0044] In conjunction with the sixth aspect, in one possible implementation, the memory is located outside the aforementioned communication device.

[0045] In conjunction with the sixth aspect, in one possible implementation, the memory is located within the aforementioned communication device.

[0046] In this application, the processor and memory can also be integrated into a single device, that is, the processor and memory can be integrated together.

[0047] In conjunction with the sixth aspect, in one possible implementation, the communication device further includes a transceiver for receiving BTM request frames.

[0048] In a seventh aspect, embodiments of this application provide a communication device including a logic circuit and an interface, the logic circuit and the interface being coupled; the interface is used for inputting and / or outputting information, and the logic circuit is used for performing the method shown in any possible implementation of the first aspect or any of the aspects described above.

[0049] Eighthly, embodiments of this application provide a communication device including a logic circuit and an interface, the logic circuit and the interface being coupled; the interface is used for inputting and / or outputting information, and the logic circuit is used for performing the methods shown in any possible implementation of the second aspect or any of the above aspects.

[0050] Ninthly, embodiments of this application provide a computer-readable storage medium for storing a computer program that, when run on a computer, causes the methods shown in any possible implementation of the first aspect or any of the aspects described above to be executed.

[0051] In a tenth aspect, embodiments of this application provide a computer-readable storage medium for storing a computer program that, when run on a computer, causes the methods shown in any possible implementation of the second aspect or any of the aspects described above to be executed.

[0052] Eleventhly, embodiments of this application provide a computer program product, which includes a computer program or computer code, which, when run on a computer, causes the method shown in any possible implementation of the first aspect or any of the aspects described above to be executed.

[0053] In a twelfth aspect, embodiments of this application provide a computer program product comprising a computer program or computer code that, when run on a computer, causes the methods shown in any possible implementation of the second aspect or any of the aspects described above to be executed.

[0054] In a thirteenth aspect, embodiments of this application provide a computer program that, when run on a computer, executes the methods shown in any possible implementation of the first aspect or any of the aspects described above.

[0055] In a fourteenth aspect, embodiments of this application provide a computer program that, when run on a computer, executes the methods shown in any possible implementation of the second aspect or any of the aspects described above.

[0056] In a fifteenth aspect, embodiments of this application provide a communication system including a current AP MLD, a target AP MLD, and a non-AP MLD, wherein the target AP MLD is used to perform the method shown in any possible implementation of the second aspect or any of the above aspects, and the non-AP MLD is used to perform the method shown in any possible implementation of the first aspect or any of the above aspects.

[0057] The technical effects achieved in the above aspects can be referred to each other or to the beneficial effects in the method embodiments shown below, and will not be repeated here. Attached Figure Description

[0058] Figure 1a This is a schematic diagram of an architecture of a wireless communication system provided in an embodiment of this application;

[0059] Figure 1b This is a schematic diagram of another architecture of the wireless communication system provided in the embodiments of this application;

[0060] Figure 2a This is a schematic diagram of an application scenario provided by an embodiment of this application;

[0061] Figure 2b A schematic diagram of a general seamless roaming architecture provided for embodiments of this application;

[0062] Figure 2c A schematic diagram illustrating an FT resource request under an air interface transmission mode, provided as an embodiment of this application;

[0063] Figure 2d A schematic diagram illustrating an FT resource request under a DS transmission mode provided in an embodiment of this application;

[0064] Figure 3a A flowchart illustrating a roaming deadline update method provided in this application embodiment;

[0065] Figure 3b This is a schematic diagram of the structure of a first frame provided in an embodiment of this application;

[0066] Figure 3c This is a schematic diagram of another first frame structure provided in an embodiment of this application;

[0067] Figure 4 A flowchart illustrating a method for extending the roaming deadline provided in this application embodiment;

[0068] Figure 5 A flowchart illustrating a method for early termination of roaming deadline provided in this application embodiment;

[0069] Figure 6 A flowchart illustrating a method for early termination of roaming provided in this application embodiment;

[0070] Figure 7a A schematic diagram of a TIE format provided for an embodiment of this application;

[0071] Figure 7b A schematic diagram of a new TIE provided for an embodiment of this application;

[0072] Figure 7c A schematic diagram of another novel TIE provided for embodiments of this application;

[0073] Figure 8 A flowchart illustrating a method for updating roaming expiration time provided in this application embodiment;

[0074] Figure 9 A flowchart illustrating another method for updating the roaming deadline provided in this application embodiment;

[0075] Figure 10 This is a schematic diagram of the communication device provided in an embodiment of this application;

[0076] Figure 11 This is another structural schematic diagram of the communication device provided in the embodiments of this application;

[0077] Figure 12 This is another structural schematic diagram of the communication device provided in the embodiments of this application. Detailed Implementation

[0078] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0079] In the description of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. "And / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can represent: a, b, c; a and b; a and c; b and c; or a and b and c. Where a, b, and c can be single or multiple.

[0080] In the description of this application, the words "first," "second," etc., do not limit the quantity or order of execution, nor do they necessarily imply that they are different. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0081] In this application, the words "exemplary" or "for example" are used to indicate that something is an example, illustration, or illustration. Any embodiment or design described as "exemplary," "for example," or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Rather, the use of the words "exemplary," "for example," or "for example" is intended to present the relevant concepts in a specific manner.

[0082] In this application, the use of singular designations for elements is intended to represent "one or more" rather than "one and only one," unless otherwise specified.

[0083] Continuously improving throughput is a persistent technical goal in the evolution of cellular networks and wireless local area networks (WLANs). WLAN protocols are primarily discussed within the IEEE 802.11 standards group, and previous standards such as 802.11a / b / g / n / ac / ax have consistently improved throughput. The IEEE 802.11be standard, known as Extremely High Throughput (EHT), prioritizes significantly increasing peak throughput as its most important technical objective. To achieve this goal, the next-generation standard IEEE 802.11be incorporates multi-link (ML) as a key technology. Its core idea includes enabling WLAN devices supporting the next-generation IEEE 802.11 standard to transmit and receive across multiple frequency bands, allowing for data transmission using greater bandwidth and thus significantly improving throughput.

[0084] Multi-band Wi-Fi includes, but is not limited to, the 2.4GHz Wi-Fi band, the 5GHz Wi-Fi band, and the 6GHz Wi-Fi band. Access and transmission on each band are called a link, and access and transmission across multiple bands are called multi-link (ML). Multi-link technology is helpful in reducing latency and improving robustness.

[0085] A multi-link device includes one or more affiliated sites, which can be logical sites. In this embodiment, "a multi-link device includes affiliated sites" is also briefly described as "a multi-link device includes sites." Each affiliated site can operate on one frequency band, one channel, or one link. The affiliated site can be an AP or a non-APSTA (or simply STA). A multi-link device whose affiliated site is an AP can be called an AP multi-link device (AP MLD), and a multi-link device whose affiliated site is a non-AP STA can be called a non-AP multi-link device (non-AP MLD).

[0086] When a multi-link device (such as an AP MLD) and another multi-link device (non-AP MLD) transmit data, they can use link identifiers to identify a link or a station on a link. Before communication, the two multi-link devices (such as the AP MLD and the non-AP MLD) can negotiate or communicate the mapping between the link identifier (link ID) and a link or a station on a link. Alternatively, the AP MLD can indicate the mapping between the link identifier and a link or a station on a link through broadcast management frames, such as beacon frames. Therefore, during data transmission, it is not necessary to transmit a large amount of signaling information to indicate the link or the station on the link; carrying the link identifier is sufficient, reducing signaling overhead and improving transmission efficiency.

[0087] In one possible implementation, the multi-link device can implement wireless communication by following the 802.11 family of protocols, for example, following Extremely High Throughput (EHT) or following 802.11be-based or compatible protocols, thereby enabling communication with other devices. Of course, the other devices may or may not be multi-link devices.

[0088] The technical solutions provided in this application can be applied to WLAN systems, such as Wi-Fi. For example, the methods provided in this application can be applied to IEEE 802.11 series protocols, such as the next-generation Wi-Fi protocols of 802.11ax, such as 802.11be, Wi-Fi 7, or EHT, and the next generation of 802.11be, such as 802.11bn, Wi-Fi 8, or UHR, etc., which are not listed here. The technical solutions provided in this application can also be applied to wireless personal area network (WPAN) systems based on ultra-wide bandgap (UWB), sensing systems, etc. For example, the methods provided in this application can be applied to IEEE 802.15 series protocols, such as 802.15.4a, 802.15.4z, or 802.15.4ab, or a future generation of UWB WPAN protocols, etc., which are not listed here. The technical solutions provided in this application can also be applied to the following communication systems, such as Internet of Things (IoT) systems, vehicle-to-X (V2X) systems, narrowband Internet of Things (NB-IoT) systems, devices used in vehicle-to-vehicle systems, IoT nodes and sensors in IoT, smart cameras, smart remote controls, smart water and electricity meters in smart homes, and sensors in smart cities. Alternatively, they can also be applied to long-term evolution (LTE) systems, 5th-generation (5G) communication systems, and new communication systems that will emerge in the future development of communication.

[0089] Although this application primarily uses the deployment of IEEE 802.11 networks as an example, those skilled in the art will readily understand that the various aspects covered in this application can be extended to other networks employing various standards or protocols, such as high-performance radio LANs (HIPERLANs) (a wireless standard similar to IEEE 802.11, primarily used in Europe), wide area networks (WANs), wireless local area networks (WLANs), personal area networks (PANs), or other networks now known or to be developed in the future.

[0090] See Figure 1a , Figure 1a This is a schematic diagram of an architecture of a wireless communication system provided in an embodiment of this application. Figure 1aAs shown, the wireless communication system includes at least two AP MLDs (such as...). Figure 1a AP MLD100 and AP MLD200) and at least one non-AP MLD (such as Figure 1a (non-AP MLD300). Optional. Figure 1a It can also include traditional sites that only support transmission over a single link (such as...). Figure 1a The single-link non-AP STA400 (also known as STA400) is used in this context. The AP MLD provides services to the non-AP MLD, and the non-AP MLD can communicate with the AP MLD using multiple links to improve throughput. A STA within a non-AP MLD can also communicate with an AP within an AP MLD via a single link. Understandably... Figure 1a The use of non-AP MLD as a mobile phone and AP MLD as a router in this application is merely an example and does not imply any limitation on the types of AP MLD and non-AP MLD used in this application. It is also understood that... Figure 1a The number of AP MLDs and non-AP MLDs is merely exemplary. The number of AP MLDs or non-AP MLDs in the wireless communication system may be more or less, and this application does not limit this.

[0091] In the embodiments of this application, the term "communication" can also be described as "data transmission," "information transmission," or "transmission." The term "transmission" can refer to sending and receiving in general.

[0092] See Figure 1b , Figure 1b This is a schematic diagram of another architecture of the wireless communication system provided in the embodiments of this application. For example... Figure 1b As shown, an AP MLD consists of n stations, where n is a positive integer. The diagram uses n=2 as an example, meaning the n stations in the AP MLD are AP1 and AP2. A non-AP MLD also consists of n stations, which are STA1 and STA2 in the diagram. Communication between MLDs is multi-link communication. Figure 1bLink 1 and Link 2 in the network constitute a multi-link system. In other words, the AP MLD and the non-AP MLD can communicate in parallel using Link 1, Link 2, ..., Link n. One AP in the AP MLD can establish a link with one STA in the non-AP MLD. For example, STA1 in the non-AP MLD establishes Link 1 with AP1 in the AP MLD, STA2 in the non-AP MLD establishes Link 2 with AP2 in the AP MLD, STAn in the non-AP MLD establishes Link n with APn in the AP MLD, and so on. Exemplarily, the multi-link device in this application embodiment can be a single-antenna device or a multi-antenna device. For example, it can be a device with two or more antennas. This application embodiment does not limit the number of antennas included in the multi-link device.

[0093] The frequency bands in which multi-link devices can operate may include, but are not limited to: sub 1GHz, 2.4GHz, 5GHz, 6GHz and high frequency 60GHz.

[0094] For example, a multi-link device (which can be either a non-AP MLD or an AP MLD) can be a device with wireless communication capabilities. This device can be a complete device or a chip or processing system installed in a complete device. Devices with these chips or processing systems installed can implement the methods and functions of the embodiments of this application under the control of these chips or processing systems. For example, the non-AP MLD in the embodiments of this application has wireless transceiver capabilities, can support the 802.11 series protocols, and can communicate with AP MLDs, single-link devices, or other non-AP MLDs. For example, a non-AP MLD is any user communication device that allows users to communicate with an AP and thus with a WLAN. For example, a non-AP MLD can be a tablet computer, desktop computer, laptop computer, ultra-mobile personal computer (UMPC), handheld computer, netbook, personal digital assistant (PDA), mobile phone, or other network-connected user devices, or an IoT node in the Internet of Things, or an in-vehicle communication device in the Internet of Vehicles; a non-AP MLD can also be a chip and processing system in the above-mentioned terminals. An AP MLD is a device that can provide services to a non-AP MLD and can support the 802.11 series of protocols. For example, an AP MLD can be a communication server, router, switch, bridge, or other communication entity. Alternatively, an AP MLD can include various forms of macro base stations, micro base stations, relay stations, etc. Of course, an AP MLD can also be the chip and processing system within these various types of devices, thereby implementing the methods and functions of the embodiments of this application. The 802.11 protocol can be a protocol that supports or is compatible with 802.11be.

[0095] Understandably, multi-link devices can support high-speed, low-latency transmission. With the continuous evolution of wireless LAN application scenarios, multi-link devices can be applied to even more scenarios, such as sensor nodes in smart cities (e.g., smart water meters, smart electricity meters, smart air quality monitoring nodes), smart devices in smart homes (e.g., smart cameras, projectors, displays, televisions, speakers, refrigerators, washing machines, etc.), nodes in the Internet of Things (IoT), entertainment terminals (e.g., AR, VR wearable devices), smart devices in smart offices (e.g., printers, projectors, etc.), vehicle-to-everything (V2X) devices, and some infrastructure in daily life scenarios (e.g., vending machines, supermarket self-service navigation kiosks, self-checkout machines, self-ordering machines, etc.). In this application embodiment, the specific forms of non-AP MLD and AP MLD are not limited; they are merely illustrative examples.

[0096] The following is a brief description of the application scenarios involved in the embodiments of this application.

[0097] When an AP provides service to a non-AP STA, the signal quality degrades with the distance between the AP and the non-AP STA. When the signal quality between the AP and the non-AP STA drops to a certain level, the non-AP STA is no longer suitable to associate with that AP and will instead want to roam to another AP with better signal quality to maintain normal data transmission.

[0098] The primary goal of IEEE 802.11bn is to achieve ultra-high reliability, which includes reducing data loss and latency, and improving data transmission continuity. During roaming from the current access point (STA) to the target STA, re-establishing the connection requires additional time, leading to increased latency. Simultaneously, data continuity is affected by the data channel switching, potentially causing an increase in packet loss. Seamless roaming, a key feature of 802.11bn, was proposed to address this issue. In essence, various methods can effectively shorten the re-association process between the STA and the target STA, and enhance data continuity during this process, thus achieving seamless roaming.

[0099] A basic service set (BSS) is a fundamental module of an IEEE 802.11 local area network (LAN) and consists of multiple STAs (Stations). A key protocol in existing WiFi standards for enabling fast roaming is the Fast BSS Transition (FT) protocol, proposed in 802.11r. The FT protocol defines a mobility domain, which can include multiple BSSs. With the support of the FT protocol, STAs can quickly switch between BSSs within the same mobility domain. A non-AP STA leaving its current BSS and joining a new BSS means that a non-AP STA needs to disconnect from its currently associated AP and re-associate with a new AP. For example, see... Figure 2a , Figure 2a This is a schematic diagram illustrating an application scenario provided in an embodiment of this application. For example... Figure 2a As shown, there are four access points (APs) near the non-AP STA: AP1, AP2, AP3, and AP4. Assume the non-AP STA is currently associated with AP1, but is about to detach from AP1. Therefore, the non-AP STA needs to choose one of the remaining three APs (AP2, AP3, and AP4) for reassignment. If the non-AP STA chooses AP2, then AP2 becomes the target AP.

[0100] To achieve rapid handover, FT supports STA to negotiate a pairwise transient key (PTK) with the target AP in advance and allows STA to make resource requests in advance. This greatly shortens the process of STA establishing reassociation with the target AP, thereby achieving the effect of rapid handover.

[0101] The FT protocol has a reassociation deadline time. Generally speaking, after completing the FT preparation process with the target AP, the STA must send a reassociation request before a certain deadline; otherwise, the STA will need to complete the entire preparation process with the target AP again. Specifically, the interval between the FT request (or Authentication-Request) and the reassociation request during the FT process must not exceed the set reassociation deadline time.

[0102] While the FT protocol effectively speeds up roaming, 802.11bn is still seeking methods to achieve faster handovers and better maintain data continuity in order to achieve seamless roaming. Meanwhile, the introduction of multi-link devices (MLDs) in 802.11be has also brought new possibilities to seamless roaming. Considering that MLDs will become mainstream in 802.11bn and that MLDs can better achieve seamless roaming, roaming in 802.11bn mainly refers to the handover of a non-AP MLD from the current AP MLD to the target AP MLD. The two main current seamless roaming architectures include enhanced FT and roaming AP MLD. Similar to the reassociation deadline in FT, roaming deadline constraints can be introduced in both seamless roaming architectures.

[0103] The following section introduces the enhanced FT architecture and the roaming AP MLD architecture.

[0104] Enhanced FT is an improvement on the FT protocol. By introducing context transfer, it shortens the reassociation process between the non-AP MLD and the target AP MLD, enhancing the continuity of data transmission. Furthermore, because it extends to multi-link scenarios, Enhanced FT also includes the configuration of multiple links between the non-AP MLD and the target AP MLD.

[0105] The roaming AP MLD architecture extends the concept of AP MLD. In this architecture, two or more AP MLDs can logically belong to the same larger roaming AP MLD. This means that even if a non-AP MLD switches from its current AP MLD to the target AP MLD, it remains logically associated with the same roaming AP MLD; the only difference is the link between them. Therefore, the roaming process is equivalent to link reconfiguration. This architecture also utilizes context passing to shorten link reconfiguration time and enhance data continuity.

[0106] See also Figure 2b , Figure 2b A schematic diagram of a general seamless roaming architecture provided for embodiments of this application, as shown below. Figure 2b As shown, this roaming architecture can be used to describe both enhanced FT architectures and roaming AP MLD architectures. The dashed lines in the diagram represent data transmission that can occur either directly between the non-AP MLD and the target AP MLD via the air interface (over-the-air), or via the non-AP MLD through the current AP MLD to the target AP MLD (over-the-DS). Groups of non-AP MLDs that can achieve seamless roaming can be called seamless roaming domains; for example, the current AP MLD and the candidate target AP MLD are in the same seamless roaming domain. The frame names in the attached diagram can also be replaced according to the following correspondence:

[0107] Roaming probe request / response: probe request / response, FT probe request / response;

[0108] Roaming preparation request / response: authentication request / response, FT request / response;

[0109] Roaming request / response: reassociation request / response, roaming announcement indicator / response, link reconfiguration request / response.

[0110] The Enhanced FT architecture and the Roaming AP MLD architecture, two architectures for seamless roaming, share many similarities. Broadly speaking, seamless roaming can be divided into the following two phases (the names of these two phases may vary in different proposals):

[0111] (1) Roaming Preparation Phase: This phase involves completing the necessary preparations for the non-AP MLD to roam from the current AP MLD to the target AP MLD. During this phase, the non-AP MLD remains associated with the current AP MLD. An essential part of roaming preparation is the renegotiation or sharing of pairwise temporary keys (PTKs). To further expedite the switch to the target AP MLD, semi-static context transfers can be performed, including certain block ack (BA) parameters (e.g., TID, BA policy, Buffer Size, etc.), stream classification service (SCS), target wake time (TWT), etc. Because these semi-static contexts hardly change during roaming, they can be transferred in advance to shorten roaming time. For enhanced FT architectures, multi-link setup is also required.

[0112] (2) Roaming Transition Phase: In this phase, the non-AP MLD switches from the current AP MLD to the target AP MLD. This requires DSremapping, which changes the data path from the non-AP MLD to the DS from passing through the current AP MLD to passing through the target AP MLD. Additionally, context passing (either semi-static or dynamic context) is performed during this phase. Optionally, to prevent data loss, data forwarding from the current AP MLD to the target AP MLD may be performed.

[0113] In addition, before the roaming preparation phase, the non-AP MLD needs to collect information about the candidate target AP MLD. This process can be either the non-AP MLD passively receiving information from the candidate target AP MLD, such as its broadcast beacon frames, or the non-AP MLD actively exchanging roaming probe request / response frames with the candidate target AP MLD through air interface transmission or DS transmission to obtain relevant information.

[0114] Additionally, the existing FT resource request protocol allows non-AP MLDs to request certain types of resources from the target AP MLD before sending a reassociation request. This resource request can be implemented in two ways: via air interface transmission or via DS transmission.

[0115] See also Figure 2c , Figure 2c This is a schematic diagram of an FT resource request under an air interface transmission mode provided in an embodiment of this application, as shown below. Figure 2c As shown, in the air interface transmission mode, the non-AP MLD directly sends an authentication-confirm request frame to the target AP MLD, which includes information related to the resource request. Then, the target AP MLD replies with an authentication-Ack frame to the non-AP MLD, confirming that the resource request has been accepted.

[0116] See also Figure 2d , Figure 2d This is a schematic diagram of an FT resource request under the DS transmission mode provided in an embodiment of this application, as shown below. Figure 2dAs shown, in the DS transmission mode, the non-AP MLD sends an FT confirm request frame to the target AP MLD via the current AP MLD, which includes information related to the resource request. Then, the target AP MLD replies with an FT Ack frame to the non-AP MLD via the current AP MLD, confirming that the resource request has been accepted.

[0117] The standard stipulates that the reassociation deadline in FT should be consistently managed across the entire mobility domain. That is, the reassociation deadline within a mobility domain is a specific value, and the specific value chosen depends on the implementation. In the example code provided in the standard, the default value for the reassociation deadline is set to 1000 time units (TUs), which is approximately 1 second (1024μs * 1000). The rules for setting the roaming deadline in enhanced FT are the same as those for setting the reassociation deadline in FT, so the roaming deadline is also set to a specific value based on the specific implementation.

[0118] In the roaming AP MLD architecture, there is currently no strict definition of a roaming deadline. However, considering that the target AP MLD has already reserved resources for the non-AP MLD during the roaming preparation phase, setting a deadline for sending roaming request frames is natural and reasonable to avoid indefinitely occupying the target AP MLD's resources. Since there are currently no specific rules for setting this deadline, it is assumed that the method for setting the roaming deadline in the roaming AP MLD architecture is the same as that in the enhanced FT architecture, i.e., it is set to a specific value within a roaming domain.

[0119] Based on the description of the application scenarios involved in the embodiments of this application, it is clear that the selection of the roaming deadline is singular within a seamless roaming domain. If the deadline is too short, many non-AP MLDs in the seamless roaming domain may struggle to send roaming requests in time, thus failing to achieve successful roaming. If the deadline is too long, the APMLD needs to cache the PTK of non-AP MLDs preparing for roaming for an extended period and reserve roaming resources for them. This also results in the APMLD needing to prepare for roaming for a large number of non-AP MLDs, leading to resource waste. Furthermore, compared to FT, seamless roaming requires more tasks during the roaming preparation phase, such as semi-static context transfer and multi-link setup. This makes the time consumption of the preparation phase more uncertain. Since the roaming preparation phase is included within the roaming deadline, estimating a suitable deadline becomes even more difficult.

[0120] In addition, non-AP MLDs may need to update their roaming deadlines under certain special circumstances, which makes it difficult for a single, static deadline to support seamless roaming. For example, consider the following two situations: (1) The non-AP MLD is unable to send a roaming request due to interference. This interference may be internal, such as caused by in-device coexistence (IDC) issues (e.g., interference from Bluetooth signals inside the non-AP MLD), or it may be external, such as signal interference from overlapping BSSs (OBSS). (2) The non-AP MLD's estimation of its movement is not accurate enough, resulting in the non-AP MLD still being within the suitable service range of the current AP MLD when the deadline is approaching, and there is no need to roam to the target AP MLD temporarily. In both scenarios, if the non-AP MLD anticipates needing to roam again in a short period (e.g., after the interference ends, or after the non-AP MLD moves into the service range of the target AP MLD after a period of time), then the non-AP MLD will want to extend the roaming deadline to avoid the overhead of another roaming preparation phase. If the non-AP MLD anticipates being unable to roam or no longer needing to roam in a longer period (e.g., due to prolonged interference, or the non-AP MLD not expecting to approach the target AP MLD again), then the non-AP MLD will want to terminate the roaming process early to release the resources occupied at the target AP MLD and reduce resource waste.

[0121] Example 1:

[0122] Based on the above description, embodiments of this application provide a method for updating roaming expiration time, such as... Figure 3a As shown, the method includes the following steps:

[0123] 101. The non-AP MLD generates the first frame, which includes the first information. The first information is used to request an update to the roaming deadline of the non-AP MLD of the non-access point multilink device.

[0124] This application embodiment includes at least two AP MLDs: the current AP MLD and the target AP MLD. The current AP MLD is the AP MLD currently associated with the non-AP MLD, and the target AP MLD is the AP MLD to which the non-AP MLD is expected to roam, or it can also be referred to as the AP MLD to which the non-AP MLD is expected to establish re-association or perform link reconfiguration. For details regarding the roaming, re-association, and link reconfiguration of the non-AP MLD, please refer to the relevant descriptions in the aforementioned application scenarios, which will not be repeated here.

[0125] The roaming deadline is the time between sending the roaming preparation request frame and sending the roaming request frame (see reference). Figure 2b (Interaction flow within the system). The initial roaming deadline is a specific value, such as 1000 TUs.

[0126] The non-AP MLD generates a first frame, which includes initial information for requesting an update to its own roaming deadline.

[0127] Optionally, the first information is used to request an extension of the roaming deadline.

[0128] For example, suppose the (initial) roaming deadline is T1. In some cases, such as when a non-AP MLD is temporarily unable to issue a roaming request due to interference, it may wish to resume roaming after the interference ends. Therefore, the non-AP MLD sends a first message requesting an extension of the roaming deadline.

[0129] Optionally, the first information includes a first roaming deadline (extended roaming deadline), the duration of which is greater than the length of the roaming deadline.

[0130] For example, the first roaming deadline is T2, where T2 > T1. For instance, T2 can be 1500 TUs. The first information request updates the roaming deadline to the first roaming deadline, thereby extending the roaming deadline.

[0131] Optionally, the first information may include the duration of the extension.

[0132] For example, if the extension period is T0, the first information request adds the extension period to the roaming deadline. Then the updated roaming deadline is T1 + T0, where T0 > 0.

[0133] Optionally, the first information may also include indication information for the extension type.

[0134] For example, the extension type indication information is used to indicate whether the first information includes an extended roaming deadline or an extended duration. For instance, the indication information corresponds to an additional 1 bit. When this 1-bit indication information is 1, it indicates that the first information includes the extended roaming deadline. When the indication information is 0, it indicates that the first information includes the extended duration.

[0135] Optionally, before generating the first frame, the method further includes: determining that the extended roaming deadline is less than or equal to a preset duration.

[0136] Optionally, the preset duration is as specified in the protocol and / or configured in the target AP MLD.

[0137] The first information generated by the non-AP MLD has certain limitations. For example, the extended roaming deadline must be less than or equal to a preset duration. For instance, the preset duration can be a value relative to the initial roaming deadline. For example, it could be twice the roaming deadline, i.e., preset duration = 2 * T1. In this way, when the initial roaming deadline of the seamless roaming domain changes, the maximum roaming deadline will automatically change accordingly. Alternatively, the preset duration can be a specific roaming deadline value that is greater than the initial roaming deadline, for example, 2000 TUs. In this case, the initial roaming deadline is equivalent to a soft deadline (which can be updated and extended), while the preset duration is a hard deadline (which cannot be exceeded).

[0138] Additionally, the validity period of a PTK is a default limitation; without setting a preset duration, the extended expiration date cannot exceed the PTK's validity period. If a preset duration is set, the preset duration must be less than or equal to the PTK's validity period.

[0139] Optionally, before sending the first frame, the non-AP MLD determines that the number of times the first information is sent does not exceed a preset number.

[0140] The preset number of attempts can be specified by the protocol and / or configured by the target AP MLD.

[0141] The first piece of information can be used to request an extension of the roaming deadline, which can correspond to a preset number of times, or the number of times it is used to request an extension of the roaming deadline and the number of times it is used to request early termination of the roaming deadline can be combined to correspond to a preset number of times.

[0142] Optionally, if the preset number of times and / or preset duration are configured by the target AP MLD, they can be sent to the non-AP MLD via beacon frames or roaming probe response frames.

[0143] Optionally, the first piece of information is used to request an early termination of the roaming deadline.

[0144] For example, in some cases, such as when the non-AP MLD's estimation of its movement is inaccurate, the non-AP MLD may not actually enter the service range of the target AP MLD for an extended period, thus eliminating the need for roaming to the target AP MLD. Therefore, the non-AP MLD sends a first message requesting early termination of the roaming deadline.

[0145] Optionally, the first information includes a second roaming deadline, the duration of which is less than the duration of the roaming deadline.

[0146] For example, the first roaming deadline is T3, where T3 < T1. The first information request to terminate roaming early directly ends the current roaming state of the non-AP MLD. This ensures that the process of terminating the roaming deadline early is consistent with the aforementioned process of extending the roaming deadline, both involving time updates based on the existing roaming deadline. This reduces the design complexity of the first frame.

[0147] Optionally, the first information may include request information regarding the termination of the roaming request.

[0148] For example, the first information is used to request roaming termination, directly ending the current roaming status of the non-AP MLD. Optionally, roaming termination can be requested using a 1-bit indication. This 1-bit indication can be 1. This improves the processing efficiency of the target AP MLD for the first information, quickly achieving the process of ending the non-AP MLD roaming.

[0149] Alternatively, the first frame may also be referred to as the roaming update request frame.

[0150] For example, a non-AP MLD can send the first message in the same frame requesting an extension of the roaming deadline and an early termination of the roaming deadline. For instance... Figure 3b As shown, Figure 3b This is a schematic diagram of the structure of a first frame provided in an embodiment of this application. The frame type of the first frame is a specific field in the frame body, which can be indicated by this specific field. That is, this specific field indicates that the first frame is used for updating the roaming deadline. In addition, when the first information in the first frame is used to request an extension of the roaming time, it corresponds to the first content; when the first information in the first frame is used to request an early termination of the roaming deadline, it corresponds to the second content.

[0151] Setting the frame used to request an update to the roaming deadline as a single frame can reduce the design complexity of the frame structure.

[0152] Optionally, the first frame may also include 1 bit of content indication information to indicate the content of the first information. For example, when the 1 bit is 0, it indicates that the first information in the first frame corresponds to the first content; when the 1 bit is 1, it indicates that the first information corresponds to the second content.

[0153] Optionally, if the first frame is used to request an extension of the roaming deadline, it can be called a roaming extend request frame; if the first frame is used to request an early termination of the roaming deadline, it can be called a roaming terminate request frame.

[0154] For example, a non-AP MLD can send the first message requesting an extension of the roaming deadline and an early termination of the roaming deadline in different frames. For example... Figure 3c As shown, Figure 3c This is a schematic diagram of another first frame structure provided in an embodiment of this application. When the first frame is a roaming extension request frame, it corresponds to the third frame type and the first content; when the first frame is a roaming termination request frame, it corresponds to the fourth frame type and the second content. Similarly, the third frame type or the fourth frame type can be indicated by specific fields in the frame body. The third frame type indicates that the first frame is a frame used to extend the roaming deadline, and the fourth frame type indicates that the first frame is a frame used to terminate the roaming deadline early.

[0155] Setting up two separate frames for requesting extended roaming deadlines and requests for early termination of roaming deadlines allows for greater design flexibility. Furthermore, when the target AP MLD receives a frame and reads its type, it can determine the necessary updates, improving the efficiency of updating the roaming deadline based on this initial information.

[0156] 102. The non-AP MLD sends the first frame. Correspondingly, the target AP MLD receives the first frame.

[0157] For example, the non-AP MLD generates a first frame and sends the first frame to the target AP MLD so that the target AP MLD updates the roaming deadline of the non-AP MLD based on the first information in the first frame.

[0158] Optionally, the non-AP MLD sends the first frame to the target AP MLD, including two cases:

[0159] (1) The non-AP MLD directly sends the first frame to the target AP MLD. That is, the air interface transmission method.

[0160] (2) The non-AP MLD sends the first frame to the current AP MLD, and the current AP MLD forwards the first frame to the target AP MLD. This is the DS transmission mode.

[0161] The communication method between the non-AP MLD and the target AP MLD can be a fixed choice or a method that can be flexibly changed based on factors such as signal quality. For example, when the Received Signal Strength Indicator (RSSI) between the non-AP MLD and the current AP MLD is good, DS transmission can be considered; when the RSSI between the non-AP MLD and the target AP MLD is good, air interface transmission may be preferred. No restrictions are imposed here. 103. The target AP MLD updates the roaming deadline of the non-AP MLD based on the first frame.

[0162] After the target AP MLD receives the first frame, it reads the first information in it and updates the roaming deadline of the non-AP MLD according to the first information, including extending the roaming deadline of the non-AP MLD or terminating the roaming deadline of the non-AP MLD in advance.

[0163] Optionally, assuming the target AP MLD has a preset number of times and / or a preset duration, and the first message sent by the non-AP MLD does not meet the preset number of times and / or preset duration limit, the target AP MLD may refuse to update the roaming deadline of the non-AP MLD.

[0164] Optionally, after step 103 (after updating the roaming deadline of the non-AP MLD), the method may further include: 104, the target AP MLD sends a second frame to the non-AP MLD, the second frame including second information, the second information being used to indicate that the update of the roaming deadline of the non-AP MLD has been completed.

[0165] For example, the second frame can be called a roaming update response frame. Alternatively, if the first frame is a roaming extend request frame, the second frame can be a roaming extend response frame; if the first frame is a roaming terminate request frame, the second frame can be a roaming terminate response frame. The target AP MLD sends the second frame to the non-AP MLD so that the non-AP MLD can determine that its roaming deadline update has been completed. This avoids the non-AP MLD waiting or resending update requests due to uncertainty about whether the roaming deadline has been updated, thus improving the reliability of the non-AP MLD's determination that the roaming deadline has been updated. The type of the second frame can also be indicated by specific fields in the frame body. The second frame type indicates that the second frame is used to respond to the roaming deadline update.

[0166] Optionally, after the target AP MLD extends the roaming deadline, it replies with a roaming update response frame to confirm that the deadline has been updated. Before the original deadline, the non-AP MLD can send roaming update request frames multiple times to request an extension of the roaming deadline. The exchange of roaming update request frames and roaming update response frames also achieves the negotiation of the roaming deadline.

[0167] Optionally, after the target AP MLD terminates the roaming deadline of the non-AP MLD, the target AP MLD does not need to reply with a roaming update response frame to the non-AP MLD, and the non-AP MLD assumes that the roaming process has been terminated.

[0168] In this embodiment, a first frame is sent from the non-AP MLD to the target AP MLD to request the target AP MLD to update its roaming deadline, including extending or prematurely terminating the roaming deadline. This allows the roaming deadline to be flexible and variable, rather than a single, fixed option. This ensures successful roaming while avoiding resource waste due to excessively long roaming times, thus improving the reliability of the non-AP MLD roaming process.

[0169] The above embodiment describes a method for updating the roaming deadline. This method can be integrated with existing communication architectures.

[0170] Example 2: This application combines the method of extending the roaming deadline with a seamless roaming architecture. Please refer to the following for details. Figure 4 , Figure 4 A flowchart illustrating a method for extending the roaming deadline provided in this application embodiment:

[0171] 201. The non-AP MLD sends a roaming preparation request frame. Correspondingly, the target AP MLD receives the roaming preparation request frame.

[0172] 202. The target AP MLD sends a roaming preparation response frame. Correspondingly, the non-AP MLD receives the roaming preparation response frame.

[0173] The target AP MLD and non-AP MLD can be transmitted over the air or via DS, and there is no limitation here.

[0174] The roaming deadline is the time between the sending of the roaming preparation request frame and the sending of the roaming request frame. Therefore, the roaming deadline begins after the non-AP MLD sends the roaming preparation request frame. This initial roaming deadline is the first possible roaming deadline. Between the target AP MLD receiving the roaming preparation request frame and sending the roaming preparation response frame, steps such as PTK renegotiation or PTK sharing, multi-link configuration, and semi-static context passing can still occur. These will not be elaborated upon here.

[0175] 203. The non-AP MLD sends the first frame, which includes first information used to request an extension of the roaming deadline. Correspondingly, the target AP MLD receives the first frame.

[0176] For several possible reasons, the non-AP MLD found itself unable to initiate a roaming request within the initial roaming deadline. Therefore, the non-AP MLD sent a first frame to the target AP MLD to request an extension of the roaming deadline.

[0177] As described in Embodiment 1 above, the non-AP MLD can send the first frame to the target AP MLD via either air interface transmission or DS transmission. Either method can be selected, or the two communication methods can be changed depending on the communication quality. Further details will not be provided here.

[0178] 204. The target AP MLD extends the roaming deadline based on the first information.

[0179] 205. The target AP MLD sends a second frame, which includes second information indicating that the roaming deadline has been extended. Correspondingly, the non-AP MLD receives the second frame.

[0180] After receiving the first message, the target AP MLD agrees to extend the roaming deadline as indicated in the first message. The roaming deadline of the non-AP MLD is then updated to the extended roaming deadline. A second frame can then be sent to the non-AP MLD, indicating that the roaming deadline has been extended (or, assuming the roaming deadline was not extended exactly as indicated in the first message, but rather updated to a range within its own limits, the second frame may also include the extended roaming deadline). Upon receiving the second frame, the non-AP MLD knows it can initiate a roaming request according to the extended roaming deadline.

[0181] Optionally, the first frame can be a roaming update request frame, and the second frame can be a roaming update response frame; or the first frame can be a roaming extension request frame, and the second frame can be a roaming extension response frame. The specific description is the same as in the aforementioned Embodiment 1, and will not be repeated here.

[0182] The following steps are optional:

[0183] 206. During the extended roaming deadline, the non-AP MLD sends a roaming request frame. Correspondingly, the target AP MLD receives the roaming request frame.

[0184] The roaming request frame is sent after the first frame. The deadline for sending the roaming request frame is the extended roaming deadline.

[0185] 207. The target AP MLD sends a roaming response frame, and correspondingly, the non-AP MLD receives the roaming response frame.

[0186] After receiving the roaming request frame, the target AP MLD can perform a reassociation process or a link reconfiguration process between the non-AP MLD and the target AP MLD (reassociation is performed here in an enhanced FT architecture; link reconfiguration is performed here in a roaming AP MLD architecture), which includes context passing between the current AP MLD and the target AP MLD. This is to enable the non-AP MLD to roam to the target AP MLD.

[0187] Where possible, a non-AP MLD may request an extension of the roaming deadline multiple times. Therefore, after step 204, the following may also be included:

[0188] 2041. The non-AP MLD retransmits the first frame, which includes first information requesting an extension of the roaming deadline. Correspondingly, the target AP MLD receives the first frame.

[0189] 2051. The target AP MLD retransmits a second frame, which includes second information indicating that the roaming deadline has been extended. Correspondingly, the non-AP MLD receives the second frame (steps 2041 and 2051 are not shown in the figures).

[0190] The first frame retransmitted by the non-AP MLD may include an extension duration (either an extension based on the initial roaming deadline or an extension based on the extended roaming deadline), or it may include the updated roaming deadline. The target AP MLD updates the roaming deadline again based on the first information in the retransmitted first frame, and notifies the non-AP MLD that the roaming deadline update is complete via a second frame. That is, steps 204 and 205 above can be repeated. It only requires that the first frame be sent within the current roaming deadline.

[0191] As can be seen, in this embodiment, the method of extending the roaming deadline is combined with the scenario of seamless roaming, enabling the non-AP MLD to obtain the extended roaming deadline before initiating a roaming request, so as to make the roaming request based on the extended roaming deadline. This ensures the timeliness of extending the roaming deadline and increases the probability of successfully achieving roaming.

[0192] Example 3: This application combines the method of early termination of roaming deadline with a seamless roaming architecture. Please refer to the following for details. Figure 5 , Figure 5 A flowchart illustrating a method for early termination of roaming deadline provided in this application embodiment:

[0193] 301. The non-AP MLD sends a roaming preparation request frame. Correspondingly, the target AP MLD receives the roaming preparation request frame.

[0194] 302. The target AP MLD sends a roaming preparation response frame. Correspondingly, the non-AP MLD receives the roaming preparation response frame.

[0195] The target AP MLD and non-AP MLD can be transmitted over the air or via DS, and there is no limitation here.

[0196] For a description of steps 301 and 302, please refer to the description of steps 201 and 202 above.

[0197] 303. The non-AP MLD sends the first frame, which includes first information used to request early termination of the roaming deadline. Correspondingly, the target AP MLD receives the first frame.

[0198] For various possible reasons, the non-AP MLD discovers that it does not need to perform roaming at this time. Therefore, the non-AP MLD sends a first frame to the target AP MLD to request an early termination of the roaming deadline.

[0199] As described in Embodiment 1 above, the non-AP MLD can send the first frame to the target AP MLD via either air interface transmission or DS transmission. Either method can be selected, or the two communication methods can be changed depending on the communication quality. Further details will not be provided here.

[0200] 304. The target AP MLD terminates the roaming deadline ahead of schedule based on the first information.

[0201] After the target AP MLD receives the first frame, it terminates the roaming deadline early based on the first information in the frame, and ends the roaming process directly.

[0202] After receiving the first frame, the target AP MLD agrees to terminate the roaming deadline early according to the first information. Optionally, after sending the first frame, the non-AP MLD assumes that the target AP MLD has terminated the roaming deadline early according to the first information and will not initiate a roaming request again. The target AP MLD may also choose not to send a second frame to notify the non-AP MLD that the roaming deadline has been terminated early. This reduces communication resource consumption.

[0203] The following steps are optional:

[0204] 305. The target AP MLD sends a second frame, which includes second information indicating that the roaming deadline has been terminated ahead of schedule. Correspondingly, the non-AP MLD receives the second frame.

[0205] After the target AP MLD receives the first frame and terminates the roaming deadline early according to the first information, it can also send a second frame to the non-AP MLD to indicate that the roaming deadline has been terminated early. This allows the non-AP MLD to confirm that the roaming deadline has been terminated early and prevents it from initiating any more roaming request frames or other first frames to request early termination of the roaming deadline. This improves communication reliability.

[0206] As can be seen, in this embodiment, the method of early termination of the roaming deadline is combined with the scenario of seamless roaming, enabling the non-AP MLD to determine that the roaming deadline has been terminated in advance before initiating a roaming request, thus avoiding the need to initiate a roaming request. This ensures the timeliness of early termination of the roaming deadline and avoids roaming failures that may be caused by unnecessary early termination of the roaming deadline. Overall, the reliability of the roaming process is improved.

[0207] Example 4: In some cases, roaming can be terminated early even after a non-AP MLD sends a roaming request frame. See also... Figure 6 The above is a flowchart of a method for early termination of roaming provided in an embodiment of this application. Figure 6 As shown, the method specifically includes the following steps:

[0208] 401. The non-AP MLD sends a roaming preparation request frame. Correspondingly, the target AP MLD receives the roaming preparation request frame.

[0209] 402. The target AP MLD sends a roaming preparation response frame. Correspondingly, the non-AP MLD receives the roaming preparation response frame.

[0210] The target AP MLD and non-AP MLD can be transmitted over the air or via DS, and there is no limitation here.

[0211] For a description of steps 401 and 402, please refer to the description of steps 201 and 202 above.

[0212] 403. The non-AP MLD sends a roaming request frame to the target AP MLD, and the target AP MLD receives the roaming request frame accordingly.

[0213] The roaming process of a non-AP MLD begins when it sends a roaming request frame to the target AP MLD. After receiving the roaming request frame, the target AP MLD can perform a reassociation process or a link reconfiguration process between the non-AP MLD and the target AP MLD, including context passing between the current AP MLD and the target AP MLD, etc., to enable the non-AP MLD to roam to the target AP MLD.

[0214] 404. The non-AP MLD sends a third frame to the target AP MLD. This third frame includes third information, which is used to request early termination of roaming. Correspondingly, the target AP MLD receives the third frame.

[0215] 405. The target AP MLD terminates roaming early based on third-party information.

[0216] In certain situations, such as poor signal quality from the target AP MLD or a non-AP MLD having more important processes to handle, the non-AP MLD can send a third frame to the target AP MLD to request early termination of roaming, even if roaming has already begun. Upon receiving the third frame, the target AP MLD will directly terminate the non-AP MLD's roaming process based on the third information.

[0217] Optionally, the third frame corresponds to the fifth frame type, where the fifth frame type indicates that the third frame is a roaming process termination frame. The target AP MLD can determine that it needs to terminate the roaming process of the non-AP MLD upon reading the fifth frame type. Alternatively, the third frame may include specific bit values, which the target AP MLD can use to determine the termination of the non-AP MLD's roaming process. Or, the third frame may include text request information, which the target AP MLD can use to determine the termination of the non-AP MLD's roaming process.

[0218] Optionally, the method further includes step 406: the target AP MLD sends a fourth frame, which includes fourth information indicating that roaming has been terminated early. Correspondingly, the non-AP MLD receives the fourth frame.

[0219] After the target AP MLD receives the third frame and terminates roaming early according to the third information, it can also send a fourth frame to the non-AP MLD to indicate that roaming has been terminated early. This allows the non-AP MLD to confirm that roaming has been terminated early and avoid waiting for a roaming response frame, thus reducing the resource overhead of the non-AP MLD.

[0220] As can be seen, in this embodiment of the application, a method for early termination of roaming is proposed in the scenario of seamless roaming. This allows the non-AP MLD to determine that roaming has been terminated in advance after initiating a roaming request and before receiving a roaming response, without waiting for the roaming response. This improves the flexibility of the roaming process and reduces the ineffective resource overhead of MLDs (non-AP MLD and AP MLD).

[0221] Example 5: Examples 2 to 4 described above illustrate methods for updating roaming deadlines or terminating roaming early under a seamless roaming architecture. In the above process, the first or third information sent can be carried in a timeout interval element (TIE). A detailed description follows.

[0222] The FT uses TIE to carry reassociation deadline information. See also... Figure 7a , Figure 7a A schematic diagram of a TIE format provided in this application embodiment is shown below. Figure 7aAs shown, when the Timeout Interval Type is 1, the Timeout Interval Value represents the reassociation deadline interval, indicating the reassociation deadline. Additionally, when the Timeout Interval Type value is 0 or between 6 and 255, it is a reserved bit, and the meaning of its corresponding Timeout Interval Value is undefined. In a robust security network (RSN), the TIE carrying the reassociation deadline is transmitted from the current AP MLD to the non-AP MLD during the initial mobility domain association process (note that since the current AP MLD and the target AP MLD are in the same mobility domain, their reassociation deadlines are consistent). In a non-robust security network, the TIE carrying the reassociation deadline is transmitted from the target AP MLD to the non-AP MLD in the FT resource request protocol.

[0223] In this embodiment of the application, a non-AP MLD can carry a TIE in the first frame to send first information (or third information), and use the TIE to indicate the roaming deadline information.

[0224] Optionally, in the case of seamless roaming, when timeout interval type = 1, the meaning of timeoutinterval value is defined as the roaming deadline for requesting an update. This includes the roaming deadline for requesting an extension or the roaming deadline for requesting early termination.

[0225] Specifically, the existing timeout interval type (timeout interval type=1) is reused here. In the existing FT, the corresponding timeout interval value means the reassociation deadline. Here, we consider expanding the meaning of the corresponding timeout interval value to the (updated) roaming deadline in the case of seamless roaming.

[0226] For example, see [link / reference] Figure 7b , Figure 7b A schematic diagram of a new TIE provided for embodiments of this application, as shown below. Figure 7bAs shown, in the TIE sent by the non-AP MLD, the timeout interval type = 1, and the value indicated by the timeout interval value is a1, where a1 > T0 and T0 is the initial roaming deadline. Then the non-AP MLD requests the target AP MLD to update the roaming deadline of the non-AP MLD to the extended roaming deadline a1.

[0227] Alternatively, in the TIE sent by the non-AP MLD, the timeout interval type = 1, and the value indicated by the timeout interval value is a2, where a2 < T0 and T0 is the initial roaming deadline. Then the non-AP MLD requests the target AP MLD to prematurely terminate the roaming deadline of the non-AP MLD and directly end the roaming process.

[0228] Optionally, in the case of seamless roaming, when the timeout interval type = P (P is a value from 6 to 255), the meaning of the timeout interval value is defined as the requested updated roaming deadline, including the requested extended roaming deadline or the requested prematurely terminated roaming deadline.

[0229] For example, reference can be made to Figure 7c , Figure 7c which is a schematic diagram of another new TIE provided by the embodiment of this application. As shown in Figure 7c in the TIE sent by the non-AP MLD, the timeout interval type = 7, and the value indicated by the timeout interval value is a1, where a1 > T0 and T0 is the initial roaming deadline. Then the non-AP MLD requests the target AP MLD to update the roaming deadline of the non-AP MLD to the extended roaming deadline a1.

[0230] Alternatively, in the TIE sent by the non-AP MLD, the timeout interval type = 7, and the value indicated by the timeout interval value is a2, where a2 < T0 and T0 is the initial roaming deadline. Then the non-AP MLD requests the target AP MLD to prematurely terminate the roaming deadline of the non-AP MLD and directly end the roaming process.

[0231] Note that a timeout interval value of 0 means there is no deadline. Therefore, when updating the roaming deadline using TIE, the timeout interval value cannot be 0. Also, if there are restrictions on updating the roaming deadline, the timeout interval value must meet those restrictions.

[0232] As can be seen, in the embodiments of this application, the first information (or the third information for early termination of roaming) is represented by an existing TIE in the first frame, which allows the transmission of the first information to be reused by existing element structures, reducing the design complexity and reading complexity of the frame content, and improving the transmission and reading efficiency of the first information.

[0233] Example 6: Examples 2 through 5 described above illustrate a method for combining updated roaming deadlines with a seamless roaming architecture. In other cases, based on the FT resource request protocol, an enhanced FT roaming architecture combined with updated roaming deadlines may be considered.

[0234] See also Figure 8 , Figure 8 A flowchart illustrating a method for updating roaming expiration time provided in this application embodiment is shown below. Figure 8 As shown, the method includes the following steps:

[0235] 501. The non-AP MLD sends an authentication request frame to the target AP MLD. Correspondingly, the target AP MLD receives the authentication request frame.

[0236] 502. The target AP MLD sends an authentication response frame to the non-AP MLD. Correspondingly, the non-AP MLD receives the authentication response frame.

[0237] In this embodiment, the non-AP MLD and the target AP MLD communicate via air interface. That is, they communicate directly with each other.

[0238] 503. The non-AP MLD sends an authentication confirm request frame to the target AP MLD, and the target AP MLD receives the authentication confirm request frame accordingly. This authentication confirm request frame includes first information.

[0239] The non-AP MLD sends an authentication confirmation request frame, which includes information related to the resource request. Additionally, the authentication confirmation request frame also includes first information for requesting an update to the roaming deadline, including a request to extend the roaming deadline or a request to terminate the roaming deadline early. That is, in this embodiment, the first frame is an authentication confirmation request frame.

[0240] Optionally, the method further includes:

[0241] 504. The target AP MLD sends an authentication ACK frame to the non-AP MLD, and the non-AP MLD receives the authentication ACK frame accordingly. This authentication ACK frame includes second information.

[0242] After receiving the authentication confirmation frame, the non-AP MLD can use the updated roaming deadline and send a roaming request before this roaming deadline to realize the non-AP MLD roaming from the current AP MLD to the target AP MLD.

[0243] The target AP MLD sends an authentication confirmation frame to confirm that the resource request from the non-AP MLD has been accepted. Additionally, the authentication confirmation frame includes second information indicating that the roaming deadline has been updated, including whether the roaming deadline has been extended or terminated earlier. That is, in this embodiment, the second frame is an authentication confirmation frame.

[0244] Or you may refer to Figure 9 , Figure 9 A flowchart illustrating another method for updating the roaming deadline provided in this application embodiment is shown below. Figure 9 As shown, the method includes the following steps:

[0245] 601. A non-AP MLD (via the current AP MLD) sends an FT request frame to the target AP MLD. Correspondingly, the target AP MLD receives the FT request frame.

[0246] 602. The target AP MLD (via the current AP MLD) sends an FT response frame to the non-AP MLD. Correspondingly, the non-AP MLD receives the FT response frame.

[0247] In this embodiment, the communication between the non-AP MLD and the target AP MLD is via DS transmission. That is, the two communicate through the current AP MLD.

[0248] 603. A non-AP MLD (via the current AP MLD) sends an FT confirm request frame to the target AP MLD, and the target AP MLD receives the FT confirm request frame accordingly. The FT confirm request frame includes first information.

[0249] The non-AP MLD sends an FT confirmation request frame, which includes information related to the resource request. Additionally, the FT confirmation request frame also includes first information for requesting an update to the roaming deadline, including a request to extend the roaming deadline or a request to terminate the roaming deadline early. That is, in this embodiment, the first frame is an FT confirmation request frame.

[0250] Optionally, the method further includes:

[0251] 604. The target AP MLD (via the current AP MLD) sends an FT acknowledgment (FTACK) frame to the non-AP MLD, and the non-AP MLD receives the FT acknowledgment frame accordingly. This FT acknowledgment frame includes second information.

[0252] After receiving the FT confirmation frame, the non-AP MLD can use the updated roaming deadline and send a roaming request before this roaming deadline to realize the roaming of the non-AP MLD from the current AP MLD to the target AP MLD.

[0253] The target AP MLD sends an FT confirmation frame to confirm that the resource request from the non-AP MLD has been accepted. Additionally, the FT confirmation frame includes second information indicating that the roaming deadline has been updated, including whether the roaming deadline has been extended or terminated earlier. That is, in this embodiment, the second frame is an FT confirmation frame.

[0254] Example 6 can also be combined with Example 5, that is, the TIE is carried in the authentication confirmation request frame or the FT confirmation request frame and sent as the first information, so as to request an update to the roaming expiration time (or request early termination of roaming).

[0255] As can be seen, in the embodiments of this application, in the scenario where a non-AP MLD requests resources from a target AP MLD during roaming, a method for updating the roaming deadline is proposed. This allows the non-AP MLD to update the roaming deadline at the same time as initiating the resource request, ensuring that the update of the roaming deadline occurs before the start of roaming preparation. This guarantees that the non-AP MLD can complete the roaming process according to the pre-determined roaming deadline, further reducing the impact of the roaming deadline update on the roaming process and improving the reliability of the roaming process.

[0256] The foregoing details the method provided in this application. To facilitate the implementation of the above-described solutions in the embodiments of this application, corresponding apparatus or devices are also provided in the embodiments of this application.

[0257] This application divides the target AP MLD and non-AP MLD into functional modules according to the above method embodiments. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application is illustrative and only represents one logical functional division; other division methods may be used in actual implementation. The following will combine... Figures 10 to 12 The target APMLD and non-AP MLD of the embodiments of this application are described in detail.

[0258] See Figure 10 , Figure 10 This is a schematic diagram of the communication device provided in an embodiment of this application, as shown below. Figure 10 As shown, the communication device includes a transceiver unit 10 and a processing unit 20. The transceiver unit 10 can implement corresponding communication functions, and the processing unit 20 is used for data processing. The transceiver unit 10 can also be called a communication interface or a communication unit, etc.

[0259] In some embodiments of this application, the communication device may be the target AP MLD shown above. Figure 10 The communication device shown can be used to perform the steps or functions executed by the target AP MLD in the above method embodiments. For example, the communication device can be the target AP MLD or a chip or functional module configured in the target AP MLD, etc., and this application embodiment does not limit this. The transceiver unit 10 is used to perform transceiver-related operations of the target AP MLD in the above method embodiments, and the processing unit 20 is used to perform processing-related operations of the target AP MLD in the above method embodiments.

[0260] For example, the transceiver unit 10 is used to receive a first frame, the first frame including first information, the first information being used to request an update of the roaming deadline of the non-AP MLD; the processing unit 20 is used to update the roaming deadline of the non-AP MLD.

[0261] It is understood that the specific descriptions of the transceiver unit and processing unit shown in the embodiments of this application are merely examples. For the specific functions or execution steps of the transceiver unit and processing unit, please refer to any one of the above method embodiments one to six, which will not be described in detail here.

[0262] For example, the transceiver unit 10 is also configured to send a second frame, which includes second information indicating that the roaming deadline for the non-AP MLD has been updated.

[0263] Optionally, the first information is used to request an update to the roaming deadline of the non-AP MLD, including: the first information is used to request an extension of the roaming deadline of the non-AP MLD.

[0264] Optionally, the first information includes a first roaming deadline, the duration of which is greater than the duration of the roaming deadline; or the first information includes an extension duration.

[0265] Optionally, the first information is used to request an update to the roaming deadline of the non-AP MLD, including: the first information is used to request an early termination of the roaming deadline of the non-AP MLD.

[0266] Optionally, the first information may include a second roaming expiration time, the duration of which is shorter than the duration of the roaming expiration time; or it may include a request for roaming expiration.

[0267] Optionally, the first information is carried in the timeout interval element TIE.

[0268] Optionally, before generating the first frame, the method further includes: determining that the number of times the first information is sent is less than a preset number; and / or determining that the extended roaming deadline is less than or equal to a preset duration.

[0269] Optionally, the preset number of times and / or preset duration are as agreed upon in the agreement.

[0270] Optionally, the preset number of times and / or preset duration are configured for the target AP MLD.

[0271] Optionally, the preset number of times and / or preset duration are carried in the beacon frames and / or roaming probe response frames sent by the target AP MLD.

[0272] Optionally, the preset duration is determined based on the validity period of the paired temporary keys of the non-AP MLD and the target AP MLD.

[0273] Optionally, before sending the first frame, the method further includes receiving a roaming preparation response frame, which indicates that roaming preparation for the non-AP MLD has been completed.

[0274] Optionally, the first frame may also include third information, which is used to request the communication resources of the target AP MLD.

[0275] Optionally, the second frame may also include fourth information, which is used to confirm the communication resources of the target AP MLD that accepts the request from the first request information.

[0276] Optionally, if the first information is used to indicate an extension of the roaming deadline for a non-AP MLD, the first frame corresponds to the third frame type; if the first information is used to indicate an early termination of the roaming deadline for a non-AP MLD, the first frame corresponds to the fourth frame type.

[0277] Reuse Figure 10 In some other embodiments of this application, the communication device may be the non-APMLD shown above. That is... Figure 10 The communication device shown can be used to perform the steps or functions executed by the non-AP MLD in the above method embodiments. For example, the communication device can be a non-AP MLD or a chip or functional module configured in the non-AP MLD, etc., and this application embodiment does not limit this. The transceiver unit 10 is used to perform transceiver-related operations of the non-AP MLD in the above method embodiments, and the processing unit 20 is used to perform non-AP MLD processing-related operations in the above method embodiments.

[0278] For example, processing unit 20 is used to generate a first frame, the first frame including first information, the first information being used to request an update of the roaming deadline of the non-access point multilink device (non-AP MLD); transceiver unit 10 is used to send the first frame.

[0279] For example, the transceiver unit 10 is also configured to receive a second frame, which includes second information indicating that the roaming deadline for the non-AP MLD has been updated.

[0280] For an explanation of the first or second information, please refer to the optional methods in the execution of the aforementioned AP MLD device. Alternatively, please refer to the relevant descriptions of Embodiments 1 to 6, which will not be repeated here.

[0281] The above describes the non-AP MLD and AP MLD of embodiments of this application. The following describes the possible product forms of the non-AP MLD and AP MLD. It should be understood that any product possessing the above-described features... Figure 10 Any product of any form that possesses the aforementioned non-AP MLD functionality, or any product that has the above-mentioned features. Figure 10 Any form of product that incorporates the functions of the described AP MLD falls within the protection scope of the embodiments of this application. It should also be understood that the following description is merely illustrative and does not limit the product forms of non-AP MLDs and AP MLDs in the embodiments of this application to these examples.

[0282] In one possible implementation, Figure 10 In the communication device shown, the processing unit 20 can be one or more processors, and the transceiver unit 10 can be a transceiver, or the transceiver unit 10 can also be a transmitting unit and a receiving unit. The transmitting unit can be a transmitter, and the receiving unit can be a receiver. The transmitting unit and the receiving unit are integrated into one device, such as a transceiver. In the embodiments of this application, the processor and the transceiver can be coupled, etc., and the connection method between the processor and the transceiver is not limited in the embodiments of this application. In the process of executing the above method, the process of sending information (such as sending a BTM request frame, etc.) in the above method can be understood as the process of the processor outputting the above information. When outputting the above information, the processor outputs the above information to the transceiver so that the transceiver can transmit it. After the above information is output by the processor, it may need to undergo other processing before reaching the transceiver. Similarly, the process of receiving information (such as receiving a BTM request frame, etc.) in the above method can be understood as the process of the processor receiving the input above information. When the processor receives the input information, the transceiver receives the above information and inputs it into the processor. Furthermore, after the transceiver receives the aforementioned information, the information may need to undergo further processing before being input into the processor.

[0283] See Figure 11 , Figure 11 This is another schematic diagram of the communication device provided in the embodiments of this application. The communication device can be an AP MLD or a non-AP MLD, or a chip therein. Figure 11 Only the main components of the communication device are shown. In addition to the processor 1001 and transceiver 1002, the communication device may further include a memory 1003 and input / output devices (not shown).

[0284] The processor 1001 is mainly used to process communication protocols and communication data, control the entire communication device, execute software programs, and process the data of the software programs. The memory 1003 is mainly used to store software programs and data. The transceiver 1002 may include control circuitry and an antenna. The control circuitry is mainly used for converting baseband signals to radio frequency signals and processing radio frequency signals. The antenna is mainly used for transmitting and receiving radio frequency signals in the form of electromagnetic waves. Input / output devices, such as touchscreens, displays, and keyboards, are mainly used to receive user input data and output data to the user.

[0285] When the communication device is powered on, the processor 1001 can read the software program in the memory 1003, interpret and execute the instructions of the software program, and process the data of the software program. When data needs to be transmitted wirelessly, the processor 1001 performs baseband processing on the data to be transmitted and outputs the baseband signal to the radio frequency (RF) circuit. The RF circuit processes the baseband signal and transmits the RF signal outward in the form of electromagnetic waves through the antenna. When data is sent to the communication device, the RF circuit receives the RF signal through the antenna, converts the RF signal into a baseband signal, and outputs the baseband signal to the processor 1001. The processor 1001 converts the baseband signal into data and processes the data.

[0286] In another implementation, the radio frequency circuitry and antenna can be set up independently of the processor performing baseband processing. For example, in a distributed scenario, the radio frequency circuitry and antenna can be arranged remotely, independent of the communication device.

[0287] The processor 1001, transceiver 1002, and memory 1003 can be connected via a communication bus.

[0288] For example, the communication device can be used to perform the functions of the target AP MLD in the aforementioned embodiments one to six.

[0289] For example, the communication device can be used to perform the functions of the non-AP MLD in the aforementioned embodiments one to six.

[0290] In one implementation, the processor 1001 may store instructions, which may be a computer program. The computer program runs on the processor 1001 and causes the communication device to execute the methods described in the above method embodiments. The computer program may be embedded in the processor 1001; in this case, the processor 1001 may be implemented in hardware.

[0291] In one implementation, the communication device may include a circuit that can perform the functions of sending, receiving, or communicating in the aforementioned method embodiments. The processor and transceiver described in this application can be implemented on integrated circuits (ICs), analog ICs, radio frequency integrated circuits (RFICs), mixed-signal ICs, application-specific integrated circuits (ASICs), printed circuit boards (PCBs), electronic devices, etc. The processor and transceiver can also be manufactured using various IC process technologies, such as complementary metal-oxide semiconductors (CMOS), n-metal-oxide-semiconductor (NMOS), p-type metal-oxide semiconductors (PMOS), bipolar junction transistors (BJTs), bipolar CMOS (BiCMOS), silicon-germanium (SiGe), gallium arsenide (GaAs), etc.

[0292] It is understood that the communication device shown in the embodiments of this application may also have more than Figure 11 This application does not limit the use of other components or other related elements. The methods performed by the processor and transceiver shown above are merely examples; for the specific steps performed by the processor and transceiver, please refer to the description of the method embodiments above.

[0293] In another possible implementation Figure 10 In the communication device shown, the processing unit 20 can be one or more logic circuits, and the transceiver unit 10 can be an input / output interface, or a communication interface, or an interface circuit, or an interface, etc. Alternatively, the transceiver unit 10 can also be a transmitting unit and a receiving unit. The transmitting unit can be an output interface, and the receiving unit can be an input interface. The transmitting unit and the receiving unit are integrated into one unit, such as an input / output interface. See also Figure 12 , Figure 12 This is yet another structural schematic diagram of the communication device provided in the embodiments of this application. For example... Figure 12 As shown, Figure 12The communication device shown includes logic circuitry 901 and interface 902. That is, the processing unit 20 can be implemented using logic circuitry 901, and the transceiver unit 10 can be implemented using interface 902. The logic circuitry 901 can be a chip, processing circuit, integrated circuit, or system-on-chip (SoC) chip, etc., and the interface 902 can be a communication interface, input / output interface, pins, etc. For example, Figure 12 The above-mentioned communication device is used as an example of a chip, which includes a logic circuit 901 and an interface 902.

[0294] In this embodiment, the logic circuit and the interface can also be coupled to each other. The specific connection method between the logic circuit and the interface is not limited in this embodiment.

[0295] In some embodiments of this application, the communication device can be used to perform the methods, steps, or functions executed by the target AP MLD in any of the above method embodiments.

[0296] For example, logic circuit 901 is used to generate a second frame; interface 902 is used to output the second frame.

[0297] In other embodiments of this application, the communication device can be used to perform methods, steps, or functions performed by non-AP MLD in any of the above method embodiments.

[0298] For example, logic circuit 901 is used to generate a first frame, and interface 902 is used to output the first frame.

[0299] It is understood that specific details regarding the first frame and the second frame can be found in the method implementation examples shown above, and will not be elaborated upon here.

[0300] It is understood that the communication device shown in the embodiments of this application can implement the method provided in the embodiments of this application in hardware form or in software form, etc., and the embodiments of this application do not limit it in this way.

[0301] for Figure 12 For specific implementations of the various embodiments shown, please refer to the above embodiments, which will not be described in detail here.

[0302] This application also provides a wireless communication system, which includes a non-AP MLD, a current AP MLD, and a target AP MLD. The non-AP MLD and the target AP MLD can be used to perform the methods in any of the foregoing embodiments.

[0303] In addition, this application also provides a computer program for implementing the operations and / or processes performed by the non-AP MLD in the method provided in this application.

[0304] This application also provides a computer program for implementing the operations and / or processes performed by the target AP MLD in the method provided in this application.

[0305] This application also provides a computer-readable storage medium storing computer code that, when executed on a computer, causes the computer to perform operations and / or processes performed by non-APMLD in the method provided in this application.

[0306] This application also provides a computer-readable storage medium storing computer code that, when executed on a computer, causes the computer to perform the operations and / or processes performed by the target APMLD in the method provided in this application.

[0307] This application also provides a computer program product comprising computer code or a computer program that, when run on a computer, causes the operations and / or processes performed by a non-AP MLD device in the method provided in this application to be executed.

[0308] This application also provides a computer program product comprising computer code or a computer program that, when run on a computer, causes the operations and / or processes performed by the target AP MLD in the method provided in this application to be executed.

[0309] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interfaces, devices, or units, or it may be an electrical, mechanical, or other form of connection.

[0310] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected according to actual needs to achieve the technical effects of the solutions provided in the embodiments of this application.

[0311] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0312] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned readable storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0313] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for updating roaming expiration time, characterized in that, The method includes: Generate a first frame, which includes first information, which is used to request an update of the roaming deadline of the non-access point multilink device (non-AP MLD). Send the first frame.

2. The method according to claim 1, characterized in that, The method further includes: Receive a second frame, which includes second information indicating that the roaming deadline update for the non-APMLD has been completed.

3. A method for updating roaming expiration time, characterized in that, The method includes: Receive a first frame, the first frame including first information, the first information being used to request an update of the roaming deadline of the non-access point multilink device (non-AP MLD); Update the roaming deadline for the aforementioned non-AP MLD.

4. The method according to claim 3, characterized in that, The method further includes: A second frame is sent, which includes second information indicating that the update of the roaming deadline for the non-APMLD has been completed.

5. The method according to any one of claims 1-4, characterized in that, The first information is used to request an update to the roaming deadline for the non-AP MLD, including: The first information is used to request an extension of the roaming deadline for the non-AP MLD.

6. The method according to claim 5, characterized in that, The first information includes a first roaming deadline, the duration of which is greater than the duration of the roaming deadline; or the first information includes an extension duration.

7. The method according to any one of claims 1-4, characterized in that, The first information is used to request an update to the roaming deadline for the non-AP MLD, including: The first information is used to request the early termination of the roaming deadline of the non-AP MLD.

8. The method according to claim 7, characterized in that, The first information includes a second roaming expiration time, the duration of which is less than the duration of the roaming expiration time; or it includes a request for roaming expiration.

9. In the method according to any one of claims 1-8, the first information is carried in the timeout interval element TIE.

10. The method according to any one of claims 1-9, characterized in that, Before generating the first frame, the method further includes: Determine that the number of times the first information is sent is less than a preset number; and / or The extended roaming deadline is determined to be less than or equal to the preset duration.

11. The method according to claim 10, characterized in that, The preset number of times and / or the preset duration are as agreed upon in the protocol.

12. The method according to claim 10, characterized in that, The preset number of times and / or the preset duration are configured for the target AP MLD.

13. The method according to claim 12, characterized in that, The preset number of times and / or the preset duration are carried in the beacon frames and / or roaming probe response frames sent by the target AP MLD.

14. The method according to any one of claims 10-13, characterized in that, The preset duration is determined based on the validity period of the paired temporary key between the non-AP MLD and the target AP MLD.

15. The method according to any one of claims 1-2 or 5-14, characterized in that, Before sending the first frame, the method further includes: Receive a roaming preparation response frame, which indicates that roaming preparation for the non-AP MLD has been completed.

16. The method according to any one of claims 1-14, characterized in that, The first frame also includes third information, which is used to request the communication resources of the target AP MLD.

17. The method according to claim 16, characterized in that, The second frame also includes fourth information, which is used to confirm the communication resources of the target AP MLD that accepted the request from the first request information.

18. The method according to any one of claims 5-17, characterized in that, The first information is used to indicate that, in the case of extending the roaming deadline of the non-AP MLD, the first frame corresponds to the third frame type; The first information is used to indicate the roaming deadline of the non-AP MLD to be terminated in advance, and the first frame corresponds to the fourth frame type.

19. A communication device, characterized in that, Includes units or modules for performing the method as described in any one of claims 1 to 18.

20. A communication device, characterized in that, Including processor and memory; The memory is used to store instructions; The processor is configured to execute the instructions to cause the method of any one of claims 1 to 18 to be performed.

21. A communication device, characterized in that, It includes logic circuitry and an interface, the logic circuitry and the interface being coupled; the interface is used to input and / or output code instructions, and the logic circuitry is used to execute the code instructions to cause the method of any one of claims 1 to 18 to be performed.

22. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program, which, when executed, performs the method as described in any one of claims 1 to 18.

23. A communication system, characterized in that, The communication system includes a current AP MLD, a target AP MLD, and a non-AP MLD, wherein the target AP MLD is used to perform the method as described in any one of claims 3-18, and the non-AP MLD is used to perform the method as described in any one of claims 1-2 or 5-18.

Images