Handover method, and apparatus, device, medium and program product

Abstract

The present application belongs to the field of Wi-Fi. Disclosed are a handover method, and an apparatus, a device, a medium and a program product. The method is executed by a non-AP MLD, and comprises: sending and / or receiving at least one first frame, which is used for implementing a handover between two AP MLDs at different positions on the basis of link reconfiguration. In the method, by means of sending and / or receiving at least one first frame, which is used for implementing a handover between two AP MLDs at different positions on the basis of link reconfiguration, a link reconfiguration protocol between the two AP MLDs at different positions is optimized, and the handover of the non-AP MLD between the two AP MLDs during a communication process is implemented.

Description

Switching method, device, equipment, medium and program product Technical Field

[0001] The present application relates to the field of Wireless Fidelity (Wi-Fi), and in particular to a switching method, apparatus, device, medium, and program product. Background Art

[0002] When a non-access point device moves between different access point devices, it may switch from a current access point (AP) to a target AP.

[0003] Related technologies include Fast Basic Service Set (BSS) Transition (FT). Fast BSS Transition can reduce the duration of connectivity loss between a station (STA) and a distributed system (DS), or between a non-AP Multi-Link Device (non-AP MLD) and a DS, during a BSS switch. However, since the STA (or non-AP MLD) needs to reassociate with the target AP or target AP MLD after switching, and re-establish the data transmission and reception protocols and scenarios, data continuity between the STA and the DS, or between the non-AP MLD and the DS, cannot be maintained.

[0004] Summary of the Invention

[0005] The present application provides a switching method, apparatus, device, medium, and program product, the technical solution of which at least includes:

[0006] According to one aspect of an embodiment of the present application, a handover method is provided. The method is performed by a non-AP MLD, and the method includes:

[0007] At least one first frame is sent and / or received, where the at least one first frame is used to implement switching between two AP MLDs at different locations based on link reconfiguration.

[0008] According to another aspect of an embodiment of the present application, a handover method is provided. The method is performed by a current AP MLD, and the method includes:

[0009] At least one first frame is sent and / or received, where the at least one first frame is used to implement switching between a non-AP MLD and a current AP MLD at a different location and a target AP MLD based on link reconfiguration.

[0010] According to another aspect of an embodiment of the present application, a handover method is provided. The method is performed by a target AP MLD, and the method includes:

[0011] At least one first frame is sent and / or received, where the at least one first frame is used to implement switching between a non-AP MLD and a current AP MLD at a different location and a target AP MLD based on link reconfiguration.

[0012] According to another aspect of an embodiment of the present application, a non-access point multi-link device is provided, the device including:

[0013] The transmission module is configured to send and / or receive at least one first frame, where the at least one first frame is used to implement switching between two access point multi-link devices at different locations based on link reconfiguration.

[0014] According to another aspect of an embodiment of the present application, a current access point multi-link device is provided, the device including:

[0015] The transmission module is configured to send and / or receive at least one first frame, wherein the at least one first frame is used to implement switching between a non-access point multi-link device and a current access point multi-link device and a target access point multi-link device at different locations based on link reconfiguration.

[0016] According to another aspect of an embodiment of the present application, a target access point multi-link device is provided, the device including:

[0017] The transmission module is configured to send and / or receive at least one first frame, wherein the at least one first frame is used to implement switching between a non-access point multi-link device and a current access point multi-link device and a target access point multi-link device at different locations based on link reconfiguration.

[0018] According to another aspect of an embodiment of the present application, a non-access point multi-link device is provided, the non-access point multi-link device including:

[0019] processor;

[0020] a transceiver connected to the processor;

[0021] a memory for storing executable instructions for the processor;

[0022] The processor is configured to load and execute executable instructions to implement the switching methods in various aspects described above.

[0023] According to another aspect of an embodiment of the present application, a current access point multi-link device is provided, the current access point multi-link device including:

[0024] processor;

[0025] a transceiver connected to the processor;

[0026] a memory for storing executable instructions for the processor;

[0027] The processor is configured to load and execute executable instructions to implement the switching methods in various aspects described above.

[0028] According to another aspect of an embodiment of the present application, a target access point multi-link device is provided, the target access point multi-link device including:

[0029] processor;

[0030] a transceiver connected to the processor;

[0031] a memory for storing executable instructions for the processor;

[0032] The processor is configured to load and execute executable instructions to implement the switching methods in various aspects described above.

[0033] According to another aspect of an embodiment of the present application, a computer-readable storage medium is provided, in which at least one program is stored. The at least one program is loaded and executed by a processor to implement the switching method as described in the above aspects.

[0034] According to another aspect of an embodiment of the present application, a computer program product or computer program is provided, which includes computer instructions, the computer instructions are stored in a computer-readable storage medium, a processor obtains the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to implement the switching method as described in the above aspects.

[0035] The technical solutions provided by the embodiments of the present application may have the following beneficial effects:

[0036] The method optimizes the link reconfiguration protocol between the two AP MLDs at different locations by sending and / or receiving at least one first frame, where the at least one first frame is used to implement switching between two AP MLDs at different locations based on link reconfiguration, and implements switching of a non-AP MLD between the two AP MLDs during communication. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0038] FIG1 shows a schematic diagram of a communication system provided by an exemplary embodiment of the present application;

[0039] FIG2 is a schematic diagram showing a method for establishing multiple links provided by the related art;

[0040] FIG3 shows a schematic diagram of a connection between a logical AP MLD and a STA provided by a related art;

[0041] FIG4 shows a flow chart of a switching method provided by an exemplary embodiment of the present application;

[0042] FIG5 shows a flow chart of a switching method provided by an exemplary embodiment of the present application;

[0043] FIG6 is a schematic diagram showing a high-level architecture of a mobility domain MLD and its subordinate AP MLD according to an exemplary embodiment of the present application;

[0044] FIG7 is a schematic diagram showing a format of a reconfiguration status list subfield provided by an exemplary embodiment of the present application;

[0045] FIG8 is a schematic diagram showing a format of a group key data subfield provided by an exemplary embodiment of the present application;

[0046] FIG9 is a schematic diagram showing a mobile domain element format provided by an exemplary embodiment of the present application;

[0047] FIG10 shows a schematic diagram of the FT capability and policy field format provided by an exemplary embodiment of the present application;

[0048] FIG11 is a schematic diagram showing a block confirmation protocol context element format provided by an exemplary embodiment of the present application;

[0049] FIG12 is a schematic diagram showing the format of a block acknowledgment protocol context parameter control field provided by an exemplary embodiment of the present application;

[0050] FIG13 is a schematic diagram showing the format of a block acknowledgment protocol context parameter set list field provided by an exemplary embodiment of the present application;

[0051] FIG14 shows a schematic diagram of the format of a single block confirmation protocol context parameter set field provided by an exemplary embodiment of the present application;

[0052] FIG15 is a schematic diagram showing the format of a single block confirmation protocol context parameter set field provided by an exemplary embodiment of the present application;

[0053] FIG16 shows a schematic diagram of the format of a block confirmation parameter set field provided by an exemplary embodiment of the present application;

[0054] FIG17 is a schematic diagram showing a format of a security association context element provided by an exemplary embodiment of the present application;

[0055] FIG18 shows a schematic diagram of the format of a security association context parameter control field provided by an exemplary embodiment of the present application;

[0056] FIG19 shows a schematic diagram of the format of a security association context parameter set list field provided by an exemplary embodiment of the present application;

[0057] FIG20 shows a schematic diagram of the format of a security association context parameter set field provided by an exemplary embodiment of the present application;

[0058] FIG21 shows a schematic diagram of the format of a security association context parameter set field provided by an exemplary embodiment of the present application;

[0059] FIG22 is a schematic diagram showing a format of a timeout interval element provided by an exemplary embodiment of the present application;

[0060] FIG23 shows a flow chart of a switching method provided by an exemplary embodiment of the present application;

[0061] FIG24 shows a flow chart of a switching method provided by an exemplary embodiment of the present application;

[0062] FIG25 shows a flow chart of a switching method provided by an exemplary embodiment of the present application;

[0063] FIG26 shows a flow chart of a switching method provided by an exemplary embodiment of the present application;

[0064] FIG27 shows a flow chart of a switching method provided by an exemplary embodiment of the present application;

[0065] FIG28 shows a block diagram of a non-access point multi-link device provided by an exemplary embodiment of the present application;

[0066] FIG29 shows a block diagram of a current access point multi-link device provided by an exemplary embodiment of the present application;

[0067] FIG30 shows a block diagram of a target access point multi-link device provided by an exemplary embodiment of the present application;

[0068] FIG31 shows a schematic structural diagram of a non-access point multi-link device, a current access point multi-link device, or a target access point multi-link device provided by an exemplary embodiment of the present application. DETAILED DESCRIPTION

[0069] To make the objectives, technical solutions, and advantages of the present application more clear, the embodiments of the present application will be further described in detail below with reference to the accompanying drawings. Exemplary embodiments will be described in detail herein, with examples shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Instead, they are merely examples of devices and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0070] The terms used in this disclosure are for the purpose of describing specific embodiments only and are not intended to limit the disclosure. As used in this disclosure and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0071] It should be understood that although the terms first, second, third, etc. may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining."

[0072] Figure 1 shows a schematic diagram of a communication system 10 provided in an exemplary embodiment of the present application. Communication system 10 includes terminals, terminals and network devices, or access points (APs) and station-stations (STAs), though this embodiment is not limited to these. This embodiment of the present application uses the example of communication system 10 including a mobility domain MLD 110 (AP) and a non-AP MLD 120 (STA). Mobility domain MLD 110 includes a current AP MLD 111 and a target AP MLD 112.

[0073] In some scenarios, an AP can be referred to as an AP STA, meaning that in a sense, an AP is also a type of STA. In some scenarios, a STA can be referred to as a non-AP STA.

[0074] In some embodiments, STAs may include AP STAs and non-AP STAs.

[0075] Communication in a communication system can be between an AP and a non-AP STA, between a non-AP STA and a non-AP STA, or between a STA and a peer STA. A peer STA refers to a device that communicates with the STA peer. For example, a peer STA may be an AP or a non-AP STA.

[0076] An AP acts as a bridge between wired and wireless networks. Its primary function is to connect wireless network clients together and then connect the wireless network to the Ethernet. An AP can be a terminal device with a Wi-Fi chip (such as a mobile phone) or a network device (such as a router).

[0077] It should be understood that the role of STA in a communication system is not absolute. For example, in some scenarios, when a mobile phone is connected to a router, the mobile phone is a non-AP STA. When the mobile phone serves as a hotspot for other mobile phones, the mobile phone plays the role of AP.

[0078] APs and non-AP STAs can be devices used in the Internet of Vehicles, IoT nodes and sensors in the Internet of Things (IoT), smart cameras, smart remote controls, smart water and electricity meters in smart homes, and sensors in smart cities.

[0079] In some embodiments, non-AP STAs may support, but are not limited to, 802.11be. Non-AP STAs may also support various current and future 802.11 family wireless local area network (WLAN) standards, such as 802.11ax, 802.11ac, 802.11n, 802.11g, 802.11b, and 802.11a.

[0080] In some embodiments, the AP may be a device supporting the 802.11be standard. The AP may also be a device supporting various current and future 802.11 family WLAN standards, such as 802.11ax, 802.11ac, 802.11n, 802.11g, 802.11b, and 802.11a.

[0081] In some embodiments, the STA may be a mobile phone, tablet computer, computer, virtual reality (VR) device, augmented reality (AR) device, wireless device in industrial control, set-top box, wireless device in unmanned driving, vehicle-mounted communication device, wireless device in telemedicine, wireless device in smart grid, wireless device in transportation safety, wireless device in smart city or wireless device in smart home, wireless communication chip, etc. that supports WLAN / Wi-Fi technology.

[0082] WLAN technology can support frequency bands including but not limited to: low frequency bands (2.4GHz, 5GHz, 6GHz) and high frequency bands (60GHz).

[0083] One or more links exist between the station and the access point. In some embodiments, the station and the access point support multi-band communication, for example, communicating simultaneously on the 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz frequency bands, or communicating simultaneously on different channels in the same frequency band (or different frequency bands), thereby improving the communication throughput and / or reliability between devices. Such a device is generally referred to as a multi-band device, or a multi-link device (MLD), and is sometimes also referred to as a multi-link entity or a multi-band entity. A multi-link device can be an access point device or a station device. If the multi-link device is an access point device, the multi-link device includes one or more APs; if the multi-link device is a station device, the multi-link device includes one or more non-AP STAs.

[0084] A multi-link device including one or more APs is referred to as an AP, and a multi-link device including one or more non-AP STAs is referred to as a non-AP. In some embodiments, a non-AP may be referred to as a STA.

[0085] In some embodiments, an AP may include multiple APs, and a non-AP may include multiple STAs. Multiple links may be formed between multiple APs in the AP and multiple STAs in the non-AP. Data communication may be performed between the APs in the AP and the corresponding STAs in the non-AP via the corresponding links. As shown in Figure 1, non-AP MLD 120 communicates data with current AP MLD 111 via multiple links, and with target AP MLD 112 via multiple links. After moving, non-AP MLD 120 disconnects the link with current AP MLD 111 and switches to data communication only with target AP MLD 112 via the multiple links.

[0086] An AP is a device deployed in a wireless local area network to provide wireless communication capabilities for STAs. STAs may include: User Equipment (UE), Access Terminal, Subscriber Unit, Subscriber Station, Mobile Station, Mobile Station, Remote Station, Remote Terminal, Mobile Device, Wireless Communication Device, User Agent, or User Equipment. Alternatively, a STA may be a cellular phone, cordless phone, Session Initiation Protocol (SIP) phone, Wireless Local Loop (WLL) station, Personal Digital Assistant (PDA), handheld device with wireless communication capabilities, computing device or other processing device connected to a wireless modem, vehicle-mounted device, or wearable device, but this is not limited in the present embodiment.

[0087] In some embodiments, both the STA and the AP support the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard, but are not limited to the IEEE 802.11 standard.

[0088] Establish multiple links;

[0089] FIG2 is a schematic diagram of a method for establishing a multi-link provided by related art, which is performed by an AP MLD 210 and a non-AP MLD 220 . The AP MLD 210 includes: an AP1 supporting 2.4 GHz, an AP2 supporting 5 GHz, and an AP3 supporting 6 GHz; the non-AP MLD 220 includes: an STA1 supporting 2.4 GHz, an STA2 supporting 5 GHz, and an STA3 supporting 6 GHz.

[0090] The relevant standards define Multi-Link Operation (MLO) and AP MLD210 and non-AP MLD220 devices with MLO capabilities. Multiple links can be established between the AP MLD210 and non-AP MLD220 on multiple different frequency bands / channels.

[0091] As shown in Figure 2, three links, called Link 1, Link 2, and Link 3, are established between AP MLD 210 and non-AP MLD 220 at 2.4 GHz, 5 GHz, and 6 GHz. These links can operate simultaneously. AP 1 operating on Link 1 (2.4 GHz), AP 2 operating on Link 2 (5 GHz), and AP 3 operating on Link 3 (6 GHz) are called affiliated APs of AP MLD 210.

[0092] Similarly, STA1 working on link 1 (2.4 GHz), STA2 working on link 2 (5 GHz), and non-AP STA 3 working on link 3 (6 GHz) are respectively called affiliated non-AP STAs of the non-AP MLD.

[0093] Logical AP MLD;

[0094] Figure 3 shows a schematic diagram of the connection between a logical AP MLD and a STA, as provided by related technologies. Multiple non-collocated APs are considered a single logical AP MLD 310. When a STA connects to this logical AP MLD 310, these non-collocated APs can be considered different subordinate APs of the logical AP MLD 310. This allows the logical AP MLD 310 to use different subordinate APs and different links to provide services to the STA, thereby enabling uninterrupted roaming for the STA. The logical AP MLD is also called a mobility domain MLD.

[0095] As shown in Figure 3, STA1 uses multiple links to connect to AP 1 and AP 2 respectively. When STA1 moves, the link connection with AP 1 is disconnected but the link connection with AP 2 is not affected. Therefore, the mobility support of STA1 is improved. STA1 can be one STA or multiple STAs, which is not limited in this embodiment of the present application.

[0096] Multi-link reconfiguration;

[0097] If a non-AP MLD has established multiple links with an AP MLD and the non-AP MLD is associated with the AP MLD, and the non-AP MLD updates the links (for example, adding or deleting a link) by re-association, the existing association, security, and other context information between the AP MLD and the non-AP MLD will be removed, disrupting ongoing data communication on the established multilinks. This incurs additional network overhead for re-establishing all context information. Therefore, relevant standards propose a multilink reconfiguration operation.

[0098] The multi-link reconfiguration operation includes:

[0099] (1) Operates from the perspective of AP MLD, enabling AP MLD to dynamically add or remove its affiliated APs;

[0100] (2) Operating from the perspective of non-AP MLD, non-AP MLD can seamlessly add and / or delete links to an existing multilink, without requiring the non-AP MLD to reassociate with the AP MLD (i.e., perform multilink (re)establishment). For example, when an AP MLD associated with a non-AP MLD adds a new subordinate AP, the non-AP MLD can add the new link to the existing multilink through multilink reconfiguration. Similarly, the non-AP MLD can delete unused links (for whatever reason) from an existing multilink through multilink reconfiguration, freeing up resources and simplifying link management.

[0101] The relevant standards define new protected Extremely High Throughput (EHT) action frames for Link Reconfiguration Request / Response messages to support seamless addition and / or deletion of links to an existing multi-link of a non-AP MLD without requiring the non-AP MLD to associate or reassociate with the peer MLD.

[0102] The non-AP MLD initiates the addition and / or deletion of links to an established multilink. Its main definitions include:

[0103] (1) The Reconfiguration Multi-Link element is enhanced to support adding and / or deleting links. The Reconfiguration Multi-Link element carries one or more Per-STA Profile subelements, each of which contains an Operation Update Type subfield. The Operation Update Type subfield is set to indicate the MLO update type of the link indicated by the Link IDentifier (Link ID) subfield contained in the subelement (including AP removal, operation parameter update, link addition, link deletion, etc.). In the Reconfiguration Multi-Link element transmitted by AP MLD, the Link ID subfield specifies a value that uniquely identifies the link being operated by the reported AP. In the Reconfiguration Multi-Link element transmitted by non-AP MLD, the Link ID subfield specifies the link to be reconfigured.

[0104] (2) A single link reconfiguration request frame can indicate the addition and / or removal of links. The AP MLD can partially or fully accept multiple link reconfiguration requests and indicate the result status of the link reconfiguration in a link reconfiguration response frame.

[0105] (3) The Link Reconfiguration Response frame provides the Group Temporal Key (GTK), Integrity Group Temporal Key (IGTK), and Beacon Integrity Group Temporal Key (BIGTK) for any new link added to an established multilink. The MLO Key Data Encapsulation (KDE) of the GTK / IGTK / BIGTK is sent in the Link Reconfiguration Response frame. No additional message exchange is required to establish the group key for the newly added link.

[0106] (4) A new Link Reconfiguration Notification frame is defined for AP MLD to recommend which links to add and / or delete from the MLD settings of the associated non-AP MLD.

[0107] Although FT can reduce the duration of connectivity loss between a STA and a DS, or between a non-AP MLD and a DS, during a BSS handover, the STA (or non-AP MLD) must reassociate with the target AP (or target AP MLD) and reestablish the data transmission and reception protocol. Therefore, data continuity between the STA (or non-AP MLD) and the DS cannot be maintained.

[0108] While the logical AP MLD solution theoretically supports multiple APs in different locations attached to a single logical AP MLD using different links to provide services for the same non-AP MLD, achieving non-AP MLD roaming without interruption, when multiple APs in different locations communicate with the same non-AP MLD over different links, synchronization of data communication status and confirmation of transmission and reception based on the non-AP MLD between the APs is difficult due to their different locations. This places high demands on the communication quality of the backhaul links between the APs.

[0109] The present application proposes a link reconfiguration method for switching a non-AP MLD from a current AP MLD to a target AP MLD. FIG4 shows a flowchart of the switching method provided by an exemplary embodiment of the present application. The method is performed by a non-AP MLD 410, a current AP MLD 420, and a target AP MLD 430. The method includes:

[0110] Step 401: The non-AP MLD 410 sends a link reconfiguration request frame to the current AP MLD 420.

[0111] The link reconfiguration request frame is used to instruct the non-AP MLD 410 to request link reconfiguration with the current AP MLD 420 and the target AP MLD 430 to achieve handover.

[0112] In some embodiments, the link reconfiguration request frame includes:

[0113] The first element corresponding to the current AP MLD420 is used to delete at least one link between the current AP MLD420 and the current AP MLD420;

[0114] The second element corresponding to the target AP MLD430 is used to establish at least one link with the target AP MLD430.

[0115] In some embodiments, the first element includes a first reconfiguration multilink element for describing reconfiguration multilink information of the non-AP MLD and the current AP MLD;

[0116] The second element includes a second reconfiguration multilink element, which is used to describe the reconfiguration multilink information of the non-AP MLD and the target AP MLD.

[0117] In some embodiments, the link reconfiguration request frame further includes:

[0118] The first flow identifier to link mapping element is used to perform flow identifier to link mapping on the link established with the target AP MLD.

[0119] In some embodiments, the format of the link reconfiguration request frame is as shown in Table 1:

[0120] Table 1

[0121] Exemplarily, the first reconfiguration multilink element is a reconfiguration multilink element with an order of 5, the second reconfiguration multilink element is a reconfiguration multilink element with an order of 6, and the first flow identifier to link mapping element is a flow identifier to link mapping element with an order of 8.

[0122] The format of the above-mentioned link reconfiguration request frame is an exemplary possible situation. In different embodiments or different designs, it is not ruled out that at least one of the designs of the link reconfiguration request frame and other fields, the order of information, the information included, the number of bytes occupied, and the information name may change. This embodiment does not limit this.

[0123] Step 402 : The current AP MLD 420 sends a link reconfiguration request frame to the target AP MLD 430 .

[0124] For details of the link reconfiguration request frame, please refer to step 401 and will not be repeated here.

[0125] Step 403: The target AP MLD 430 sends a link reconfiguration response frame to the current AP MLD 420.

[0126] The link reconfiguration response frame is used to feed back the link reconfiguration performed with the target AP MLD 430 to the non-AP MLD 410 .

[0127] In some embodiments, the link reconfiguration response frame includes:

[0128] The third element corresponding to the current AP MLD is used to indicate the link reconfiguration status corresponding to the current AP MLD;

[0129] The fourth element corresponding to the target AP MLD is used to indicate the link reconfiguration state corresponding to the target AP MLD.

[0130] The third element includes at least one of the following: a reconfiguration state list of the current AP MLD, including at least one reconfiguration state tuple; the number of reconfiguration state tuples of the current AP MLD;

[0131] The fourth element includes at least one of the following: a reconfiguration state list of the target AP MLD, including at least one reconfiguration state element; a number of reconfiguration state tuples of the target AP MLD;

[0132] The reconfiguration status element is used to indicate the reconfiguration status of a link.

[0133] In some embodiments, the link reconfiguration response frame may be an action frame of protected EHT or ultra-high reliability (UHR), UHR+ type. The format of the link reconfiguration response frame is shown in Table 2:

[0134] Table 2

[0135] For example, the third element includes the number of reconfiguration status tuples of the current AP MLD with an order of 6 and the reconfiguration status list of the current AP MLD with an order of 7; the fourth element includes the number of reconfiguration status tuples of the target AP MLD with an order of 8 and the reconfiguration status list of the target AP MLD with an order of 9.

[0136] The format of the above-mentioned link reconfiguration response frame is an exemplary possible situation. In different embodiments or different designs, it is not ruled out that at least one of the designs of the link reconfiguration response frame and other fields, the order of information, the information included, the number of bytes occupied, and the information name may change. This embodiment does not limit this.

[0137] Step 404: The current AP MLD 420 sends a link reconfiguration response frame to the non-AP MLD 410.

[0138] The link reconfiguration response frame is used to feed back the link reconfiguration performed with the current AP MLD 420 and the target AP MLD 430 to the non-AP MLD 410 .

[0139] Compared with step 403, in step 404, the current AP MLD 420 adds information about the link reconfiguration performed with the current AP MLD 420 to the link reconfiguration response frame. For details of the link reconfiguration response frame, refer to Table 2 and are not repeated here.

[0140] In summary, the method provided in this embodiment optimizes the link reconfiguration protocol between the current AP MLD and the target AP MLD at different locations by sending and / or receiving a link reconfiguration request frame and a link reconfiguration response frame. The link reconfiguration request frame and the link reconfiguration response frame are used to implement switching between the current AP MLD and the target AP MLD at different locations based on link reconfiguration, thereby implementing switching of the non-AP MLD between the current AP MLD and the target AP MLD during communication.

[0141] FIG5 shows a flowchart of a handover method provided by an exemplary embodiment of the present application. The method is performed by a non-AP MLD. The method includes:

[0142] Step 510: Send and / or receive at least one first frame.

[0143] The at least one first frame is used to implement switching between two AP MLDs at different locations based on link reconfiguration.

[0144] In some embodiments, the two AP MLDs belong to the same mobility domain MLD, or the two AP MLDs belong to the same mobility domain.

[0145] The mobility domain MLD, also called logical AP MLD, treats multiple AP MLDs that are not in the same location as one MLD. This embodiment does not limit the specific name of the mobility domain MLD.

[0146] In some embodiments, the non-AP MLD switches between two AP MLDs in at least one of the following scenarios:

[0147] Switching scenario 1: When the non-AP MLD is associated with the mobility domain MLD, and two AP MLDs belong to the same mobility domain MLD, the non-AP MLD switches between the two AP MLDs at the AP MLD-level association level to which the mobility domain MLD belongs.

[0148] Switching scenario 2: When the non-AP MLD is associated with only one of the two AP MLDs, and the two AP MLDs are not affiliated with the same mobility domain MLD, the non-AP MLD switches its association between the two AP MLDs.

[0149] The switching (transition) in the embodiment of the present application can also be replaced by describing as conversion.

[0150] For handover scenario 1, handover of the AP MLD-level association to the mobility domain MLD means that before the handover, the non-AP MLD is associated with the mobility domain MLD, and the non-AP MLD establishes multiple links with an AP MLD affiliated with the mobility domain MLD (i.e., all or part of the links established between the non-AP MLD and the mobility domain MLD belong to the links between the non-AP MLD and the AP MLD affiliated with the mobility domain MLD). After the handover, the non-AP MLD is still associated with the mobility domain MLD, and the non-AP MLD establishes multiple links with another AP MLD affiliated with the mobility domain MLD (i.e., all or part of the links established between the non-AP MLD and the mobility domain MLD belong to the links between the non-AP MLD and another AP MLD affiliated with the mobility domain MLD).

[0151] For handover scenario 2, the non-AP MLD associates with access point multi-link devices affiliated with different mobility domain MLDs before and after the handover, thereby performing association handover.

[0152] For the mobility domain MLD to which the current AP MLD among the two AP MLDs belongs, the mobility domain MLD belongs to multiple AP MLDs including the current AP MLD.

[0153] For the mobility domain MLD to which the target AP MLD in the two AP MLDs belongs, the mobility domain MLD belongs to multiple AP MLDs including the target AP MLD.

[0154] The switching provided in the embodiments of the present application may include BSS switching, FT, seamless BSS switching or seamless fast switching.

[0155] It should be noted that the method provided in the embodiment of the present application is for switching non-AP MLD from the current AP MLD to the target AP MLD in the scenario of mobile domain AP MLD. This method is also applicable to the switching of non-MLD STA from the current AP to the target AP in the scenario of mobile domain AP MLD.

[0156] In some embodiments, the two AP MLDs belong to the same mobility domain MLD, which is used for at least one of the following:

[0157] Provides connection services between a non-AP MLD or two AP MLDs and DS;

[0158] Maintaining data continuity for non-AP MLD switching between two AP MLDs during roaming.

[0159] Authentication and / or association or reassociation of non-AP MLD;

[0160] Non-AP MLD security associations;

[0161] Distribution of all or part of the security association information for non-AP MLD;

[0162] Synchronize all or part of the state and / or buffer information of the upper layers of the MAC layer above the two APs' MLD layers;

[0163] Manage the distribution of authentication information for non-AP MLD links;

[0164] Manages the AP MLD-level association or reassociation between a non-AP MLD and two AP MLDs.

[0165] For the target AP MLD that establishes a multilink with a non-AP multilink device, select the MAC address corresponding to the target AP MLD for data transmission.

[0166] Synchronization of first data between two AP MLDs, where the first data is used to maintain data communication between the non-AP MLD and the two AP MLDs or DSs;

[0167] MLD-level information is exchanged or indicated via the MAC sublayer of the two AP MLDs.

[0168] In some embodiments, sending and / or receiving at least one first frame includes:

[0169] Send a link reconfiguration request frame. The link reconfiguration request frame is used to instruct the non-AP MLD to request link reconfiguration with two AP MLDs to achieve handover.

[0170] A link reconfiguration response frame is received. The link reconfiguration response frame is used to feed back the link reconfiguration performed with the two AP MLDs to the non-AP MLD.

[0171] In some embodiments, the two AP MLDs include a current AP MLD and a target AP MLD. The link reconfiguration request frame is sent by the non-AP MLD to the current AP MLD, and then sent by the current AP MLD to the target AP MLD.

[0172] In some embodiments, the two AP MLDs include a current AP MLD and a target AP MLD. The link reconfiguration response frame is sent by the target AP MLD to the current AP MLD, and then fed back by the current AP MLD.

[0173] When the non-AP MLD needs to switch from communicating with the current AP MLD to communicating with the target AP MLD, the non-AP MLD sends a link reconfiguration request frame to the current AP MLD. The link reconfiguration request frame is used to request to delete at least one link between it and the current AP MLD. The current AP MLD then sends a link reconfiguration request frame to the target AP MLD. The link reconfiguration request frame is used to request to establish at least one link between the non-AP MLD and the target AP MLD.

[0174] The target AP MLD sends a link reconfiguration response frame to the current AP MLD. The link reconfiguration response frame indicates the link reconfiguration status of the target AP MLD, for example, whether a link is established with the non-AP MLD. The current AP MLD sends a link reconfiguration response frame to the non-AP MLD. The link reconfiguration response frame indicates the link reconfiguration status of the current AP MLD and the target AP MLD, for example, whether the current AP MLD deletes the link and whether the target AP MLD establishes a link with the non-AP MLD.

[0175] In some embodiments, the two AP MLDs include a current AP MLD and a target AP MLD;

[0176] The link reconfiguration request frame includes:

[0177] The first element corresponding to the current AP MLD is used to delete at least one link with the current AP MLD;

[0178] The second element corresponding to the target AP MLD is used to establish at least one link with the target AP MLD.

[0179] In some embodiments, the first element includes a first reconfiguration multilink element for describing reconfiguration multilink information of the non-AP MLD and the current AP MLD;

[0180] The second element includes a second reconfiguration multilink element, which is used to describe the reconfiguration multilink information of the non-AP MLD and the target AP MLD.

[0181] In some embodiments, the link reconfiguration request frame further includes:

[0182] The first flow identifier to link mapping element is used to perform flow identifier to link mapping on the link established with the target AP MLD.

[0183] In some embodiments, the format of the link reconfiguration request frame is as shown in Table 1 in the embodiment of Figure 4. For example, the third element includes the number of reconfiguration status tuples of the current AP MLD with an order of 6, and the reconfiguration status list of the current AP MLD with an order of 7; the fourth element includes the number of reconfiguration status tuples of the target AP MLD with an order of 8, and the reconfiguration status list of the target AP MLD with an order of 9.

[0184] In some embodiments, the two AP MLDs include a current AP MLD and a target AP MLD, and the link reconfiguration response frame includes:

[0185] The third element corresponding to the current AP MLD is used to indicate the link reconfiguration status corresponding to the current AP MLD;

[0186] The fourth element corresponding to the target AP MLD is used to indicate the link reconfiguration state corresponding to the target AP MLD.

[0187] In some embodiments, the third element includes at least one of the following: a reconfiguration state list of the current AP MLD, including at least one reconfiguration state tuple; the number of reconfiguration state tuples of the current AP MLD;

[0188] The fourth element includes at least one of the following: a reconfiguration state list of the target AP MLD, including at least one reconfiguration state element; a number of reconfiguration state tuples of the target AP MLD;

[0189] The reconfiguration status element is used to indicate the reconfiguration status of a link.

[0190] In some embodiments, the link reconfiguration response frame can be an action frame of protected EHT, UHR, or UHR+ type. The format of the link reconfiguration response frame is shown in Table 2 in the embodiment of Figure 4. For example, the third element includes the number of reconfiguration status tuples of the current AP MLD (ordered 6) and the reconfiguration status list of the current AP MLD (ordered 7); the fourth element includes the number of reconfiguration status tuples of the target AP MLD (ordered 8) and the reconfiguration status list of the target AP MLD (ordered 9).

[0191] In some embodiments, the two AP MLDs belong to the same mobility domain MLD, or the two AP MLDs belong to the same mobility domain, the method further includes:

[0192] Send and / or receive first indication information, where the first indication information is used to indicate the mobility domain MLD.

[0193] In some embodiments, the first indication information is carried in at least one of the following frames:

[0194] Link reconfiguration request frame;

[0195] Link reconfiguration response frame;

[0196] Request frame;

[0197] Response frame;

[0198] FT request frame;

[0199] FT response frame;

[0200] FT confirmation frame;

[0201] FT response frame;

[0202] Association request frame;

[0203] Association response frame;

[0204] Reassociation request frame;

[0205] Reassociation response frame;

[0206] The request frame instructs the non-AP MLD to request context replication or migration between two AP MLDs to maintain data connectivity during handover. The response frame indicates the result of context replication or migration to the non-AP MLD.

[0207] In some embodiments, the first indication information includes at least one of the following:

[0208] Mobile domain MLD identifier;

[0209] Mobility domain MLD MAC address.

[0210] Illustratively, the first indication information is called a Mobility Domain Element (MDE), which is used to indicate link reconfiguration in a mobility domain MLD scenario and carries information such as mobility domain MLD information (e.g., a mobility domain MLD identifier or a mobility domain MLD MAC address), whether FT is within the same mobility domain MLD, etc. The AP MLD can use the MDE to notify that the AP MLD is included in or affiliated with a mobility domain MLD, notify the AP MLD of support for the FT function, and provide FT policy information, including whether FT is supported or permitted between two AP MLDs affiliated with the same mobility domain MLD.

[0211] In some embodiments, the switching is based on FT, the method further comprising:

[0212] Send and / or receive second indication information, where the second indication information is used to indicate whether to support or allow FT between two AP MLDs attached to the same mobility domain MLD.

[0213] FT between two AP MLDs attached to the same mobility domain MLD is used to maintain data connectivity during handover, compared with FT between two AP MLDs.

[0214] In some embodiments, the second indication information is carried in at least one of the following frames:

[0215] Link reconfiguration request frame;

[0216] Link reconfiguration response frame;

[0217] Request frame;

[0218] Response frame;

[0219] FT request frame;

[0220] FT response frame;

[0221] FT confirmation frame;

[0222] FT response frame;

[0223] Association request frame;

[0224] Association response frame;

[0225] Reassociation request frame;

[0226] Reassociation response frame;

[0227] The request frame instructs the non-AP MLD to request context replication or migration between two AP MLDs to maintain data connectivity during handover. The response frame indicates the result of context replication or migration to the non-AP MLD.

[0228] In some embodiments, based on the mobility domain MLD architecture, a high-level architecture of the mobility domain MLD and its subordinate AP MLDs and non-AP MLDs for switching a non-AP MLD (or STA) for data connectivity from a current AP MLD (or AP) to a target AP MLD (or AP) is shown in FIG6 .

[0229] The high-level system architecture includes at least one of the following: DS 610 , mobility domain MLD general sublayer 620 , a first switching module 630 , an auxiliary MLD upper MAC sublayer 640 , an auxiliary MLD lower MAC sublayer 650 , a second switching module 660 , a non-AP MLD lower MAC sublayer 670 , and a non-AP MLD upper MAC sublayer 680 .

[0230] The DS610 is an architecture for distributing computing and communication functions across multiple nodes or devices. The primary function of the DS is to coordinate and manage computing and communication tasks in a distributed environment to achieve efficient data transmission and collaboration.

[0231] The mobility domain MLD general sublayer 620 includes a mobility domain AP MLD 621 . The MLD MAC address of the mobility domain AP MLD 621 is Q, and data communication is performed with the DS 610 via a first MAC-Service Access Point (SAP).

[0232] AP MLD1, whose MLD MAC address is M, and AP MLD2, whose MLD MAC address is N, have the same functions. AP MLD1 is used as an example for description. Mobility domain AP MLD 621 communicates data with AP MLD1 via first switching module 630. First switching module 630 is a module within mobility domain AP MLD 621, a module within AP MLD 1, or a module within another AP MLD.

[0233] AP MLD1 communicates data with AP1 (MAC address w) and AP2 (MAC address x) via the second MAC-SAP. AP1 and AP2 have identical functions, so AP1 is used as an example for this description. AP1 communicates data with second switching module 660 via link 1. Second switching module 660 is a module in non-AP MLD 681, AP MLD 1, or another AP MLD.

[0234] Non-AP STA1 with MAC address y and non-AP STA2 with MAC address z have the same functions. Non-AP STA1 associates with AP1 and AP3 with MAC address r, while non-AP STA2 associates with AP2 and AP4 with MAC address s. Non-AP STA1 is used as an example for this description. Non-AP MLD with MAC address P communicates with non-AP STA1 through the fourth MAC-SAP.

[0235] The functions of the mobility domain MLD general sublayer 620 include at least one of the following:

[0236] (1) Provides the distributed system access function (DSAF) to the AP MLDs (e.g., AP MLD1 and AP MLD2) attached to the mobility domain MLD.

[0237] (2) Authentication, association, and reassociation functions between the non-AP MLD681 and the mobile domain AP MLD621;

[0238] (3) Security associations, such as Pairwise Master Key Security Association (PMKSA) and Pairwise Transient Key Security Association (PTKSA), and managing the distribution of GTK / IGTK / BIGTK;

[0239] (4) Manage the partial association and reassociation functions between the non-AP MLD681 and the AP MLDs attached to the mobility domain AP MLD;

[0240] (5) For the subordinate AP MLD associated with non-AP MLD 681, select the MAC address of the subordinate AP MLD for data transmission;

[0241] (6) Synchronize (copy or migrate) all or part of the state and buffer information of the upper layer of the MAC layer of the subordinate MLD of the mobility domain MLD;

[0242] (7) MLD-level management information exchange / indication is performed through the MAC sublayer of the MLD-attached layer.

[0243] The synchronization of all or part of the upper layer status and buffer information of the MAC layer above the MLD of the mobility domain MLD includes:

[0244] For a designated non-AP MLD associated with a mobility domain MLD, the non-AP MLD switches from the current AP MLD to the target AP MLD to which it is associated. This involves synchronizing all or part of the state and buffer information of the upper layers of the MAC layer above the subordinate MLD. This ensures the continuity of data communication sessions and data transmission during the process of the non-AP MLD being associated with different subordinate AP MLDs due to roaming.

[0245] All or part of the upper layer status and buffer information of the MAC layer above the subordinate MLD of the mobility domain MLD, that is, the session or protocol status and buffer information maintained for data exchange with the designated non-AP MLD (for the designated non-AP MLD), including at least one of the following:

[0246] (1) Unicast frame sequence number (SN) / packet number (PN) allocation status and related buffer data;

[0247] (2) SN allocation status and related buffer data of group-addressed MAC Service Data Unit (MSDU);

[0248] (3) buffer data for energy saving in individually addressed frames;

[0249] (4) Block Ack session status and duplicate detection and reordering buffer data for received frames;

[0250] (5) The PN counter status of the sending end and the replay detection status and related buffer data of the receiving end.

[0251] In some embodiments, the link reconfiguration response frame includes a status code indicating link reconfiguration in a mobility domain MLD scenario. When the status code is a first value, it indicates rejection of the mobility domain link reconfiguration.

[0252] The format of the link reconfiguration response frame is shown in Table 2 of the embodiment of Figure 4, where the status code value, name, and meaning of the newly added status code subfield with the order of 5 are shown in Table 3. When the status code value is 142 or other values, it is used to indicate that the mobility domain link reconfiguration is rejected, the mobility domain link reconfiguration request fails, and the target AP MLD does not successfully add a link.

[0253] Table 3

[0254] In some embodiments, the reconfiguration status list subfield of the current AP MLD and the reconfiguration status list subfield of the target AP MLD both adopt the reconfiguration status list format. The reconfiguration status list includes one or more reconfiguration status tuples, as shown in FIG7 . FIG7 is a schematic diagram of the reconfiguration status list subfield format provided by an exemplary embodiment of the present application. The reconfiguration status list subfield format includes at least one of the following: a link ID information (Link ID Info) field and a status (Status) field. In the embodiments of the present application, domains and fields have the same meaning, and subdomains and fields have the same meaning.

[0255] The Link ID field occupies one byte, and the Status field occupies two bytes. The format of the Link ID field follows the IEEE 802.11be definition. The Link ID field in the Link ID field indicates the link identifier corresponding to the AP MLD and is used to delete existing links or add new links in the corresponding Link Reconfiguration Request frame. The Status field indicates the status of the Link Reconfiguration operation for the link corresponding to the Link ID field.

[0256] The above-mentioned reconfiguration status list subfield format is an exemplary possible situation. In different embodiments or different designs, it is not ruled out that the position of the reconfiguration status list subfield field in the frame, the arrangement order with other fields, the number of bytes occupied, and at least one of the field names may change. This embodiment does not limit this.

[0257] In some embodiments, the link reconfiguration response frame includes group key data, indicating the group key successfully added to the link corresponding to the target AP MLD. The group key data subfield optionally appears and contains the group key successfully added to the link corresponding to the target AP MLD (status code value equals SUCCESS). Figure 8 shows a schematic diagram of the group key data subfield format provided by an exemplary embodiment of the present application. The group key data subfield format includes at least one of the following: a Key Data Length field and a Key Data field.

[0258] Among them, the key data length field occupies 2 bytes, and the number of bytes occupied by the key data field is variable.

[0259] The group key data subfield contains an MLO GTK KDE, an MLO IGTK KDE, and an MLO BIGTK KDE, which provide the group key identified by the link ID subfield for the link added by the target AP MLD.

[0260] In the case where the link reconfiguration response frame includes a group key data subfield and includes an OCI element, an OCI element subfield may optionally appear.

[0261] The above-mentioned group key data subfield format is an exemplary possible situation. In different embodiments or different designs, it is not ruled out that the position of the group key data subfield field in the frame, the arrangement order with other fields, the number of bytes occupied, and at least one of the field names may change. This embodiment does not limit this.

[0262] In some embodiments, the link reconfiguration response frame includes a basic multi-link element for providing a STA-granular configuration file for one or more subordinate APs of the target AP MLD.

[0263] If the target AP MLD adds at least one link, the Link Reconfiguration Response frame includes a Basic Multilink element, which is used to provide the STA's profile for one or more subordinate APs of the target AP MLD, corresponding to the links successfully added to the multilink reconfiguration of the non-AP MLD. If the target AP MLD does not add a link, the Link Reconfiguration Response frame does not include the Basic Multilink element.

[0264] In some embodiments, the link reconfiguration response frame includes: a second flow identifier to link mapping element, which is used to respond to the flow identifier to link mapping on the link established with the target AP MLD.

[0265] In some embodiments, the link reconfiguration response frame is used by the AP MLD (including the current AP MLD and the target AP MLD) in the mobility domain MLD scenario to respond to the link reconfiguration request frame sent by the non-AP MLD, thereby accepting or rejecting the non-AP MLD's request to delete links and / or add new links on the established multiple links.

[0266] For FT, the link reconfiguration response frame is used by the AP MLD (including the current AP MLD and the target AP MLD) to respond to the link reconfiguration request frame sent by the non-AP MLD in the mobility domain MLD scenario. It accepts or rejects the non-AP MLD's request to delete a link on the current AP MLD's established multilinks and to add a new link on the target AP MLD.

[0267] In some embodiments, the switching is based on the FT, at least one of a link reconfiguration request frame and a link reconfiguration response frame, further comprising:

[0268] The second indication information is used to indicate whether to support or allow FT between two AP MLDs attached to the same mobility domain MLD.

[0269] Exemplarily, the second indication information is called the "Whether FT is in the same mobility domain MLD" field. When the value of this field is 1, it indicates that FT is supported or allowed between two AP MLDs attached to the same mobility domain MLD. When the value of this field is 0, it indicates that FT is not supported or allowed between two AP MLDs attached to the same mobility domain MLD.

[0270] Figure 9 shows a schematic diagram of a mobility domain element format provided by an exemplary embodiment of the present application. The mobility domain element format includes at least one of the following: an element identifier (Element IDentifier, Element ID) field, a length (Length) field, a mobility domain identifier (Mobility Domain IDentifier, MDID) field, an FT capability and policy (FT Capability and Policy) field, a mobility domain MLD identifier field, and a mobility domain MLD MAC address field.

[0271] The Element ID field occupies 1 byte, the Length field occupies 1 byte, the MDID field occupies 2 bytes, the FT Capability and Policy field occupies 1 byte, the Mobility Domain MLD Identifier field occupies 0 or 1 byte, and the Mobility Domain MLD MAC Address field occupies 0 or 6 bytes.

[0272] Regarding the above-mentioned FT capability and policy fields, Figure 10 shows a schematic diagram of the FT capability and policy field format provided by an exemplary embodiment of the present application. The FT capability and policy fields include at least one of the following: FT field through DS, resource request protocol capability field, whether FT is in the same mobile domain MLD (FTinMobileDomainMLD) field, and reserved field.

[0273] Among them, the FT field through DS occupies 1 bit, the resource request protocol capability field occupies 1 bit, the MLD field whether FT is in the same mobility domain occupies 1 bit, and the reserved field occupies 5 bits.

[0274] The "Is FT in the Same Mobility Domain MLD" field indicates whether FT is supported or permitted between two AP MLDs affiliated with the same mobility domain MLD. For example, when the value of the "Is FT in the Same Mobility Domain MLD" field is 1, it indicates that FT is supported or permitted between two AP MLDs affiliated with the same mobility domain MLD. When the value of the "Is FT in the Same Mobility Domain MLD" field is 0, it indicates that FT is not supported or permitted between two AP MLDs affiliated with the same mobility domain MLD. Alternatively, when the value of the "Is FT in the Same Mobility Domain MLD" field is 0, it indicates that FT is supported or permitted between two AP MLDs affiliated with the same mobility domain MLD. When the value of the "Is FT in the Same Mobility Domain MLD" field is 1, it indicates that FT is not supported or permitted between two AP MLDs affiliated with the same mobility domain MLD. This embodiment is not limited to this.

[0275] The "Whether FT is in the same mobility domain MLD" field controls the behavior of STA or non-AP MLD when performing FT. Non-AP MLD can use information from MDE to determine the handover method recommended by AP MLD and the protocols supported by AP MLD.

[0276] The above-mentioned formats of the mobility domain element, FT capability, and policy fields are exemplary possible scenarios. In different embodiments or designs, the position of the mobility domain element, FT capability, and policy fields in the frame, their order relative to other fields, the number of bytes or bits occupied, the element name, or the field name may be changed. This embodiment does not limit this.

[0277] In some embodiments, the method further comprises:

[0278] At least one second frame is sent and / or received, where the second frame is used to synchronize context information related to the non-AP MLD between the two AP MLDs, where the context information includes at least one of state information and buffer information.

[0279] In some embodiments, sending and / or receiving at least one second frame includes:

[0280] Send a request frame, which is used to instruct the non-AP MLD to request synchronization of non-AP MLD-related context information between two AP MLDs.

[0281] A response frame is received, where the response frame is used to feed back to the non-AP MLD the context information related to the synchronization between the two AP MLDs.

[0282] In some embodiments, the context information includes at least one of the following:

[0283] First context information, the first context information is information related to a block confirmation protocol context;

[0284] The second context information is information related to the security association context.

[0285] In some embodiments, the first context information is carried in a block acknowledgement protocol context element.

[0286] In some embodiments, the second context information is carried in a security association context element.

[0287] Block confirmation protocol context elements:

[0288] In some embodiments, the block confirmation protocol context may also be described as a block confirmation protocol scenario (Block Ack context), a block confirmation context, or a block confirmation scenario, which is information of the maintained block confirmation process.

[0289] In some embodiments, the block acknowledgment protocol context element includes information about a block acknowledgment protocol context or state that the specified MLD has established and maintained with one or more peer MLDs (i.e., non-AP MLDs). The block acknowledgment protocol context element includes a block acknowledgment protocol context parameter control field, which is used to indicate at least one of the following:

[0290] The device where the block confirmation protocol context element is located;

[0291] Whether the device containing the block acknowledgment protocol context element and the non-AP MLD for which the block acknowledgment protocol context is targeted are the same device;

[0292] If the device containing the block acknowledgment protocol context element and the non-AP MLD targeted by the block acknowledgment protocol context are the same device, the non-AP MLD targeted by the block acknowledgment protocol context;

[0293] • The number of Block Acknowledgement Protocol Context Parameter Sets included in the Block Acknowledgement Protocol Context element.

[0294] In some embodiments, the device where the Block ACK protocol context element resides is the current AP MLD.

[0295] Figure 11 shows a schematic diagram of a block acknowledgment protocol context element format provided by an exemplary embodiment of the present application. The block acknowledgment protocol context element format includes at least one of the following: an element ID field, a length field, an element ID extension field, a block acknowledgment protocol context parameter control field, and a block acknowledgment protocol context parameter set list field. In the embodiment of the present application, a domain and a field have the same meaning, and a subdomain and a field have the same meaning.

[0296] Among them, the element ID field occupies 1 byte, the length field occupies 1 byte, the element ID extension field occupies 1 byte, the block confirmation protocol context parameter control field occupies 9 or 15 bytes, and the block confirmation protocol context parameter set list field occupies a variable number of bytes.

[0297] Regarding the above-mentioned block acknowledgment protocol context parameter control field, Figure 12 shows a format diagram of the block acknowledgment protocol context parameter control field provided by an exemplary embodiment of the present application. The block acknowledgment protocol context parameter control field includes at least one of the following: MLD MAC address field, whether the opposite MLD is the same MLD field, the opposite MLD MAC address field, the number of single block acknowledgment protocol context parameter sets field, and a reserved field.

[0298] The MLD MAC address field occupies 48 bits, whether the peer MLD is the same MLD field occupies 1 bit, the peer MLD MAC address field occupies 0 or 48 bits, the single block confirmation protocol context parameter set number field occupies 16 bits, and the reserved field occupies 7 bits.

[0299] The MLD MAC address field indicates the MAC address of the MLD where the block acknowledgment protocol context described by the block acknowledgment protocol context element is located. The MLD MAC address may be the MLD address of a roaming MLD.

[0300] The "Whether the opposite-end MLD is the same MLD" field indicates whether the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element is the same MLD. When its value is 0, it indicates that the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation context scenario element is the same MLD; when its value is 1, it indicates that the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element is multiple MLDs. Alternatively, when its value is 1, it indicates that the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation context scenario element is the same MLD; when its value is 0, it indicates that the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element is multiple MLDs. This is not limited in the embodiments of the present application.

[0301] The peer MLD MAC address indicates the MAC address of the peer MLD for the block acknowledgment protocol context described by the block acknowledgment protocol context element. When its value is 0, the peer MLD MAC address field is present in the block acknowledgment protocol context parameter control field; when its value is 1, the peer MLD MAC address field is not present in the block acknowledgment protocol context parameter control field. Alternatively, when its value is 1, the peer MLD MAC address field is present in the block acknowledgment protocol context parameter control field; when its value is 0, the peer MLD MAC address field is not present in the block acknowledgment protocol context parameter control field. This is not limited in this embodiment of the present application.

[0302] The Number of Single Block Acknowledgement Protocol Context Parameter Sets field is a 16-bit unsigned integer indicating the number of Single Block Acknowledgement Protocol Context Parameter Set fields in the Block Acknowledgement Protocol Context Parameter Set List field.

[0303] In some embodiments, the block confirmation protocol context element includes a block confirmation protocol context parameter set list field, the block confirmation protocol context parameter set list field includes at least one block confirmation protocol context parameter set subfield, and a block confirmation protocol context parameter set subfield is used to indicate a block confirmation protocol context parameter set.

[0304] In some embodiments, the Block ACK Protocol Context Parameter Set subfield is used to indicate at least one of the following:

[0305] The role of the device in the block acknowledgement protocol context;

[0306] Non-AP MLD for the Block ACK protocol context;

[0307] Block confirmation parameter set;

[0308] Block confirmation timeout value.

[0309] Regarding the above-mentioned block confirmation protocol context parameter set list field, Figure 13 shows a format diagram of the block confirmation protocol context parameter set list field provided by an exemplary embodiment of the present application. The block confirmation protocol context parameter set list field includes at least one of the following: one or more single block confirmation protocol context parameter set fields, and a padding field.

[0310] Among them, the number of bits occupied by a single block confirmation protocol context parameter set field is variable, and the number of bits occupied by the padding field is variable.

[0311] In some embodiments, if the block acknowledgment protocol context parameter set subfield is used to indicate that the role of the device in the corresponding block acknowledgment protocol context is an initiator in the block acknowledgment protocol context, the block acknowledgment protocol context parameter set subfield is further used to indicate at least one of the following:

[0312] Send window starting sequence number;

[0313] Send window size.

[0314] In some embodiments, if the block acknowledgment protocol context parameter set subfield is used to indicate that the device in the block acknowledgment protocol context has a role as a receiver in the block acknowledgment protocol context, the block acknowledgment protocol context parameter set subfield is further used to indicate at least one of the following:

[0315] Receive buffer starting sequence number;

[0316] Receive window size;

[0317] Record the starting sequence number of the bitmap;

[0318] Record the maximum sequence number of the bitmap;

[0319] Record the bitmap size.

[0320] For the above-mentioned single block acknowledgment protocol context parameter set field, when the MLD where the block acknowledgment protocol context is located is the initiator MLD role, Figure 14 shows a format diagram of a single block acknowledgment protocol context parameter set field provided by an exemplary embodiment of the present application. The single block acknowledgment protocol context parameter set field includes at least one of the following: MLD role field (initiator MLD), peer MLD (Peer MLD) field, block acknowledgment parameter set (Block Ack Parameter Set) field, block acknowledgment timeout value (Block Ack Timeout) field, send window starting sequence number (WinStartO) field, and send window size (WinSizeO) field.

[0321] Among them, the MLD role field (initiator MLD) occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the block confirmation parameter set field occupies 16 bits, the block confirmation timeout value field occupies 8 bits, the send window starting sequence number field occupies 12 bits, and the send window size field occupies 10 bits.

[0322] In the case where the MLD where the block acknowledgment protocol context is located is the receiver MLD role, Figure 15 shows a format diagram of a single block acknowledgment protocol context parameter set field provided by an exemplary embodiment of the present application. The single block acknowledgment protocol context parameter set field includes at least one of the following: MLD role field (receiver MLD), peer MLD (Peer MLD) field, block acknowledgment parameter set (Block Ack Parameter Set) field, block acknowledgment timeout value (Block Ack Timeout) field, receive buffer start sequence number (WinStartB) field, receive window size (WinSizeB) field, record bitmap start sequence number (WinStartR) field, record bitmap maximum sequence number (WinEndR) field, and record bitmap size (WinSizeR) field.

[0323] Among them, the MLD role field (receiver MLD) occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the block confirmation parameter set field occupies 48 bits, the block confirmation timeout value field occupies 16 bits, the receive buffer starting sequence number field occupies 12 bits, the receive window size field occupies 10 bits, the record bitmap starting sequence number field occupies 12 bits, the record bitmap maximum sequence number field occupies 12 bits, and the record bitmap size field occupies 10 bits.

[0324] The MLD role field indicates the role played by the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located in the block confirmation protocol. Exemplarily, when the value of the MLD role field is 0, it indicates that the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located plays the role of the initiator MLD in the block confirmation protocol; when the value of the MLD role field is 1, it indicates that the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located plays the role of the receiver MLD in the block confirmation protocol. Alternatively, when the value of the MLD role field is 1, it indicates that the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located plays the role of the initiator MLD in the block confirmation protocol; when the value of the MLD role field is 0, it indicates that the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located plays the role of the receiver MLD in the block confirmation protocol.

[0325] When the MLD where the block confirmation protocol context is located is the initiator role, the format of a single block confirmation protocol context parameter set is shown in Figure 14. When the MLD where the block confirmation protocol context is located is the receiver role, the format of a single block confirmation protocol context parameter set is shown in Figure 15.

[0326] The peer MLD field indicates the MAC address of the peer MLD for which the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set field is targeted.

[0327] The Block Acknowledgement Parameter Set field indicates the relevant parameter set of the established Block Acknowledgement protocol corresponding to the Block Acknowledgement Protocol Context described by the single Block Acknowledgement Protocol Context Parameter Set field.

[0328] The Block Ack Timeout Value field contains the duration, in TUs (1024 microseconds), after which the Block Ack protocol terminates if no frame exchange sequence occurs within this duration using the Block Ack protocol. Setting this field to 0 disables the timeout.

[0329] The send window starting sequence number field is a send buffer control parameter used to indicate the starting sequence number of the send window.

[0330] In some embodiments, the block confirmation parameter set includes at least one of the following:

[0331] Indication information indicating whether aggregation of MSDUs is supported;

[0332] Block confirmation strategy;

[0333] Flow ID;

[0334] Buffer size.

[0335] Regarding the above-mentioned block acknowledgment parameter set field, Figure 16 shows a format diagram of the block acknowledgment parameter set field provided by an exemplary embodiment of the present application. The block acknowledgment parameter set field includes at least one of the following: Aggregate MSDU (A-MSDU) support field, Block Ack Policy field, Stream Identifier (TID) field, and Buffer Size field.

[0336] Among them, the A-MSDU support field occupies 1 bit, the block confirmation policy field occupies 1 bit, the flow identification field occupies 4 bits, and the buffer size field occupies 10 bits.

[0337] The Send Window Size field is a send buffer control parameter that indicates the send window buffer size negotiated in the Block Ack protocol. The Send Window Size field indicates the number of buffers available for a given TID. When the A-MSDU Support field is 0, the number of bytes each buffer can accommodate is equal to the maximum MSDU size. When the STA Supported A-MSDU field is 1, the number of bytes each buffer can accommodate is equal to the maximum A-MSDU size supported by the STA.

[0338] The receive buffer starting sequence number field is a receive reordering buffer control parameter and indicates the value of the sequence number field of the first MSDU or A-MSDU (arranged in ascending sequence number order) that has not yet been received.

[0339] The receive window size field is a receive reordering buffer control parameter used to indicate the receive window size.

[0340] The Record Bitmap Starting Sequence Number field is a Scoreboard Context Control parameter and is a 12-bit unsigned integer starting sequence number that indicates the lowest sequence number position in the block confirmation record bitmap (indexed by sequence number).

[0341] Records the maximum sequence number field of the bitmap, indicating the highest sequence number in the current transmission window.

[0342] The Record Bitmap Size field is a scoreboard context control parameter used to indicate the maximum transmission window size and is set to the smaller of the value of the Bitmap Length field and the buffer size field of the associated response frame of the established block return protocol.

[0343] The above-mentioned block confirmation protocol context element format, block confirmation protocol context parameter control field format, block confirmation protocol context parameter set list field format, single block confirmation protocol context parameter set field format, and block confirmation parameter set field format are exemplary possible situations. In different embodiments or different designs, it is not ruled out that at least one of the positions of the above-mentioned fields in the frame, the arrangement order with other fields, the number of bytes occupied, the number of bits occupied, the element name, and the field name may be changed. This embodiment does not limit this.

[0344] Security Association Context Elements:

[0345] In some embodiments, the security association context may also be described as a security association scenario, which is information maintained during the security association process.

[0346] In some embodiments, the security association context element includes information about the sender's PN configuration and PN counter status, and / or the receiver's replay detection context and replay counter status, which the designated MLD has established and maintained with one or more peer MLDs for encryption / decryption, and / or integrity protection and verification of security association-related data. FIG17 illustrates a schematic diagram of the security association context element format provided by an exemplary embodiment of the present application. The security association context element format includes at least one of the following: an Element ID field, a Length field, an Element ID Extension field, a Security Association (SA) Context Parameters Control field, and a Security Association Context Parameters Set List field.

[0347] Among them, the element ID field occupies 1 byte, the length field occupies 1 byte, the element ID extension field occupies 1 byte, the security association context parameter control field occupies 9 or 15 bytes, and the security association context parameter set list field occupies a variable number of bytes.

[0348] In some embodiments, the security association context element includes a security association context parameter control field, where the security association context parameter control field is used to indicate at least one of the following:

[0349] The device where the security association context element resides;

[0350] Whether the device containing the security association context element and the non-AP MLD for which the security association context is targeted are the same device;

[0351] If the device containing the security association context element and the non-AP MLD targeted by the security association context are the same device, the non-AP MLD targeted by the security association context;

[0352] The number of security association context parameter sets included in the security association context element.

[0353] In some embodiments, the device where the security association context element resides is the current AP MLD.

[0354] Regarding the above-mentioned security association context parameter control field, Figure 18 shows a format diagram of the security association context parameter control field provided by an exemplary embodiment of the present application. The security association context parameter control field includes at least one of the following: MLD MAC address field, whether the peer MLD is the same MLD field, peer MLD MAC address field, security association scenario parameter set quantity field, and reserved field.

[0355] Among them, the MLD MAC address field occupies 48 bits, whether the peer MLD is the same MLD field occupies 1 bit, the peer MLD MAC address field occupies 0 or 48 bits, the security association scenario parameter set number field occupies 16 bits, and the reserved field occupies 7 bits.

[0356] In some embodiments, the security association context element includes a security association context parameter set list field, the security association context parameter set list field includes at least one security association context parameter set subfield, and a security association context parameter set subfield is used to indicate a security association context parameter set.

[0357] In some embodiments, the security association context parameter set subfield is used to indicate at least one of the following:

[0358] The role of the device in the security association context;

[0359] The non-AP MLD for the security association context;

[0360] The security association type of the security association context.

[0361] Regarding the above-mentioned security association context parameter set list field, Figure 19 shows a format diagram of the security association context parameter set list field provided by an exemplary embodiment of the present application. The security association context parameter set list field includes at least one of the following: one or more security association context parameter set fields.

[0362] The number of bits occupied by the security association context parameter set field is variable.

[0363] In some embodiments, if the security association context parameter set subfield is used to indicate that the role of the device in which the security association context resides is an initiator in the security association context, the security association context parameter set subfield is further used to indicate at least one of the following:

[0364] Replay counter number;

[0365] TID;

[0366] The count of the replay counter for the TID.

[0367] In some embodiments, if the security association context parameter set subfield is used to indicate that the role of the device where the security association context resides in the security association context is a receiver, the security association context parameter set subfield is further used to indicate at least one of the following:

[0368] Packet number counter number;

[0369] TID;

[0370] The count of the packet number counter for the TID.

[0371] For the above-mentioned security association context parameter set field, when the MLD where the security association context described by the security association context parameter set field is located is the receiver MLD role, Figure 20 shows a format diagram of the security association context parameter set field provided by an exemplary embodiment of the present application. The security association context parameter set field includes at least one of the following: MLD role field, peer MLD (Peer MLD) field, PTKSA / Group Temporal Key Security Association (GTKSA) / Tunneled direct link setup PeerKey Security Association (TPKSA) field, the number of replay counters field, one or more TID fields, and one or more replay counter counts (the count of replay counter) fields.

[0372] The MLD role field occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the PTKSA / GTKSA / TPKSA field occupies 2 bits, the replay counter number field occupies 5 bits, the TID field occupies 8 bits, and the replay counter count field occupies 48 bits.

[0373] In the case where the MLD where the security association context described by the security association context parameter set field is located is the sender MLD role, Figure 21 shows a format diagram of the security association context parameter set field provided by an exemplary embodiment of the present application. The security association context parameter set field includes at least one of the following: MLD role field, peer MLD (Peer MLD) field, PTKSA / GTKSA / TPKSA field, PN counter number (the number of PN counters) field, one or more TID fields, and one or more PN counter count (the count of the PN counter) fields.

[0374] Among them, the MLD role field occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the PTKSA / GTKSA / TPKSA field occupies 2 bits, the PN counter number field occupies 5 bits, the TID field occupies 8 bits, the middle PN counter count field occupies 0 or 48 bits, and the last PN counter count field occupies 48 bits.

[0375] The MLD role field indicates the role played by the MLD where the security association context described by the security association context parameter set field is located in the security association context. Exemplarily, when the value of the MLD role field is 0, it indicates that the MLD where the security association context described by the security association context parameter set field is located plays the role of a receiver MLD, that is, it describes the receiving-end replay context parameter set; when the value of the MLD role field is 1, it indicates that the MLD where the security association context described by the security association context parameter set field is located plays the role of a sender MLD, that is, it describes the sending-end PN counter context parameter set. Or, when the value of the MLD role field is 1, it indicates that the MLD where the security association context described by the security association context parameter set field is located plays the role of a receiver MLD; when the value of the MLD role field is 0, it indicates that the MLD where the security association context described by the security association context parameter set field is located plays the role of a sender MLD.

[0376] The PTKSA / GTKSA / TPKSA field indicates the security association type corresponding to the replay context described by the replay context parameter set field, as shown in Table 4. For example, when the value of the PTKSA / GTKSA / TPKSA field is 0, meaning PTKSA, the replay count value field in the replay context parameter set field corresponds to the PTKSA replay count value.

[0377] Table 4

[0378] The above-mentioned block confirmation protocol context element format, security association context parameter control format, security association context parameter set list field format, and security association context parameter set field format are exemplary possible situations. In different embodiments or different designs, it is not ruled out that at least one of the positions of the above-mentioned fields in the frame, the arrangement order with other fields, the number of bytes occupied, the number of bits occupied, the element name, and the field name may change. This embodiment does not limit this.

[0379] In some embodiments, the second frame further includes: third indication information, where the third indication information is used to indicate that the context information includes information about a block acknowledgement protocol context and / or a security association context.

[0380] In some embodiments, the two AP MLDs belong to the same mobility domain MLD, and at least one of the request frame and the response frame further includes:

[0381] The first indication information is used to indicate the mobility domain MLD.

[0382] In some embodiments, the switching is based on at least one of an FT, a request frame, and a response frame, further comprising:

[0383] The second indication information is used to indicate whether FT is supported or permitted between two AP MLDs affiliated with the same mobility domain MLD. Exemplarily, the second indication information is called the "Whether FT is in the same mobility domain MLD" field. When the value of this field is 1, it indicates that FT is supported or permitted between two AP MLDs affiliated with the same mobility domain MLD. When the value of this field is 0, it indicates that FT is not supported or permitted between two AP MLDs affiliated with the same mobility domain MLD.

[0384] In some embodiments, the two AP MLDs include a current AP MLD and a target AP MLD:

[0385] The request frame is sent to the current AP MLD, which then sends it to the target AP MLD.

[0386] The response frame is sent by the target AP MLD to the current AP MLD, and then fed back by the current AP MLD.

[0387] In some embodiments, the switching is based on FT, the request frame is a FT confirmation frame, and the response frame is a FT acknowledgement frame.

[0388] The non-AP MLD sends an FT confirmation frame to the target AP MLD via the current AP MLD. The target AP MLD then sends an FT response frame to the non-AP MLD via the current AP MLD. The FT confirmation frame includes at least one of the following: non-AP MLD information, target AP MLD information, MDE, Block Ack protocol context element, Security Association context element, and Basic Multilink element. The FT response frame includes at least one of the following: non-AP MLD information, target AP MLD information, MDE, Timeout interval element, Block Ack protocol context element, Security Association context element, and Basic Multilink element.

[0389] The FT confirmation frame and the FT response frame carry a block confirmation protocol context element and a security association context element, indicating related block confirmation protocol context (or state) information and security association context (or state) information.

[0390] In some embodiments, the two AP MLDs belong to the same mobility domain MLD, and the method further includes:

[0391] Send FT request frame;

[0392] Receive FT response frame.

[0393] When the non-AP MLD determines that a handover from the current AP MLD to the target AP MLD is required in the mobility domain MLD scenario, the non-AP MLD sends an FT request frame to the target AP MLD via the current AP MLD. The target AP MLD then sends an FT response frame to the non-AP MLD via the current AP MLD. The FT request frame includes at least one of the following: non-AP MLD information, target AP MLD information, MDE, and basic multilink elements. The FT response frame includes at least one of the following: non-AP MLD information, target AP MLD information, MDE, and basic multilink elements.

[0394] The FT request frame and the FT response frame carry an MDE (FTinMobileDomainMLD field, mobile domain MLD information field), indicating that FT is supported or allowed between two AP MLDs attached to the same mobile domain MLD.

[0395] In some embodiments, the method further comprises:

[0396] Send an association request frame;

[0397] Receives an association response frame.

[0398] The non-AP MLD sends an association request frame or a reassociation request frame to the current AP MLD. The current AP MLD then sends an association response frame or a reassociation response frame back to the non-AP MLD.

[0399] The non-AP MLD sends an association request frame or a reassociation request frame to the current AP MLD, including the Mobility Domain Element (MDE) and the Basic Multilink Element.

[0400] The current AP MLD sends an association response frame or a reassociation response frame to the non-AP MLD, including the Mobility Domain Element (MDE) and the Basic Multilink Element.

[0401] The association request frame or reassociation request frame carries the MDE (FTinMobileDomainMLD field, mobile domain MLD information field), instructing the non-AP MLD to associate with the AP MLD in the mobile domain MLD scenario (or the non-AP MLD to associate with the AP MLD affiliated with the mobile domain MLD), and indicating that FT is supported or allowed between two AP MLDs affiliated with the same mobile domain MLD.

[0402] In some embodiments, the switching is based on the FT, and link reconfiguration is performed if the first duration is less than or equal to a deadline for link reconfiguration;

[0403] The first duration represents the duration between the sending time of the FT request frame and the sending time of the link reconfiguration request frame, and the first frame includes the link reconfiguration request frame.

[0404] In some embodiments, the method further includes: sending fourth indication information, where the fourth indication information is used to indicate a deadline or timeout period for link reconfiguration.

[0405] Exemplarily, the fourth indication information is called a timeout interval element (TIE), which is used to specify a time interval and a timeout period.

[0406] In some embodiments, the fourth indication information is indicated by a start time and a timeout interval, or,

[0407] The fourth indication information is indicated by a deadline.

[0408] In some embodiments, the start time is implicitly represented by the sending time or receiving time of the fourth indication information;

[0409] The timeout interval is explicitly indicated by the fourth indication information.

[0410] In an embodiment of the present application, a timeout interval type value corresponding to the link reconfiguration deadline time interval is added to the timeout interval type field of the timeout interval element to indicate that the timeout interval value field represents the link reconfiguration deadline time interval. Figure 22 shows a schematic diagram of the timeout interval element format provided by an exemplary embodiment of the present application. The timeout interval element format includes at least one of the following: an element ID field, a length field, a timeout interval type field, and a timeout interval value field.

[0411] Among them, the element ID field occupies 1 byte, the length field occupies 1 byte, the timeout interval type field occupies 1 byte, and the timeout interval value field occupies 4 bytes.

[0412] The above-mentioned timeout interval element format is an exemplary possible situation. In different embodiments or different designs, it is not ruled out that the position of the timeout interval element in the frame, the arrangement order between other fields, the number of bytes occupied, and at least one of the element names may change. This embodiment does not limit this.

[0413] The Timeout Interval Value field contains a 32-bit unsigned integer, where the Link Reconfiguration Deadline Interval can be set to 0 to indicate that no deadline exists. The Timeout Interval Type field is defined as shown in Table 5:

[0414] Table 5

[0415] In summary, the method provided in this embodiment optimizes the link reconfiguration protocol between two AP MLDs at different locations by sending and / or receiving at least one first frame, where the at least one first frame is used to implement switching between two AP MLDs at different locations based on link reconfiguration, and implements switching of a non-AP MLD between two AP MLDs during communication.

[0416] The method provided in this embodiment also eliminates the time during which data connectivity is lost between the non-AP MLD and the two AP MLDs by copying or migrating the Block Ack protocol context and the Security Association context, thereby maintaining data continuity between the non-AP MLD and the two AP MLDs. The Block Ack protocol context ensures data transmission connectivity, and the Security Association context eliminates the need for renegotiation of keys after handover by omitting the key negotiation process.

[0417] FIG23 shows a flowchart of a handover method provided by an exemplary embodiment of the present application. The method is performed by the non-AP MLD 410, the current AP MLD 420, and the target AP MLD 430. The method includes:

[0418] Step 2310 : The non-AP MLD 410 sends a request frame to the current AP MLD 420 .

[0419] The request frame is used to instruct the non-AP MLD 410 to request synchronization of context information related to the non-AP MLD 410 between the current AP MLD 420 and the target AP MLD 430 .

[0420] In some embodiments, the context information includes at least one of the following:

[0421] First context information, the first context information is information related to a block confirmation protocol context;

[0422] The second context information is information related to the security association context.

[0423] In some embodiments, the first context information is carried in a block acknowledgement protocol context element.

[0424] In some embodiments, the second context information is carried in a security association context element.

[0425] For specific implementation details, please refer to the block confirmation protocol context element part and the security association context element part of the embodiment of Figure 5, which will not be repeated here.

[0426] In some embodiments, the current AP MLD 420 and the target AP MLD 430 belong to the same mobility domain MLD, and at least one of the request frame and the response frame further includes:

[0427] The first indication information is used to indicate the mobility domain MLD.

[0428] In some embodiments, the first indication information includes at least one of the following:

[0429] Mobile domain MLD identifier;

[0430] Mobility domain MLD MAC address.

[0431] Illustratively, the first indication information is called a Mobility Domain Element (MDE), which is used to indicate link reconfiguration in a mobility domain MLD scenario and carries information such as mobility domain MLD information (e.g., a mobility domain MLD identifier or a mobility domain MLD MAC address), whether FT is within the same mobility domain MLD, etc. The AP MLD can use the MDE to notify that the AP MLD is included in or affiliated with a mobility domain MLD, notify the AP MLD of support for the FT function, and provide FT policy information, including whether FT is supported or permitted between two AP MLDs affiliated with the same mobility domain MLD.

[0432] Step 2311 : The current AP MLD 420 sends a request frame to the target AP MLD 430 .

[0433] For specific details of the request frame, please refer to step 2310 and will not be repeated here.

[0434] Step 2320 : The target AP MLD 430 sends a response frame to the current AP MLD 420 .

[0435] The response frame is used to feed back to the non-AP MLD 410 the context information related to the non-AP MLD 410 that is synchronized between the current AP MLD 420 and the target AP MLD 430 .

[0436] Step 2321: The current AP MLD 420 sends a response frame to the non-AP MLD 410.

[0437] For specific details of the response frame, please refer to step 2320 and will not be repeated here.

[0438] Step 2330 : The non-AP MLD 410 sends a link reconfiguration request frame to the current AP MLD 420 .

[0439] Step 2331 : The current AP MLD 420 sends a link reconfiguration request frame to the target AP MLD 430 .

[0440] Step 2340 : The target AP MLD 430 sends a link reconfiguration response frame to the current AP MLD 420 .

[0441] Step 2341: The current AP MLD 420 sends a link reconfiguration response frame to the non-AP MLD 410.

[0442] Steps 2330 to 2341 refer to steps 401 to 404 of the embodiment of FIG. 4 , and are not described again here.

[0443] In this embodiment, steps 2310 to 2321 are optional. In different embodiments, these steps may be omitted or replaced. For example, steps 2310 to 2321 may be omitted and execution may start from step 2330 .

[0444] Steps 2310 to 2321 may be implemented as independent embodiments, steps 2330 to 2341 may be implemented as independent embodiments, step 2310 and step 2311 may be implemented as independent embodiments, step 2320 and step 2321 may be implemented as independent embodiments, step 2330 and step 2331 may be implemented as independent embodiments, and step 2340 and step 2341 may be implemented as independent embodiments, but are not limited thereto.

[0445] Step 2310 may be implemented as an independent embodiment, for example, implemented separately as a method for sending a request frame;

[0446] Step 2311 may be implemented as an independent embodiment, for example, as a method for sending a request frame.

[0447] Step 2320 may be implemented as an independent embodiment, for example, implemented separately as a method for sending a response frame;

[0448] Step 2321 may be implemented as an independent embodiment, for example, implemented separately as a method for sending a response frame;

[0449] Step 2330 may be implemented as an independent embodiment, for example, implemented separately as a method for sending a link reconfiguration request frame;

[0450] Step 2331 may be implemented as an independent embodiment, for example, as a method for sending a link reconfiguration request frame.

[0451] Step 2340 may be implemented as an independent embodiment, for example, as a method for sending a link reconfiguration response frame.

[0452] Step 2341 may be implemented as an independent embodiment, for example, implemented separately as a method for sending a link reconfiguration response frame.

[0453] In summary, the method provided in this embodiment optimizes the link reconfiguration protocol between the current AP MLD and the target AP MLD at different locations by sending and / or receiving a link reconfiguration request frame and a link reconfiguration response frame. The link reconfiguration request frame and the link reconfiguration response frame are used to implement switching between the current AP MLD and the target AP MLD at different locations based on link reconfiguration, thereby implementing switching of the non-AP MLD between the current AP MLD and the target AP MLD during communication.

[0454] The method provided in this embodiment also eliminates the time during which data connectivity between the non-AP MLD, the current AP MLD, and the target AP MLD is lost by sending a request frame to instruct the copying or migration of the block acknowledgment protocol context and the security association context, thereby maintaining data continuity between the non-AP MLD, the current AP MLD, and the target AP MLD. The block acknowledgment protocol context ensures data transmission connectivity, and the security association context eliminates the need for renegotiation of keys after a handover by omitting the key negotiation process.

[0455] FIG24 shows a flowchart of a handover method provided by an exemplary embodiment of the present application. The method is performed by the non-AP MLD 410, the current AP MLD 420, and the target AP MLD 430. The method includes:

[0456] Step 2410 : The non-AP MLD 410 sends an FT request frame to the current AP MLD 420 .

[0457] In some embodiments, the FT request frame includes at least one of the following: non-AP MLD information, target AP MLD information, MDE, and basic multilink element.

[0458] In some embodiments, the current AP MLD 420 and the target AP MLD 430 belong to the same mobility domain MLD, and the FT request frame further includes: first indication information, which is used to indicate the mobility domain MLD.

[0459] In some embodiments, the FT request frame further includes:

[0460] The second indication information is used to indicate whether to support or allow FT between the current AP MLD420 and the target AP MLD430 that are affiliated with the same mobility domain MLD.

[0461] The FT request frame carries an MDE (FTinMobileDomainMLD field, mobile domain MLD information field), indicating that FT is supported or allowed between the current AP MLD 420 and the target AP MLD 430 that are attached to the same mobile domain MLD.

[0462] Step 2411 : The current AP MLD 420 sends an FT request frame to the target AP MLD 430 .

[0463] For details of the FT request frame, please refer to step 2410 and will not be repeated here.

[0464] Step 2420 : The target AP MLD 430 sends an FT response frame to the current AP MLD 420 .

[0465] In some embodiments, the FT response frame includes at least one of the following: non-AP MLD information, target AP MLD information, MDE, and basic multilink element.

[0466] In some embodiments, the current AP MLD 420 and the target AP MLD 430 belong to the same mobility domain MLD, and the FT response frame further includes: first indication information, which is used to indicate the mobility domain MLD.

[0467] In some embodiments, the FT response frame further includes:

[0468] The second indication information is used to indicate whether to support or allow FT between the current AP MLD420 and the target AP MLD430 that are affiliated with the same mobility domain MLD.

[0469] The FT response frame carries an MDE (FTinMobileDomainMLD field, mobile domain MLD information field), indicating that FT is supported or allowed between the current AP MLD 420 and the target AP MLD 430 that are attached to the same mobile domain MLD.

[0470] Step 2421: The current AP MLD 420 sends an FT response frame to the non-AP MLD 410.

[0471] For specific details of the FT response frame, please refer to step 2420 and will not be repeated here.

[0472] Step 2430 : The non-AP MLD 410 sends an FT confirmation frame to the current AP MLD 420 .

[0473] In some embodiments, the handover is based on FT, and the FT confirmation frame includes at least one of the following: non-AP MLD information, target AP MLD information, MDE, block confirmation protocol context element, security association context element, and basic multilink element.

[0474] The FT acknowledgment frame carries a block acknowledgment protocol context element and a security association context element, indicating related block acknowledgment protocol context (or state) information and security association context (or state) information.

[0475] Step 2431 : The current AP MLD 420 sends an FT confirmation frame to the target AP MLD 430 .

[0476] For details of the FT confirmation frame, please refer to step 2430 and will not be repeated here.

[0477] Step 2440 : The target AP MLD 430 sends an FT response frame to the current AP MLD 420 .

[0478] In some embodiments, the handover is based on FT, and the FT response frame includes at least one of the following: non-AP MLD information, target AP MLD information, MDE, timeout interval element, block acknowledgement protocol context element, security association context element, and basic multilink element.

[0479] The FT response frame carries a block acknowledgement protocol context element and a security association context element, indicating related block acknowledgement protocol context (or state) information and security association context (or state) information.

[0480] Step 2441: The current AP MLD 420 sends an FT response frame to the non-AP MLD 410.

[0481] For details of the FT response frame, please refer to step 2440 and will not be repeated here.

[0482] Steps 2430 to 2441 refer to steps 2310 to 2321 of the embodiment of FIG. 23 and are not described again here.

[0483] Step 2450 : The non-AP MLD 410 sends a link reconfiguration request frame to the current AP MLD 420 .

[0484] Step 2451 : The current AP MLD 420 sends a link reconfiguration request frame to the target AP MLD 430 .

[0485] Step 2460 : The target AP MLD 430 sends a link reconfiguration response frame to the current AP MLD 420 .

[0486] Step 2461: The current AP MLD 420 sends a link reconfiguration response frame to the non-AP MLD 410.

[0487] Steps 2450 to 2461 refer to steps 401 to 404 of the embodiment of FIG. 4 , and are not described again here.

[0488] In this embodiment, steps 2410 to 2421 are optional, and steps 2430 to 2441 are optional. In different embodiments, these steps may be omitted or replaced, for example, steps 2410 to 2441 may be omitted and execution may start from step 2450.

[0489] Steps 2410 to 2421 may be implemented as an independent embodiment, steps 2430 to 2441 may be implemented as an independent embodiment, and steps 2450 to 2461 may be implemented as an independent embodiment, but are not limited thereto.

[0490] Step 2410 may be implemented as an independent embodiment, for example, as a method for sending an FT request frame.

[0491] Step 2411 may be implemented as an independent embodiment, for example, as a method for sending an FT request frame.

[0492] Step 2420 may be implemented as an independent embodiment, for example, as a method for sending an FT response frame.

[0493] Step 2421 may be implemented as an independent embodiment, for example, as a method for sending an FT response frame.

[0494] Step 2430 may be implemented as an independent embodiment, for example, as a method for sending an FT confirmation frame.

[0495] Step 2431 may be implemented as an independent embodiment, for example, as a method for sending an FT confirmation frame.

[0496] Step 2440 may be implemented as an independent embodiment, for example, as a method for sending an FT response frame.

[0497] Step 2441 may be implemented as an independent embodiment, for example, as a method for sending an FT response frame.

[0498] Step 2450 may be implemented as an independent embodiment, for example, as a method for sending a link reconfiguration request frame.

[0499] Step 2451 may be implemented as an independent embodiment, for example, as a method for sending a link reconfiguration request frame.

[0500] Step 2460 may be implemented as an independent embodiment, for example, as a method for sending a link reconfiguration response frame.

[0501] Step 2461 may be implemented as an independent embodiment, for example, implemented separately as a method for sending a link reconfiguration response frame.

[0502] In summary, the method provided in this embodiment optimizes the link reconfiguration protocol between the current AP MLD and the target AP MLD at different locations by sending and / or receiving a link reconfiguration request frame and a link reconfiguration response frame. The link reconfiguration request frame and the link reconfiguration response frame are used to implement switching between the current AP MLD and the target AP MLD at different locations based on link reconfiguration, thereby implementing switching of the non-AP MLD between the current AP MLD and the target AP MLD during communication.

[0503] The method provided in this embodiment also sends an FT acknowledgment frame to indicate the copying or migration of the block acknowledgment protocol context and security association context. This eliminates the time during which data connectivity between the non-AP MLD, the current AP MLD, and the target AP MLD is lost, thereby maintaining data continuity between the non-AP MLD, the current AP MLD, and the target AP MLD. The block acknowledgment protocol context ensures data transmission connectivity, and the security association context eliminates the need for key renegotiation after handover by omitting the key negotiation process.

[0504] FIG25 shows a flowchart of a handover method provided by an exemplary embodiment of the present application. The method is performed by a non-AP MLD 410, a current AP MLD 420, and a target AP MLD 430. The non-AP MLD 410 is a FT Originator (FTO), the current AP MLD 420 and the target AP MLD 430 are FT Responders (FTR), and the current AP MLD 420 and the target AP MLD 430 belong to the same mobility domain MLD 400. The method includes:

[0505] Step 2510 : The non-AP MLD 410 sends an authentication request frame to the current AP MLD 420 .

[0506] When the non-AP MLD 410 determines that the data information needs to be transmitted to the current AP MLD 420 , step 2510 is executed.

[0507] The Authentication-Request frame is an Authentication frame whose Authentication Transaction Sequence Number field value is 1.

[0508] Step 2520 : The current AP MLD 420 sends an authentication response frame to the non-AP MLD 410 .

[0509] When receiving the authentication request frame sent by the non-AP MLD 410 , the current AP MLD 420 feeds back an authentication response frame. The authentication response (Authentication-Response) frame is an authentication frame with an authentication transaction sequence number field value of 2.

[0510] Step 2530 : The non-AP MLD 410 sends a (re)association request frame to the current AP MLD 420 .

[0511] In some embodiments, the non-AP MLD 410 associates with the current AP MLD 420 and performs mobility domain MLD scenario association or FT-initial mobility domain MLD scenario association.

[0512] The association is successful when the association request frame is sent for the first time, or when the time between the authentication request frame and the reassociation request frame exceeds the reassociation deadline.

[0513] If the time between the authentication request frame and the reassociation request frame does not exceed the reassociation deadline, the reassociation is successfully performed.

[0514] The (re)association request frame includes at least one of the following: an MDE (FTinMobileDomainMLD field, a mobile domain MLD information field) and a basic multilink element. The (re)association request frame carries the MDE, instructing the non-AP MLD 410 to associate with the AP MLD in the mobile domain MLD 400 scenario (or, the non-AP MLD 410 is associated with the AP MLD affiliated with the mobile domain MLD 400), and indicating support or permission for FT between the current AP MLD 420 and the target AP MLD 430 affiliated with the same mobile domain MLD.

[0515] Step 2540 : The current AP MLD 420 sends a (re)association response frame to the non-AP MLD 410 .

[0516] Upon receiving the (re)association request frame sent by the non-AP MLD 410 , the current AP MLD 420 feeds back a (re)association response frame.

[0517] The (re)association response frame includes at least one of the following: MDE (FTinMobileDomainMLD field, mobile domain MLD information field) and basic multilink element.

[0518] Step 2550 : The non-AP MLD 410 sends an FT request frame to the current AP MLD 420 .

[0519] Step 2551 : The current AP MLD 420 sends an FT request frame to the target AP MLD 430 .

[0520] Step 2560 : The target AP MLD 430 sends an FT response frame to the current AP MLD 420 .

[0521] Step 2561: The current AP MLD 420 sends an FT response frame to the non-AP MLD 410.

[0522] In some embodiments, the non-AP MLD 410 initiates a FT procedure from the current AP MLD 420 to the target AP MLD 430 in a mobility-domain MLD scenario.

[0523] Steps 2550 to 2561 refer to steps 2410 to 2421 of the embodiment of FIG. 24 and are not described again here.

[0524] Step 2570 : The non-AP MLD 410 sends an FT confirmation frame to the current AP MLD 420 .

[0525] In some embodiments, for the non-AP MLD 410 , the context and state of the mobility domain MLD, and / or all or part of the context, state, and buffer of the mobility domain MLD's corresponding subordinate MLDs are copied or migrated from the current AP MLD 420 to the target AP MLD 430 .

[0526] In some embodiments, the FT ACK frame includes at least one of the following: non-AP MLD information, target AP MLD information, MDE, Block ACK protocol context element, security association context element, and basic multilink element.

[0527] The FT acknowledgment frame carries a block acknowledgment protocol context element and a security association context element, indicating related block acknowledgment protocol context (or state) information and security association context (or state) information.

[0528] In some embodiments, the FT confirmation frame requests synchronization of the block confirmation protocol context and the security association context. The block confirmation protocol context is used to ensure connectivity of data transmission, and the security association context is used to omit the key negotiation process so that the key does not need to be renegotiated after switching.

[0529] Step 2571 : The current AP MLD 420 sends an FT confirmation frame to the target AP MLD 430 .

[0530] In some embodiments, after receiving the FT acknowledgment frame sent by the non-AP MLD 410, the current AP MLD 420 adds relevant information of the block acknowledgment protocol context and the security association context to the block acknowledgment protocol context element and the security association context element based on the request of the FT acknowledgment frame, and then sends the information to the target AP MLD 430, thereby copying or migrating the block acknowledgment protocol context and the security association context to the target AP MLD 430.

[0531] Step 2580 : The target AP MLD 430 sends an FT response frame to the current AP MLD 420 .

[0532] In some embodiments, after receiving the FT ACK frame, the target AP MLD 430 copies or migrates the block ACK protocol context and the security association context.

[0533] In some embodiments, the target AP MLD 430 generates an FT response frame. The block acknowledgment protocol context element and security association context element in the FT response frame respectively provide feedback on whether the copying result or migration result of the block acknowledgment protocol context and security association context is successful.

[0534] Step 2581: The current AP MLD 420 sends an FT response frame to the non-AP MLD 410.

[0535] In some embodiments, the FT response frame feedback block confirms that the copying result or the migration result of the protocol context and the security association context are all successful, and the current AP MLD 420 sends the FT response frame to the non-AP MLD 410 .

[0536] In some embodiments, the FT response frame feedback block confirms that the copying result or migration result of the protocol context and security association context is partially or completely unsuccessful, and the target AP MLD 430 resends the FT response frame to the current AP MLD 420 until the copying result or migration result is completely successful.

[0537] Step 2590 : The non-AP MLD 410 sends a link reconfiguration request frame to the current AP MLD 420 .

[0538] A successful link reconfiguration occurs only if the duration between the FT request frame sending time and the link reconfiguration request frame sending time does not exceed the link reconfiguration deadline.

[0539] In some embodiments, link reconfiguration is performed based on the non-AP MLD 410 in the mobility domain MLD scenario and the current AP MLD 420 and target AP MLD 430 to which the mobility domain MLD is affiliated.

[0540] In some embodiments, the link reconfiguration request frame includes at least one of the following: MDE (FTinMobileDomainMLD field, mobile domain MLD information field), reconfiguration multilink element of current AP MLD (RME for CurrentAPMLD), reconfiguration multilink element of target AP MLD (RME for TargetAPMLD), operation channel information element (OCI), and flow identifier to link mapping element.

[0541] The link reconfiguration request frame carries the MDE, instructing the non-AP MLD to request, in the mobility domain MLD scenario, link reconfiguration based on the existing multi-links in the current AP MLD and target AP MLD attached to the mobility domain MLD. This request involves adding links or deleting links from the existing multi-links. For FT-oriented link reconfiguration, the request is to delete all existing links from the existing multi-links in the current AP MLD attached to the mobility domain MLD and to create one or more new links in the target AP MLD attached to the mobility domain MLD.

[0542] The link reconfiguration request frame carries the Reconfiguration Multilink Element for CurrentAPMLD and the Reconfiguration Multilink Element for TargetAPMLD, which respectively describe the non-AP MLD request and the reconfiguration multilink information of the current AP MLD and the target AP MLD.

[0543] Optionally, the link reconfiguration request frame carries one or two flow identifier to link mapping elements, provides flow identifier to link mapping information, and instructs to perform a corresponding flow identifier to link mapping request on the link established by the target AP MLD request.

[0544] Step 2591 : The current AP MLD 420 sends a link reconfiguration request frame to the target AP MLD 430 .

[0545] In some embodiments, after the current AP MLD 420 receives the link reconfiguration request frame sent by the non-AP MLD 410, it performs link reconfiguration according to the reconfiguration multilink element (RME for CurrentAPMLD) of the current AP MLD in the link reconfiguration request frame, for example, deleting all links between it and the non-AP MLD 410.

[0546] In some embodiments, after receiving the link reconfiguration request frame sent by the current AP MLD 420 , the target AP MLD 430 performs link reconfiguration according to the reconfiguration multilink element (RME for TargetAPMLD) of the target AP MLD in the link reconfiguration request frame, for example, creates one or more links.

[0547] Step 25100 : The target AP MLD 430 sends a link reconfiguration response frame to the current AP MLD 420 .

[0548] In some embodiments, the link reconfiguration response frame includes at least one of the following: MDE (FTinMobileDomainMLD field, mobile domain MLD information field), reconfiguration status list of current AP MLD (Reconfiguration Status List for target AP MLD), reconfiguration status list of target AP MLD (Reconfiguration Status List for target AP MLD), group key data, operation channel information element (OCI), basic multilink element, and flow identifier to link mapping element.

[0549] The link reconfiguration response frame carries the MDE, indicating that the link reconfiguration response frame is a response to a link reconfiguration request frame containing the MDE, that is, a response to a link reconfiguration request based on established multiple links in the current AP MLD and the target AP MLD attached to the mobility domain MLD in the mobility domain MLD scenario.

[0550] The link reconfiguration response frame carries link reconfiguration status code information (ie, status code field), indicating the status code of link reconfiguration in the mobility domain MLD scenario.

[0551] If the status code indicates "reject mobility domain link reconfiguration", the link reconfiguration response frame does not include the reconfiguration state list information (ie, the number of reconfiguration state tuples and the reconfiguration state list) of the link reconfiguration between the current AP MLD and the target AP MLD.

[0552] If the link reconfiguration status code information carried in the link reconfiguration response frame indicates "SUCCESS," the link reconfiguration response frame also carries reconfiguration status list information for the link reconfiguration between the current AP MLD and the target AP MLD, indicating the number of reconfiguration status tuples and the reconfiguration status list in the reconfiguration status list for the link reconfiguration between the current AP MLD and the target AP MLD. In the link reconfiguration response frame, the current AP MLD and the target AP MLD each contain a reconfiguration status tuple field for each link ID indicated in the STA-granularity profile (Per-STA Profile) field of the corresponding link reconfiguration request frame.

[0553] For the reconfiguration status information of the current AP MLD, if the current AP MLD accepts the delete link request for the link ID, the corresponding status field in the reconfiguration status tuple field is set to "SUCCESS". For the reconfiguration status information of the target AP MLD, if the target AP MLD accepts the add link request for the corresponding link ID, the corresponding status field should be set to "SUCCESS" in the reconfiguration status tuple field, and the status code field contained in the STA-granularity profile field for the link ID in the carried basic multilink element should indicate "SUCCESS".

[0554] The Link Reconfiguration Response frame carries a Basic Multilink Element for the target AP MLD, which is used to provide STA-granular profile information for one or more subordinate APs of the target AP MLD. If the target AP MLD accepts the Link Add Request for one or more links, it shall include a Basic Multilink Element in the Link Reconfiguration Response frame, which contains one STA-granular profile information for each subordinate AP corresponding to the link that the target AP MLD accepts for addition to the non-AP MLD.

[0555] If the Link Reconfiguration Status Code information carried in the Link Reconfiguration Response frame indicates "SUCCESS," meaning the target AP MLD accepts the request to add one or more links, the current AP MLD and the target AP MLD should include the Group Key Data field in the Link Reconfiguration Response frame. For each link added by the target AP MLD, the current AP MLD and the target AP MLD should include an MLO GTK KDE, an MLO IGTK KDE, and an MLO BIGTK KDE in the Group Key Data field, providing the group key identified by the Link ID field for the link added by the target AP MLD.

[0556] Optionally, the link reconfiguration response frame further includes one or two flow identifier to link mapping elements, or does not include a flow identifier to link mapping element, to respond to a received link reconfiguration request frame that carries or does not carry a flow identifier to link mapping element, indicating the result of flow identifier to link mapping performed by the non-AP MLD and the target AP MLD on the established link. The rules for the target AP MLD and the non-AP MLD to perform flow identifier to link mapping on the established link, and the manner in which the link reconfiguration response frame indicates the result of the flow identifier to link mapping in response to a link reconfiguration request frame that carries or does not carry a flow identifier to link mapping element, are consistent with the manner in which the target AP MLD sends an association response frame in response to a received association request frame that carries or does not carry a flow identifier to link mapping element and indicates the result of the flow identifier to link mapping.

[0557] In some embodiments, the target AP MLD 430 generates a link reconfiguration response frame, which includes a reconfiguration status list of the target AP MLD, indicating the link reconfiguration status of the target AP MLD 430 , for example, indicating that the target AP MLD 430 has successfully added one or more links.

[0558] Step 25101: The current AP MLD 420 sends a link reconfiguration response frame to the non-AP MLD 410.

[0559] In some embodiments, after receiving the link reconfiguration response frame sent by the target AP MLD 430, the current AP MLD 420 modifies the reconfiguration status list field of the current AP MLD in the link reconfiguration response frame. The reconfiguration status list field of the current AP MLD is used to indicate the reconfiguration status of the current AP MLD. For example, the field is modified to indicate that all links with the non-AP MLD 410 have been successfully deleted.

[0560] In some embodiments, after receiving the link reconfiguration response frame sent by the target AP MLD 430, the current AP MLD 420 adds a reconfiguration status list field of the current AP MLD to the link reconfiguration response frame. The reconfiguration status list field of the current AP MLD is used to indicate the reconfiguration status of the current AP MLD. For example, adding this field indicates that all links with the non-AP MLD 410 have been successfully deleted.

[0561] In this embodiment, steps 2510 to 2540 are optional, steps 2550 to 2561 are optional, and steps 2570 to 2581 are optional. In different embodiments, these steps may be omitted or replaced, for example, steps 2510 to 2581 may be omitted and execution may start from step 2590.

[0562] Steps 2510 to 2540 may be implemented as independent embodiments, steps 2550 to 2561 may be implemented as independent embodiments, steps 2570 to 2581 may be implemented as independent embodiments, and steps 2590 to 25101 may be implemented as independent embodiments, but are not limited thereto.

[0563] Step 2510 may be implemented as an independent embodiment, for example, as a method for sending an authentication request frame.

[0564] Step 2520 may be implemented as an independent embodiment, for example, as a method for sending an authentication response frame.

[0565] Step 2530 may be implemented as an independent embodiment, for example, as a method for sending a (re)association request frame.

[0566] Step 2540 may be implemented as an independent embodiment, for example, as a method for sending a (re)association response frame.

[0567] Step 2550 may be implemented as an independent embodiment, such as being implemented separately as a method for sending an FT request frame;

[0568] Step 2551 may be implemented as an independent embodiment, for example, as a method for sending an FT request frame.

[0569] Step 2560 may be implemented as an independent embodiment, for example, as a method for sending an FT response frame.

[0570] Step 2561 may be implemented as an independent embodiment, for example, as a method for sending an FT response frame.

[0571] Step 2570 may be implemented as an independent embodiment, for example, as a method for sending an FT confirmation frame.

[0572] Step 2571 may be implemented as an independent embodiment, for example, as a method for sending an FT confirmation frame.

[0573] Step 2580 may be implemented as an independent embodiment, for example, as a method for sending an FT response frame.

[0574] Step 2581 may be implemented as an independent embodiment, for example, as a method for sending an FT response frame.

[0575] Step 2590 may be implemented as an independent embodiment, for example, as a method for sending a link reconfiguration request frame.

[0576] Step 2591 may be implemented as an independent embodiment, for example, as a method for sending a link reconfiguration request frame.

[0577] Step 25100 may be implemented as an independent embodiment, for example, implemented separately as a method for sending a link reconfiguration response frame;

[0578] Step 25101 may be implemented as an independent embodiment, for example, implemented separately as a method for sending a link reconfiguration response frame.

[0579] In summary, the method provided in this embodiment optimizes the link reconfiguration protocol between the current AP MLD and the target AP MLD at different locations by sending and / or receiving a link reconfiguration request frame and a link reconfiguration response frame. The link reconfiguration request frame and the link reconfiguration response frame are used to implement switching between the current AP MLD and the target AP MLD at different locations based on link reconfiguration, thereby implementing switching of the non-AP MLD between the current AP MLD and the target AP MLD during communication.

[0580] The method provided in this embodiment also sends an FT acknowledgment frame to indicate the copying or migration of the block acknowledgment protocol context and security association context. This eliminates the time during which data connectivity between the non-AP MLD, the current AP MLD, and the target AP MLD is lost, thereby maintaining data continuity between the non-AP MLD, the current AP MLD, and the target AP MLD. The block acknowledgment protocol context ensures data transmission connectivity, and the security association context eliminates the need for key renegotiation after handover by omitting the key negotiation process.

[0581] The method provided in this embodiment further ensures that the copying or migration of the context information is successful by repeatedly sending FT confirmation frames before the copying result or migration result indicates success.

[0582] In the above embodiments, the descriptions of steps 401 to 404 of the embodiment of FIG. 4 , step 510 of the embodiment of FIG. 5 , steps 2330 to 2341 of the embodiment of FIG. 23 , steps 2450 to 2460 of the embodiment of FIG. 24 , and steps 2590 to 25101 of the embodiment of FIG. 25 may correspond to each other.

[0583] The descriptions of step 510 of the embodiment of Figure 5, steps 2310 to 2321 of the embodiment of Figure 23, steps 2410 to 2441 of the embodiment of Figure 24, and steps 2550 to 2581 of the embodiment of Figure 25 can refer to each other one by one.

[0584] The present application provides a link reconfiguration method for converting a non-AP MLD from a current AP MLD to a target AP MLD based on a mobility domain MLD architecture. This method optimizes the link reconfiguration protocol for co-located AP MLDs (i.e., APs to which the AP MLD is attached are all co-located APs) and utilizes replication, migration, or updating of relevant communication context and state to maintain data continuity between STAs and DSs, or between non-AP MLDs and DSs.

[0585] 1. A link reconfiguration method based on the mobility domain MLD architecture is proposed to convert the non-AP MLD from the current AP MLD to the target AP MLD. That is, under the mobility domain MLD architecture, a method and mechanism are used to simultaneously reconfigure the non-AP MLD, the current AP MLD, and the target AP MLD at different locations.

[0586] 2. Proposes the definition and functional updates of the frame types and formats for the FT-oriented link reconfiguration protocol and interaction based on the mobile domain MLD architecture, including: the definition updates of the reconfiguration request frame and reconfiguration response frame, the FT request and response protocol and the FT resource request and response protocol, and the FT acknowledgment frame (FT ACK).

[0587] 3. Propose FT-oriented link reconfiguration rules (i.e., FT-oriented rules for maintaining consistency when performing link reconfiguration simultaneously with the current AP MLD and the target AP MLD), as well as the flow identifier to link mapping method and rules involved.

[0588] FIG26 shows a flowchart of a handover method provided by an exemplary embodiment of the present application. The method is executed by the current AP MLD. The method includes:

[0589] Step 2610: Send and / or receive at least one first frame.

[0590] The at least one first frame is used to implement switching between the non-AP MLD and the current AP MLD and the target AP MLD at different locations based on link reconfiguration.

[0591] In some embodiments, the current AP MLD and the target AP MLD belong to the same mobility domain MLD, or the current AP MLD and the target AP MLD belong to the same mobility domain.

[0592] In some embodiments, the current AP MLD and the target AP MLD belong to the same mobility domain MLD, which is used for at least one of the following:

[0593] Provides connection service between non-AP MLD or current AP MLD and target AP MLD and DS;

[0594] Maintaining data continuity for non-AP MLD switching between the current AP MLD and the target AP MLD during roaming.

[0595] Authentication and / or association or reassociation of non-AP MLD;

[0596] non-AP MLD security associations;

[0597] Distribution of all or part of the security association information of non-AP MLD;

[0598] Synchronize all or part of the state and / or buffer information of the upper layer of the MAC layer above the current AP MLD and the target AP MLD;

[0599] Manage the distribution of authentication information for non-AP MLD links;

[0600] Manages the AP MLD-level association or reassociation between the non-AP MLD and the current AP MLD and the target AP MLD;

[0601] Based on the target AP MLD, the MAC address corresponding to the target AP MLD is selected for data transmission;

[0602] Synchronization of first data between the current AP MLD and the target AP MLD, the first data being used to maintain data communication between the non-AP MLD and the current AP MLD and the target AP MLD or DS;

[0603] MLD-level information is exchanged or indicated via the MAC sublayer of the current AP MLD and the target AP MLD.

[0604] In some embodiments, sending and / or receiving at least one first frame includes:

[0605] Receives a link reconfiguration request frame from the non-AP MLD and sends a link reconfiguration request frame to the target AP MLD. The link reconfiguration request frame indicates that the non-AP MLD requests link reconfiguration with the current AP MLD and the target AP MLD to implement a switchover.

[0606] The link reconfiguration response frame is received from the target AP MLD and sent to the non-AP MLD. The link reconfiguration response frame is used to provide feedback to the non-AP MLD on the link reconfiguration between the current AP MLD and the target AP MLD.

[0607] In some embodiments, the link reconfiguration request frame includes: a first element corresponding to the current AP MLD, for deleting at least one link between the non-AP MLD and the current AP MLD;

[0608] The second element corresponding to the target AP MLD is used to establish at least one link between the non-AP MLD and the target AP MLD.

[0609] In some embodiments, the first element includes a first reconfiguration multilink element for describing reconfiguration multilink information of the non-AP MLD and the current AP MLD;

[0610] The second element includes a second reconfiguration multilink element, which is used to describe the reconfiguration multilink information of the non-AP MLD and the target AP MLD.

[0611] In some embodiments, the link reconfiguration request frame further includes: a first flow identifier to link mapping element, which is used by the non-AP MLD to perform flow identifier to link mapping on the link established between the non-AP MLD and the target AP MLD.

[0612] In some embodiments, the link reconfiguration response frame includes:

[0613] The third element corresponding to the current AP MLD is used to indicate the link reconfiguration status corresponding to the current AP MLD;

[0614] The fourth element corresponding to the target AP MLD is used to indicate the link reconfiguration state corresponding to the target AP MLD.

[0615] In some embodiments, the third element includes at least one of the following: a reconfiguration state list of the current AP MLD, including at least one reconfiguration state tuple; the number of reconfiguration state tuples of the current AP MLD;

[0616] The fourth element includes at least one of the following: a reconfiguration state list of the target AP MLD, including at least one reconfiguration state element; a number of reconfiguration state tuples of the target AP MLD;

[0617] The reconfiguration status element is used to indicate the reconfiguration status of a link.

[0618] In some embodiments, the current AP MLD and the target AP MLD belong to the same mobility domain MLD, or the current AP MLD and the target AP MLD belong to the same mobility domain, the method further includes:

[0619] Send and / or receive first indication information, where the first indication information is used to indicate the mobility domain MLD.

[0620] In some embodiments, the first indication information is carried in at least one of the following frames:

[0621] Link reconfiguration request frame;

[0622] Link reconfiguration response frame;

[0623] Request frame;

[0624] Response frame;

[0625] Fast basic service set BSS switching FT request frame;

[0626] FT response frame;

[0627] FT confirmation frame;

[0628] FT response frame;

[0629] Association request frame;

[0630] Association response frame;

[0631] Reassociation request frame;

[0632] Reassociation response frame;

[0633] The request frame instructs the non-AP MLD to request context replication or migration between the current AP MLD and the target AP MLD to maintain data connectivity during handover. The response frame indicates to the non-AP MLD the result of context replication or migration between the current AP MLD and the target AP MLD.

[0634] In some embodiments, the first indication information includes at least one of the following:

[0635] Mobile domain MLD identifier;

[0636] Mobility domain MLD MAC address.

[0637] In some embodiments, the switching is based on FT, the method further comprising:

[0638] Send and / or receive second indication information, where the second indication information is used to indicate whether to support or allow FT between the current AP MLD and the target AP MLD that are affiliated with the same mobility domain MLD.

[0639] In some embodiments, FT is performed between the current AP MLD and the target AP MLD that are affiliated with the same mobility domain MLD to maintain data connectivity during the handover process.

[0640] In some embodiments, the second indication information is carried in at least one of the following frames:

[0641] Link reconfiguration request frame;

[0642] Link reconfiguration response frame;

[0643] Request frame;

[0644] Response frame;

[0645] FT request frame;

[0646] FT response frame;

[0647] FT confirmation frame;

[0648] FT response frame;

[0649] Association request frame;

[0650] Association response frame;

[0651] Reassociation request frame;

[0652] Reassociation response frame;

[0653] The request frame instructs the non-AP MLD to request context replication or migration between the current AP MLD and the target AP MLD to maintain data connectivity during handover. The response frame indicates to the non-AP MLD the result of context replication or migration between the current AP MLD and the target AP MLD.

[0654] In some embodiments, the link reconfiguration response frame includes a status code, which is used to indicate that the link reconfiguration is performed in a mobility domain MLD scenario.

[0655] In some embodiments, when the value of the status code is the first value, it is used to indicate rejection of mobility domain link reconfiguration.

[0656] In some embodiments, the link reconfiguration response frame includes: group key data, used to indicate the group key successfully added to the link corresponding to the target AP MLD.

[0657] In some embodiments, the link reconfiguration response frame includes a basic multi-link element for providing a STA-granular configuration file for one or more subordinate APs of the target AP MLD.

[0658] In some embodiments, the link reconfiguration response frame includes a second flow identifier to link mapping element, which is used to respond to the non-AP MLD performing flow identifier to link mapping on the link established between the non-AP MLD and the target AP MLD.

[0659] In some embodiments, the link reconfiguration request frame is sent by the non-AP MLD to the current AP MLD, and then sent by the current AP MLD to the target AP MLD.

[0660] In some embodiments, the link reconfiguration response frame is sent from the target AP MLD to the current AP MLD, and then sent from the current AP MLD to the non-AP MLD.

[0661] In some embodiments, the method further includes: sending and / or receiving at least one second frame, where the second frame is used to synchronize context information related to the non-AP MLD between the current AP MLD and the target AP MLD, where the context information includes: at least one of status information and buffer information.

[0662] In some embodiments, sending and / or receiving at least one second frame includes:

[0663] Receives a request frame from the non-AP MLD and sends a request frame to the target AP MLD. The request frame indicates that the non-AP MLD requests synchronization of non-AP MLD-related context information between the current AP MLD and the target AP MLD.

[0664] The target AP MLD receives a response frame and sends a response frame to the non-AP MLD. The response frame is used to feed back to the non-AP MLD the context information related to the non-AP MLD that is synchronized between the current AP MLD and the target AP MLD.

[0665] In some embodiments, the context information includes at least one of the following:

[0666] First context information, the first context information is information related to a block confirmation protocol context;

[0667] The second context information is information related to the security association context.

[0668] In some embodiments, the first context information is carried in a block acknowledgement protocol context element.

[0669] In some embodiments, the block acknowledgement protocol context element includes a block acknowledgement protocol context parameter control field, where the block acknowledgement protocol context parameter control field is used to indicate at least one of the following:

[0670] The device where the Block Acknowledgement Protocol Context element resides;

[0671] Whether the device containing the block acknowledgment protocol context element and the non-AP MLD targeted by the block acknowledgment protocol context are the same device;

[0672] If the device containing the block acknowledgment protocol context element and the non-AP MLD targeted by the block acknowledgment protocol context are the same device, the non-AP MLD targeted by the block acknowledgment protocol context;

[0673] The number of Block Acknowledgement Protocol Context Parameter Sets included in the Block Acknowledgement Protocol Context element.

[0674] In some embodiments, the block confirmation protocol context element includes a block confirmation protocol context parameter set list field, the block confirmation protocol context parameter set list field includes at least one block confirmation protocol context parameter set subfield, and a block confirmation protocol context parameter set subfield is used to indicate a block confirmation protocol context parameter set.

[0675] In some embodiments, the Block ACK Protocol Context Parameter Set subfield is used to indicate at least one of the following:

[0676] The role of the device in the block confirmation protocol context;

[0677] Non-AP MLD for the Block Ack protocol context;

[0678] Block confirmation parameter set;

[0679] Block confirmation timeout value.

[0680] In some embodiments, if the block acknowledgment protocol context parameter set subfield is used to indicate that the role of the device in the block acknowledgment protocol context is an initiator in the block acknowledgment protocol context, the block acknowledgment protocol context parameter set subfield is further used to indicate at least one of the following:

[0681] Send window starting sequence number;

[0682] Send window size.

[0683] In some embodiments, if the block acknowledgment protocol context parameter set subfield is used to indicate that the device in the block acknowledgment protocol context has a role as a receiver in the block acknowledgment protocol context, the block acknowledgment protocol context parameter set subfield is further used to indicate at least one of the following:

[0684] Receive buffer starting sequence number;

[0685] Receive window size;

[0686] Record the starting sequence number of the bitmap;

[0687] Record the maximum sequence number of the bitmap;

[0688] Record the bitmap size.

[0689] In some embodiments, the block confirmation parameter set includes at least one of the following:

[0690] Indication information indicating whether aggregated MAC service data units are supported;

[0691] Block confirmation strategy;

[0692] Flow ID;

[0693] Buffer size.

[0694] In some embodiments, the second context information is carried in a security association context element.

[0695] In some embodiments, the security association context element includes a security association context parameter control field, where the security association context parameter control field is used to indicate at least one of the following:

[0696] The device where the security association context element is located;

[0697] Whether the device containing the security association context element and the non-AP MLD targeted by the security association context are the same device;

[0698] If the device containing the security association context element and the non-AP MLD targeted by the security association context are the same device, the non-AP MLD targeted by the security association context;

[0699] The number of security association context parameter sets included in the security association context element.

[0700] In some embodiments, the security association context element includes a security association context parameter set list field, the security association context parameter set list field includes at least one security association context parameter set subfield, and a security association context parameter set subfield is used to indicate a security association context parameter set.

[0701] In some embodiments, the security association context parameter set subfield is used to indicate at least one of the following:

[0702] The role of the device in the security association context;

[0703] The non-AP MLD for the security association context;

[0704] The security association type of the security association context.

[0705] In some embodiments, the full association context parameter set subfield is used to indicate that the role of the device where the security association context resides in the security association context is an initiator; the security association context parameter set subfield is further used to indicate at least one of the following:

[0706] Replay counter number;

[0707] TID;

[0708] The count of the replay counter for the TID.

[0709] In some embodiments, if the security association context parameter set subfield is used to indicate that the role of the device where the security association context resides in the security association context is a receiver, the security association context parameter set subfield is further used to indicate at least one of the following:

[0710] Packet number counter quantity;

[0711] TID;

[0712] The count of the packet number counter for the TID.

[0713] In some embodiments, the second frame further includes:

[0714] The third indication information is used to indicate that the context information includes information about a block acknowledgement protocol context and / or a security association context.

[0715] In some embodiments, the request frame is sent by the non-AP MLD to the current AP MLD, and then sent by the current AP MLD to the target AP MLD;

[0716] The response frame is sent from the target AP MLD to the current AP MLD, and then from the current AP MLD to the non-AP MLD.

[0717] In some embodiments, the switching is based on FT, the request frame is a FT confirmation frame, and the response frame is a FT acknowledgement frame.

[0718] In some embodiments, the current AP MLD and the target AP MLD belong to the same mobility domain MLD, and the method further includes:

[0719] Receive FT request frames from non-AP MLDs and send FT request frames to target AP MLDs.

[0720] Receives FT response frames from the target AP MLD and sends FT response frames to the non-AP MLD.

[0721] In some embodiments, the method further comprises: receiving an association request frame sent by a non-AP MLD, and sending an association request frame to a target AP MLD;

[0722] Receives association response frames from the target AP MLD and sends association response frames to the non-AP MLD.

[0723] In some embodiments, the switching is based on the FT, and if the first duration is less than or equal to the deadline for link reconfiguration, the link reconfiguration is performed by the non-AP MLD;

[0724] The first duration represents the duration between the sending time of the FT request frame and the sending time of the link reconfiguration request frame, and the first frame includes the link reconfiguration request frame.

[0725] In some embodiments, the method further includes: receiving fourth indication information, where the fourth indication information is used to indicate a deadline or timeout period for link reconfiguration.

[0726] In some embodiments, the fourth indication information is indicated by a start time and a timeout interval, or,

[0727] The fourth indication information is indicated by a deadline.

[0728] In some embodiments, the start time is implicitly represented by the sending time or receiving time of the fourth indication information;

[0729] The timeout interval is explicitly indicated by the fourth indication information.

[0730] In some embodiments, the method further comprises:

[0731] If the target AP MLD agrees to establish at least one link, the current AP MLD agrees to delete all links.

[0732] When the target AP MLD refuses to establish all links, the current AP MLD refuses to delete at least one link.

[0733] When the target AP MLD rejects all requests to add links (that is, the target AP MLD refuses to establish any link), the current AP MLD should not accept all requests to delete links. That is, the current AP MLD retains at least one established link to maintain the association of the non-AP MLD with the current AP MLD.

[0734] In some embodiments, when the target AP MLD agrees to establish at least one link, the current AP MLD agrees to delete all links except the link required to be retained.

[0735] For FT-oriented link reconfiguration based on the current AP MLD and the target AP MLD, when the target AP MLD accepts at least one link addition request (that is, the target AP MLD agrees to establish at least one link), the current AP MLD should accept all link deletion requests except for links that are required to be retained. In other words, it should reject the deletion of links that are required to be retained, such as links retained as backup links during roaming.

[0736] For the specific implementation details of step 2610, please refer to step 510 of the embodiment of Figure 5, which will not be repeated here.

[0737] In summary, the method provided in this embodiment optimizes the link reconfiguration protocol between the current AP MLD and the target AP MLD at different locations by sending and / or receiving at least one first frame, where the at least one first frame is used to implement switching between the current AP MLD and the target AP MLD at different locations based on link reconfiguration, thereby implementing switching of the non-AP MLD between the current AP MLD and the target AP MLD during the communication process.

[0738] The method provided in this embodiment also eliminates the time during which data connectivity between the non-AP MLD, the current AP MLD, and the target AP MLD is lost by copying or migrating the Block Ack protocol context and the Security Association context, thereby maintaining data continuity between the non-AP MLD, the current AP MLD, and the target AP MLD. The Block Ack protocol context ensures data transmission connectivity, and the Security Association context eliminates the need for renegotiation of keys after handover by omitting the key negotiation process.

[0739] FIG27 shows a flowchart of a handover method provided by an exemplary embodiment of the present application. The method is executed by the target AP MLD. The method includes:

[0740] Step 2710: Send and / or receive at least one first frame.

[0741] The at least one first frame is used to implement switching between the non-AP MLD and the current AP MLD and the target AP MLD at different locations based on link reconfiguration.

[0742] In some embodiments, the current AP MLD and the target AP MLD belong to the same mobility domain MLD, or the current AP MLD and the target AP MLD belong to the same mobility domain.

[0743] In some embodiments, the current AP MLD and the target AP MLD belong to the same mobility domain MLD, which is used for at least one of the following:

[0744] Provides connection service between non-AP MLD or current AP MLD and target AP MLD and DS;

[0745] Maintaining data continuity for non-AP MLD switching between the current AP MLD and the target AP MLD during roaming.

[0746] Authentication and / or association or reassociation of non-AP MLD;

[0747] non-AP MLD security associations;

[0748] Distribution of all or part of the security association information of non-AP MLD;

[0749] Synchronize all or part of the state and / or buffer information of the upper layer of the MAC layer above the current AP MLD and the target AP MLD;

[0750] Manage the distribution of authentication information for non-AP MLD links;

[0751] Manages the AP MLD-level association or reassociation between the non-AP MLD and the current AP MLD and the target AP MLD;

[0752] Based on the target AP MLD, the MAC address corresponding to the target AP MLD is selected for data transmission;

[0753] Synchronization of first data between the current AP MLD and the target AP MLD, the first data being used to maintain data communication between the non-AP MLD and the current AP MLD and the target AP MLD or DS;

[0754] MLD-level information is exchanged or indicated via the MAC sublayer of the current AP MLD and the target AP MLD.

[0755] In some embodiments, sending and / or receiving at least one first frame includes:

[0756] Receive a link reconfiguration request frame sent by the current AP MLD. The link reconfiguration request frame is used to instruct the non-AP MLD to request link reconfiguration with the current AP MLD and the target AP MLD to achieve handover.

[0757] A link reconfiguration response frame is sent to the current AP MLD. The link reconfiguration response frame is used to provide feedback to the non-AP MLD regarding the link reconfiguration performed with the current AP MLD and the target AP MLD.

[0758] In some embodiments, the link reconfiguration request frame includes:

[0759] The first element corresponding to the current AP MLD is used to delete at least one link between the non-AP MLD and the current AP MLD.

[0760] The second element corresponding to the target AP MLD is used to establish at least one link between the non-AP MLD and the target AP MLD.

[0761] In some embodiments, the first element includes a first reconfiguration multilink element for describing reconfiguration multilink information of the non-AP MLD and the current AP MLD;

[0762] The second element includes a second reconfiguration multilink element, which is used to describe the reconfiguration multilink information of the non-AP MLD and the target AP MLD.

[0763] In some embodiments, the link reconfiguration request frame further includes:

[0764] The first flow identifier to link mapping element is used by the non-AP MLD to perform flow identifier to link mapping on the link established between the non-AP MLD and the target AP MLD.

[0765] In some embodiments, the link reconfiguration response frame includes:

[0766] The third element corresponding to the current AP MLD is used to indicate the link reconfiguration status corresponding to the current AP MLD;

[0767] The fourth element corresponding to the target AP MLD is used to indicate the link reconfiguration state corresponding to the target AP MLD.

[0768] In some embodiments, the third element includes at least one of the following: a reconfiguration state list of the current AP MLD, including at least one reconfiguration state tuple; the number of reconfiguration state tuples of the current AP MLD;

[0769] The fourth element includes at least one of the following: a reconfiguration state list of the target AP MLD, including at least one reconfiguration state element; a number of reconfiguration state tuples of the target AP MLD;

[0770] The reconfiguration status element is used to indicate the reconfiguration status of a link.

[0771] In some embodiments, the current AP MLD and the target AP MLD belong to the same mobility domain MLD, or the current AP MLD and the target AP MLD belong to the same mobility domain, the method further includes:

[0772] Send and / or receive first indication information, where the first indication information is used to indicate the mobility domain MLD.

[0773] In some embodiments, the first indication information is carried in at least one of the following frames:

[0774] Link reconfiguration request frame;

[0775] Link reconfiguration response frame;

[0776] Request frame;

[0777] Response frame;

[0778] Fast basic service set BSS switching FT request frame;

[0779] FT response frame;

[0780] FT confirmation frame;

[0781] FT response frame;

[0782] Association request frame;

[0783] Association response frame;

[0784] Reassociation request frame;

[0785] Reassociation response frame;

[0786] The request frame instructs the non-AP MLD to request context replication or migration between the current AP MLD and the target AP MLD to maintain data connectivity during handover. The response frame indicates to the non-AP MLD the result of context replication or migration between the current AP MLD and the target AP MLD.

[0787] In some embodiments, the first indication information includes at least one of the following:

[0788] Mobile domain MLD identifier;

[0789] Mobility domain MLD MAC address.

[0790] In some embodiments, the switching is based on FT, the method further comprising:

[0791] Send and / or receive second indication information, where the second indication information is used to indicate whether to support or allow FT between the current AP MLD and the target AP MLD that are affiliated with the same mobility domain MLD.

[0792] In some embodiments, FT is performed between the current AP MLD and the target AP MLD that are affiliated with the same mobility domain MLD to maintain data connectivity during the handover process.

[0793] In some embodiments, the second indication information is carried in at least one of the following frames:

[0794] Link reconfiguration request frame;

[0795] Link reconfiguration response frame;

[0796] Request frame;

[0797] Response frame;

[0798] FT request frame;

[0799] FT response frame;

[0800] FT confirmation frame;

[0801] FT response frame;

[0802] Association request frame;

[0803] Association response frame;

[0804] Reassociation request frame;

[0805] Reassociation response frame;

[0806] The request frame instructs the non-AP MLD to request context replication or migration between the current AP MLD and the target AP MLD to maintain data connectivity during handover. The response frame indicates to the non-AP MLD the result of context replication or migration between the current AP MLD and the target AP MLD.

[0807] In some embodiments, the link reconfiguration response frame includes a status code, which is used to indicate that the link reconfiguration is performed in a mobility domain MLD scenario.

[0808] In some embodiments, when the value of the status code is the first value, it is used to indicate rejection of mobility domain link reconfiguration.

[0809] In some embodiments, the link reconfiguration response frame includes: group key data, used to indicate the group key successfully added to the link corresponding to the target AP MLD.

[0810] In some embodiments, the link reconfiguration response frame includes a basic multi-link element for providing a STA-granular configuration file for one or more subordinate APs of the target AP MLD.

[0811] In some embodiments, the link reconfiguration response frame includes:

[0812] The second flow identifier to link mapping element is used to respond to the non-AP MLD performing flow identifier to link mapping on the link established between the non-AP MLD and the target AP MLD.

[0813] In some embodiments, the link reconfiguration request frame is sent by the non-AP MLD to the current AP MLD, and then sent by the current AP MLD to the target AP MLD.

[0814] In some embodiments, the link reconfiguration response frame is sent from the target AP MLD to the current AP MLD, and then sent from the current AP MLD to the non-AP MLD.

[0815] In some embodiments, the method further includes: sending and / or receiving at least one second frame, where the second frame is used to synchronize context information related to the non-AP MLD between the current AP MLD and the target AP MLD, where the context information includes: at least one of status information and buffer information.

[0816] In some embodiments, sending and / or receiving at least one second frame includes:

[0817] Receive a request frame sent by the current AP MLD, where the request frame is used to indicate that the non-AP MLD requests synchronization of context information related to the non-AP MLD between the current AP MLD and the target AP MLD;

[0818] A response frame is sent to the current AP MLD. The response frame is used to feed back to the non-AP MLD the context information related to the synchronization between the current AP MLD and the target AP MLD.

[0819] In some embodiments, the context information includes at least one of the following:

[0820] First context information, the first context information is information related to a block confirmation protocol context;

[0821] The second context information is information related to the security association context.

[0822] In some embodiments, the first context information is carried in a block acknowledgement protocol context element.

[0823] In some embodiments, the block acknowledgement protocol context element includes a block acknowledgement protocol context parameter control field, where the block acknowledgement protocol context parameter control field is used to indicate at least one of the following:

[0824] The device where the Block Acknowledgement Protocol Context element resides;

[0825] Whether the device containing the block acknowledgment protocol context element and the non-AP MLD targeted by the block acknowledgment protocol context are the same device;

[0826] If the device containing the block acknowledgment protocol context element and the non-AP MLD targeted by the block acknowledgment protocol context are the same device, the non-AP MLD targeted by the block acknowledgment protocol context;

[0827] The number of Block Acknowledgement Protocol Context Parameter Sets included in the Block Acknowledgement Protocol Context element.

[0828] In some embodiments, the block confirmation protocol context element includes a block confirmation protocol context parameter set list field, the block confirmation protocol context parameter set list field includes at least one block confirmation protocol context parameter set subfield, and a block confirmation protocol context parameter set subfield is used to indicate a block confirmation protocol context parameter set.

[0829] In some embodiments, the Block ACK Protocol Context Parameter Set subfield is used to indicate at least one of the following:

[0830] The role of the device in the block confirmation protocol context;

[0831] Non-AP MLD for the Block Ack protocol context;

[0832] Block confirmation parameter set;

[0833] Block confirmation timeout value.

[0834] In some embodiments, if the block acknowledgment protocol context parameter set subfield is used to indicate that the role of the device in the block acknowledgment protocol context is an initiator in the block acknowledgment protocol context, the block acknowledgment protocol context parameter set subfield is further used to indicate at least one of the following:

[0835] Send window starting sequence number;

[0836] Send window size.

[0837] In some embodiments, if the block acknowledgment protocol context parameter set subfield is used to indicate that the device in the block acknowledgment protocol context has a role as a receiver in the block acknowledgment protocol context, the block acknowledgment protocol context parameter set subfield is further used to indicate at least one of the following:

[0838] Receive buffer starting sequence number;

[0839] Receive window size;

[0840] Record the starting sequence number of the bitmap;

[0841] Record the maximum sequence number of the bitmap;

[0842] Record the bitmap size.

[0843] In some embodiments, the block confirmation parameter set includes at least one of the following:

[0844] Indication information indicating whether aggregated MAC service data units are supported;

[0845] Block confirmation strategy;

[0846] Flow ID;

[0847] Buffer size.

[0848] In some embodiments, the second context information is carried in a security association context element.

[0849] In some embodiments, the security association context element includes a security association context parameter control field, where the security association context parameter control field is used to indicate at least one of the following:

[0850] The device where the security association context element is located;

[0851] Whether the device containing the security association context element and the non-AP MLD targeted by the security association context are the same device;

[0852] If the device containing the security association context element and the non-AP MLD targeted by the security association context are the same device, the non-AP MLD targeted by the security association context;

[0853] The number of security association context parameter sets included in the security association context element.

[0854] In some embodiments, the security association context element includes a security association context parameter set list field, the security association context parameter set list field includes at least one security association context parameter set subfield, and a security association context parameter set subfield is used to indicate a security association context parameter set.

[0855] In some embodiments, the security association context parameter set subfield is used to indicate at least one of the following:

[0856] The role of the device in the security association context;

[0857] The non-AP MLD for the security association context;

[0858] The security association type of the security association context.

[0859] In some embodiments, the full association context parameter set subfield is used to indicate that the role of the device where the security association context resides in the security association context is an initiator; the security association context parameter set subfield is further used to indicate at least one of the following:

[0860] Replay counter number;

[0861] TID;

[0862] The count of the replay counter for the TID.

[0863] In some embodiments, if the security association context parameter set subfield is used to indicate that the role of the device where the security association context resides in the security association context is a receiver, the security association context parameter set subfield is further used to indicate at least one of the following:

[0864] Packet number counter quantity;

[0865] TID;

[0866] The count of the packet number counter for the TID.

[0867] In some embodiments, the second frame further includes:

[0868] The third indication information is used to indicate that the context information includes information about a block acknowledgement protocol context and / or a security association context.

[0869] In some embodiments, the request frame is sent by the non-AP MLD to the current AP MLD, and then sent by the current AP MLD to the target AP MLD;

[0870] The response frame is sent from the target AP MLD to the current AP MLD, and then from the current AP MLD to the non-AP MLD.

[0871] In some embodiments, the switching is based on FT, the request frame is a FT confirmation frame, and the response frame is a FT acknowledgement frame.

[0872] In some embodiments, the current AP MLD and the target AP MLD belong to the same mobility domain MLD, and the method further includes:

[0873] Receive the FT request frame sent by the current AP MLD;

[0874] Sends an FT response frame to the current AP MLD.

[0875] In some embodiments, the method further comprises:

[0876] Receive the association request frame sent by the current AP MLD;

[0877] Sends an association response frame to the current AP MLD.

[0878] In some embodiments, the switching is based on FT,

[0879] If the first duration is less than or equal to the link reconfiguration deadline, the link reconfiguration is performed by the non-AP MLD.

[0880] The first duration represents the duration between the sending time of the FT request frame and the sending time of the link reconfiguration request frame, and the first frame includes the link reconfiguration request frame.

[0881] In some embodiments, the method further includes: receiving fourth indication information, where the fourth indication information is used to indicate a deadline or timeout period for link reconfiguration.

[0882] In some embodiments, the fourth indication information is indicated by a start time and a timeout interval, or,

[0883] The fourth indication information is indicated by a deadline.

[0884] In some embodiments, the start time is implicitly represented by the sending time or receiving time of the fourth indication information;

[0885] The timeout interval is explicitly indicated by the fourth indication information.

[0886] For the specific implementation details of step 2710, please refer to step 510 of the embodiment of Figure 5, and will not be repeated here.

[0887] In summary, the method provided in this embodiment optimizes the link reconfiguration protocol between the current AP MLD and the target AP MLD at different locations by sending and / or receiving at least one first frame, where the at least one first frame is used to implement switching between the current AP MLD and the target AP MLD at different locations based on link reconfiguration, thereby implementing switching of the non-AP MLD between the current AP MLD and the target AP MLD during the communication process.

[0888] The method provided in this embodiment also eliminates the time during which data connectivity between the non-AP MLD, the current AP MLD, and the target AP MLD is lost by copying or migrating the Block Ack protocol context and the Security Association context, thereby maintaining data continuity between the non-AP MLD, the current AP MLD, and the target AP MLD. The Block Ack protocol context ensures data transmission connectivity, and the Security Association context eliminates the need for renegotiation of keys after handover by omitting the key negotiation process.

[0889] In the above embodiments, steps with the same sequence number can be considered to be the same step. Among them, the embodiment corresponding to Figure 4, the embodiment corresponding to Figure 5, the embodiment corresponding to Figure 23, the embodiment corresponding to Figure 24, the embodiment corresponding to Figure 25, the embodiment corresponding to Figure 26, and the embodiment corresponding to Figure 27 can be implemented separately or in combination, and this application does not limit this.

[0890] FIG28 shows a block diagram of a non-access point multi-link apparatus provided by an exemplary embodiment of the present application. The apparatus can be implemented as a non-access point multi-link device, or as a part of a non-access point multi-link device, through software or hardware, or a combination of both. The apparatus includes a transmission module 2810, wherein the functions of the transmission module 2810 are implemented by a receiver or a transmitter in the non-access point multi-link device.

[0891] The transmission module 2810 is configured to send and / or receive at least one first frame, where the at least one first frame is used to implement switching between two access point multi-link devices at different locations based on link reconfiguration.

[0892] In a possible design of this embodiment, the two access point multi-link devices belong to the same mobility domain MLD, or the two access point multi-link devices belong to the same mobility domain.

[0893] The mobility domain MLD, or logical access point multi-link device, treats multiple access point multi-link devices that are not in the same location as one MLD. This embodiment does not limit the specific name of the mobility domain MLD.

[0894] In a possible design of this embodiment, the non-access point multi-link device switches between two access point multi-link devices, including at least one of the following scenarios:

[0895] Handover scenario 1: When a non-access point multi-link device is associated with a mobility domain MLD, and two access point multi-link devices belong to the same mobility domain MLD, the non-access point multi-link device performs a handover of the access point multi-link device-level association to the mobility domain MLD between the two access point multi-link devices;

[0896] Handover scenario 2: When the non-access point multi-link device is associated with only one of the two access point multi-link devices, and the two access point multi-link devices are not affiliated with the same mobility domain MLD, the non-access point multi-link device performs association handover between the two access point multi-link devices.

[0897] The switching (transition) in the embodiment of the present application can also be replaced by describing as conversion.

[0898] For handover scenario 1, handover of the access point multi-link device-level association to the mobility domain MLD means that before the handover, the non-access point multi-link device is associated with the mobility domain MLD, and the non-access point multi-link device establishes a multi-link with an access point multi-link device affiliated with the mobility domain MLD (i.e., all or part of the link established between the non-access point multi-link device and the mobility domain MLD belongs to the link between the non-access point multi-link device and the access point multi-link device affiliated with the mobility domain MLD). After the handover, the non-access point multi-link device is still associated with the mobility domain MLD, and the non-access point multi-link device establishes a multi-link with another access point multi-link device affiliated with the mobility domain MLD (i.e., all or part of the link established between the non-access point multi-link device and the mobility domain MLD belongs to the link between the non-access point multi-link device and the other access point multi-link device affiliated with the mobility domain MLD).

[0899] For the second handover scenario, the non-access point multi-link device is associated with an access point multi-link device affiliated with different mobility domain MLDs before and after the handover, thereby performing the associated handover.

[0900] For the mobility domain MLD to which the current access point multi-link device among the two access point multi-link devices belongs, the mobility domain MLD belongs to multiple access point multi-link devices including the current access point multi-link device.

[0901] For the mobility domain MLD to which the target access point multi-link device among the two access point multi-link devices belongs, the mobility domain MLD belongs to multiple access point multi-link devices including the target access point multi-link device.

[0902] The switching provided in the embodiments of the present application may include BSS switching, FT, seamless BSS switching or seamless fast switching.

[0903] In a possible design of this embodiment, the two access point multi-link devices belong to the same mobility domain (MLD), and the mobility domain (MLD) is used for at least one of the following:

[0904] Provides connection services between a non-access point multi-link device or two access point multi-link devices and a DS;

[0905] Maintaining data continuity for non-AP multi-link devices during handover between two AP multi-link devices during roaming;

[0906] Authentication and / or association or reassociation of non-access point multi-link devices;

[0907] Security association for non-access point multi-link devices;

[0908] Distribution of all or part of the security association information for non-access point multi-link devices;

[0909] Synchronize all or part of the status and / or buffer information of the upper layers of the MAC layer of the two access point multi-link devices;

[0910] Manage the distribution of authentication information for non-access point multi-link device links;

[0911] Managing access point multi-link device-level association or re-association between a non-access point multi-link device and two access point multi-link devices;

[0912] For a target access point multi-link device that establishes a multi-link with a non-access point multi-link device among the two access point multi-link devices, selecting a MAC corresponding to the target access point multi-link device for data transmission;

[0913] Synchronization of first data between the two access point multi-link devices, the first data being used to maintain data communication between the non-access point multi-link device and the two access point multi-link devices or the DS;

[0914] • Device-level information exchange or indication is performed via the MAC sublayer of the two access point multi-link devices.

[0915] In one possible design of this embodiment, the transmission module 2810 is configured to send a link reconfiguration request frame, where the link reconfiguration request frame is used to instruct a non-access point multi-link device to request link reconfiguration with two access point multi-link devices to implement handover;

[0916] A link reconfiguration response frame is received, where the link reconfiguration response frame is used to feed back to the non-access point multi-link device the link reconfiguration performed with the two access point multi-link devices.

[0917] In a possible design of this embodiment, the two access point multi-link devices include a current access point multi-link device and a target access point multi-link device. The link reconfiguration request frame is sent by the non-access point multi-link device to the current access point multi-link device, and is then sent by the current access point multi-link device to the target access point multi-link device.

[0918] In a possible design of this embodiment, the two access point multi-link devices include a current access point multi-link device and a target access point multi-link device. The link reconfiguration response frame is sent by the target access point multi-link device to the current access point multi-link device, and then fed back by the current access point multi-link device.

[0919] When a non-access point multi-link device needs to switch from communicating with a current access point multi-link device to communicating with a target access point multi-link device, the non-access point multi-link device sends a link reconfiguration request frame to the current access point multi-link device, where the link reconfiguration request frame is used to request deletion of at least one link between the non-access point multi-link device and the current access point multi-link device; and the current access point multi-link device sends a link reconfiguration request frame to the target access point multi-link device, where the link reconfiguration request frame is used to request establishment of at least one link between the non-access point multi-link device and the target access point multi-link device.

[0920] The target access point multi-link device sends a link reconfiguration response frame to the current access point multi-link device. The link reconfiguration response frame is used to indicate the link reconfiguration status corresponding to the target access point multi-link device, such as whether a link is established with the non-access point multi-link device. The current access point multi-link device sends a link reconfiguration response frame to the non-access point multi-link device. The link reconfiguration response frame is used to indicate the link reconfiguration status corresponding to the current access point multi-link device and the target access point multi-link device, such as whether the current access point multi-link device deletes the link and whether the target access point multi-link device establishes a link with the non-access point multi-link device.

[0921] In one possible design of this embodiment, the two access point multi-link devices include a current access point multi-link device and a target access point multi-link device;

[0922] The link reconfiguration request frame includes:

[0923] A first element corresponding to the current access point multi-link device, used to delete at least one link between the current access point multi-link device and the current access point multi-link device;

[0924] The second element corresponding to the target access point multi-link device is used to establish at least one link with the target access point multi-link device.

[0925] In one possible design of this embodiment, the first element includes a first reconfiguration multi-link element, which is used to describe reconfiguration multi-link information of the non-access point multi-link device and the current access point multi-link device;

[0926] The second element includes a second reconfiguration multi-link element, which is used to describe the reconfiguration multi-link information of the non-access point multi-link device and the target access point multi-link device.

[0927] In a possible design of this embodiment, the link reconfiguration request frame further includes:

[0928] The first flow identifier to link mapping element is used to perform flow identifier to link mapping on the link established with the target access point multi-link device.

[0929] In a possible design of this embodiment, the format of the link reconfiguration request frame is as shown in Table 1 in the embodiment of FIG4 .

[0930] In a possible design of this embodiment, the two access point multi-link devices include a current access point multi-link device and a target access point multi-link device, and the link reconfiguration response frame includes:

[0931] a third element corresponding to the current access point multi-link device, used to indicate a link reconfiguration state corresponding to the current access point multi-link device;

[0932] The fourth element corresponding to the target access point multi-link device is used to indicate a link reconfiguration state corresponding to the target access point multi-link device.

[0933] In one possible design of this embodiment, the third element includes at least one of the following: a reconfiguration state list of the current access point multi-link device, including at least one reconfiguration state tuple; a number of reconfiguration state tuples of the current access point multi-link device;

[0934] The fourth element includes at least one of the following: a reconfiguration state list of the target access point multi-link device, including at least one reconfiguration state element; a number of reconfiguration state tuples of the target access point multi-link device;

[0935] The reconfiguration status element is used to indicate the reconfiguration status of a link.

[0936] In a possible design of this embodiment, the link reconfiguration response frame may be an action frame of protected EHT, UHR, or UHR+ type. The format of the link reconfiguration response frame is shown in Table 2 in the embodiment of FIG4 .

[0937] In a possible design of this embodiment, two access point multi-link devices belong to the same mobility domain MLD, or two access point multi-link devices belong to the same mobility domain, and the transmission module 2810 is further used to send and / or receive first indication information, where the first indication information is used to indicate the mobility domain MLD.

[0938] In a possible design of this embodiment, the first indication information is carried in at least one of the following frames:

[0939] Link reconfiguration request frame;

[0940] Link reconfiguration response frame;

[0941] Request frame;

[0942] Response frame;

[0943] FT request frame;

[0944] FT response frame;

[0945] FT confirmation frame;

[0946] FT response frame;

[0947] Association request frame;

[0948] Association response frame;

[0949] Reassociation request frame;

[0950] Reassociation response frame;

[0951] The request frame is used to instruct the non-access point multi-link device to request the replication or migration of context information between two access point multi-link devices to maintain data connectivity during the handover process, and the response frame is used to indicate to the non-access point multi-link device the result of the replication or migration of context information between the two access point multi-link devices.

[0952] In one possible design of this embodiment, the first indication information includes at least one of the following:

[0953] Mobile domain MLD identifier;

[0954] Mobility domain MLD MAC address.

[0955] Exemplarily, the first indication information is called a Mobility Domain Element (MDE), which is used to indicate link reconfiguration in a mobility domain MLD scenario and carries information such as mobility domain MLD information (e.g., a mobility domain MLD identifier or a MAC address of the mobility domain MLD), whether FT is within the same mobility domain MLD, etc. The access point multi-link device can use the MDE to notify that the access point multi-link device is included in or affiliated with a mobility domain MLD, notify the access point multi-link device of its support for the FT function, and notify FT policy information, including whether FT is supported or permitted between two access point multi-link devices affiliated with the same mobility domain MLD.

[0956] In a possible design of this embodiment, the switching is based on FT, and the transmission module 2810 is further configured to send and / or receive second indication information, where the second indication information is used to indicate whether FT is supported or allowed between two access point multi-link devices attached to the same mobility domain MLD.

[0957] Compared with FT between two access point multi-link devices attached to the same mobility domain MLD, FT between two access point multi-link devices is used to maintain data connectivity during handover.

[0958] In a possible design of this embodiment, the second indication information is carried in at least one of the following frames:

[0959] Link reconfiguration request frame;

[0960] Link reconfiguration response frame;

[0961] Request frame;

[0962] Response frame;

[0963] FT request frame;

[0964] FT response frame;

[0965] FT confirmation frame;

[0966] FT response frame;

[0967] Association request frame;

[0968] Association response frame;

[0969] Reassociation request frame;

[0970] Reassociation response frame;

[0971] The request frame is used to instruct the non-access point multi-link device to request the replication or migration of context information between two access point multi-link devices to maintain data connectivity during the handover process, and the response frame is used to indicate to the non-access point multi-link device the result of the replication or migration of context information between the two access point multi-link devices.

[0972] In one possible design of this embodiment, based on the mobility domain MLD architecture, a high-level system architecture of the mobility domain MLD and its subordinate access point multi-link devices and non-access point multi-link devices for switching a non-access point multi-link device (or STA) for data connectivity from a current access point multi-link device (or AP) to a target access point multi-link device (or AP) is shown in FIG6 .

[0973] The high-level system architecture includes at least one of the following: DS610, mobile domain MLD general sublayer 620, first switching module 630, auxiliary MLD upper MAC sublayer 640, auxiliary MLD lower MAC sublayer 650, second switching module 660, non-access point multi-link device lower MAC sublayer 670, non-access point multi-link device upper MAC sublayer 680.

[0974] The DS610 is an architecture for distributing computing and communication functions across multiple nodes or devices. The primary function of the DS is to coordinate and manage computing and communication tasks in a distributed environment to achieve efficient data transmission and collaboration.

[0975] The mobility domain MLD general sublayer 620 includes a mobility domain access point multi-link device 621 . The mobility domain access point multi-link device 621 has an MLD MAC address of Q and performs data communication with the DS 610 through a first MAC-Service Access Point (SAP).

[0976] Access point multi-link device 1 with an MLD MAC address of M and access point multi-link device 2 with an MLD MAC address of N have the same functions. Access point multi-link device 1 is used as an example for description. Mobility domain access point multi-link device 621 communicates data with access point multi-link device 1 via first switching module 630. First switching module 630 is a module within mobility domain access point multi-link device 621, a module within access point multi-link device 1, or a module within another access point multi-link device.

[0977] Access point multi-link device 1 communicates data with AP1 (MAC address w) and AP2 (MAC address x) via a second MAC-SAP. AP1 and AP2 have identical functions, and AP1 is used as an example for illustration. AP1 communicates data with second switching module 660 via link 1. Second switching module 660 may be a module not in access point multi-link device 681, a module in access point multi-link device 1, or a module in another access point multi-link device.

[0978] Non-AP STA1 with MAC address y and non-AP STA2 with MAC address z have the same functions. Non-AP STA1 is associated with AP1 and AP3 with MAC address r, while non-AP STA2 is associated with AP2 and AP4 with MAC address s. Non-AP STA1 is used as an example for this description. The non-access point multi-link device with MLD MAC address P communicates data with non-AP STA1 via the fourth MAC-SAP.

[0979] The functions of the mobility domain MLD general sublayer 620 include at least one of the following:

[0980] (1) Providing a distributed system access function (DSAF) to the attached access point multi-link devices (e.g., access point multi-link device 1 and access point multi-link device 2) of the mobility domain MLD;

[0981] (2) Authentication, association, and re-association functions between the non-access point multi-link device 681 and the mobile domain access point multi-link device 621;

[0982] (3) Security associations, such as Pairwise Master Key Security Association (PMKSA) and Pairwise Transient Key Security Association (PTKSA), and managing the distribution of GTK / IGTK / BIGTK;

[0983] (4) managing the partial association and re-association functions between the non-access point multi-link device 681 and the subordinate access point multi-link device of the mobile domain access point multi-link device;

[0984] (5) For the subordinate access point multi-link device associated with the non-access point multi-link device 681, select the MAC address of the subordinate access point multi-link device for data transmission;

[0985] (6) Synchronize (copy or migrate) all or part of the state and buffer information of the upper layer of the MAC layer of the subordinate MLD of the mobility domain MLD;

[0986] (7) Device-level management information exchange / indication is performed through the MAC sublayer of the MLD.

[0987] The synchronization of all or part of the upper layer status and buffer information of the MAC layer above the MLD of the mobility domain MLD includes:

[0988] For a designated non-access point multi-link device associated with a mobility domain MLD, the non-access point multi-link device switches from the current access point multi-link device to which it is associated to the target access point multi-link device to be associated, involving synchronization of all or part of the state and buffer information of the upper layers of the MAC layer above the subordinate MLD, so as to maintain the continuity of the data communication session and the continuity of data transmission during the process of the non-access point multi-link device associating with different subordinate access point multi-link devices due to roaming.

[0989] All or part of the upper layer status and buffer information of the MAC layer above the subordinate MLD of the mobility domain MLD, i.e., the session or protocol status and buffer information maintained for data exchange with the designated non-access point multi-link device (for the designated non-access point multi-link device), including at least one of the following:

[0990] (1) Unicast frame sequence number (SN) / packet number (PN) allocation status and related buffer data;

[0991] (2) SN allocation status and related buffer data of group-addressed MAC Service Data Unit (MSDU);

[0992] (3) buffer data for energy saving in individually addressed frames;

[0993] (4) Block Ack session status and duplicate detection and reordering buffer data for received frames;

[0994] (5) The PN counter status of the sending end and the replay detection status and related buffer data of the receiving end.

[0995] In a possible design of this embodiment, the link reconfiguration response frame includes: a status code, which is used to indicate the status code of link reconfiguration in the mobility domain MLD scenario. When the status code value is the first value, it is used to indicate rejection of the mobility domain link reconfiguration.

[0996] The format of the link reconfiguration response frame is shown in Table 2 in the embodiment of FIG4 .

[0997] In one possible design of this embodiment, the reconfiguration status list subfield of the current access point multi-link device and the reconfiguration status list subfield of the target access point multi-link device both adopt the reconfiguration status list format. The reconfiguration status list contains one or more reconfiguration status tuples, as shown in Figure 7 . Figure 7 shows a schematic diagram of the reconfiguration status list subfield format provided by an exemplary embodiment of the present application. The reconfiguration status list subfield format includes at least one of the following: a link ID information (Link ID Info) field and a status (Status) field. In this embodiment of the present application, domains and fields have the same meaning, and subdomains and fields have the same meaning.

[0998] The Link ID Information field occupies one byte, and the Status field occupies two bytes. The format of the Link ID Information field follows the IEEE 802.11be definition. The Link ID field in the Link ID Information field represents the link identifier corresponding to the access point multi-link device and is used to delete existing links or add new links in the corresponding Link Reconfiguration Request frame. The Status field indicates the status of the Link Reconfiguration operation for the link corresponding to the Link ID field.

[0999] The above-mentioned reconfiguration status list subfield format is an exemplary possible situation. In different embodiments or different designs, it is not ruled out that the position of the reconfiguration status list subfield field in the frame, the arrangement order with other fields, the number of bytes occupied, and at least one of the field names may change. This embodiment does not limit this.

[1000] In one possible design of this embodiment, the link reconfiguration response frame includes group key data, which indicates the group key successfully added to the link corresponding to the target access point multi-link device. The group key data subfield optionally appears and contains the group key successfully added to the link corresponding to the target access point multi-link device (status code value equal to SUCCESS). Figure 8 shows a schematic diagram of the format of the group key data subfield provided in an exemplary embodiment of the present application. The group key data subfield format includes at least one of the following: a Key Data Length field and a Key Data field.

[1001] Among them, the key data length field occupies 2 bytes, and the number of bytes occupied by the key data field is variable.

[1002] The Group Key Data subfield contains an MLO GTK KDE, an MLO IGTK KDE, and an MLO BIGTK KDE, which provide the group key identified by the Link ID subfield for the link added by the target access point multi-link device.

[1003] In the case where the link reconfiguration response frame includes a group key data subfield and includes an OCI element, an OCI element subfield may optionally appear.

[1004] The above-mentioned group key data subfield format is an exemplary possible situation. In different embodiments or different designs, it is not ruled out that the position of the group key data subfield field in the frame, the arrangement order with other fields, the number of bytes occupied, and at least one of the field names may change. This embodiment does not limit this.

[1005] In a possible design of this embodiment, the link reconfiguration response frame includes: a basic multi-link element, which is used to provide a STA-granularity configuration file for one or more subordinate APs of the target access point multi-link device.

[1006] If the target access point multi-link device adds at least one link, the link reconfiguration response frame includes a basic multi-link element for providing STA profiles to one or more subordinate APs of the target access point multi-link device, each of which corresponds to a link successfully added to the multi-link reconfiguration of the non-access point multi-link device. If the target access point multi-link device does not add a link, the link reconfiguration response frame does not include the basic multi-link element.

[1007] In a possible design of this embodiment, the link reconfiguration response frame includes: a second flow identifier to link mapping element, which is used to respond to the flow identifier to link mapping on the link established with the target access point multi-link device.

[1008] In one possible design of this embodiment, the link reconfiguration response frame is used by an access point multi-link device (including a current access point multi-link device and a target access point multi-link device) in a mobility domain MLD scenario to respond to a link reconfiguration request frame sent from a non-access point multi-link device, thereby accepting or rejecting a request by the non-access point multi-link device to delete a link and / or add a link to an established multi-link.

[1009] For FT, the link reconfiguration response frame is used by access point multi-link devices (including the current access point multi-link device and the target access point multi-link device) to respond to link reconfiguration request frames sent from non-access point multi-link devices in the mobility domain MLD scenario, thereby accepting or rejecting the non-access point multi-link device's request to delete a link on the current access point multi-link device's established multi-link and its request to add a new link on the target access point multi-link device.

[1010] In a possible design of this embodiment, the switching is based on the FT, and at least one of the link reconfiguration request frame and the link reconfiguration response frame further includes:

[1011] The second indication information is used to indicate whether to support or allow FT between two access point multi-link devices attached to the same mobility domain MLD.

[1012] Exemplarily, the second indication information is called the "Whether FT is in the same mobility domain MLD" field. When the value of this field is 1, it indicates that FT is supported or allowed between two access point multi-link devices attached to the same mobility domain MLD. When the value of this field is 0, it indicates that FT is not supported or allowed between two access point multi-link devices attached to the same mobility domain MLD.

[1013] Figure 9 shows a schematic diagram of a mobility domain element format provided by an exemplary embodiment of the present application. The mobility domain element format includes at least one of the following: an element identifier (Element IDentifier, Element ID) field, a length (Length) field, a mobility domain identifier (Mobility Domain IDentifier, MDID) field, an FT capability and policy (FT Capability and Policy) field, a mobility domain MLD identifier field, and a mobility domain MLD MAC address field.

[1014] The Element ID field occupies 1 byte, the Length field occupies 1 byte, the MDID field occupies 2 bytes, the FT Capability and Policy field occupies 1 byte, the Mobility Domain MLD Identifier field occupies 0 or 1 byte, and the Mobility Domain MLD MAC Address field occupies 0 or 6 bytes.

[1015] Regarding the above-mentioned FT capability and policy fields, Figure 10 shows a schematic diagram of the FT capability and policy field format provided by an exemplary embodiment of the present application. The FT capability and policy fields include at least one of the following: FT field through DS, resource request protocol capability field, whether FT is in the same mobile domain MLD (FTinMobileDomainMLD) field, and reserved field.

[1016] Among them, the FT field through DS occupies 1 bit, the resource request protocol capability field occupies 1 bit, the MLD field whether FT is in the same mobility domain occupies 1 bit, and the reserved field occupies 5 bits.

[1017] The "Is FT in the Same Mobility Domain MLD" field indicates whether FT is supported or permitted between two access point multi-link devices attached to the same mobility domain MLD. For example, when the value of the "Is FT in the Same Mobility Domain MLD" field is 1, it indicates that FT is supported or permitted between the two access point multi-link devices attached to the same mobility domain MLD. When the value of the "Is FT in the Same Mobility Domain MLD" field is 0, it indicates that FT is not supported or permitted between the two access point multi-link devices attached to the same mobility domain MLD. Alternatively, when the value of the "Is FT in the Same Mobility Domain MLD" field is 0, it indicates that FT is supported or permitted between the two access point multi-link devices attached to the same mobility domain MLD. When the value of the "Is FT in the Same Mobility Domain MLD" field is 1, it indicates that FT is not supported or permitted between the two access point multi-link devices attached to the same mobility domain MLD. This embodiment is not limited to this.

[1018] The "FT in the same mobility domain MLD" field controls the behavior of STAs or non-access point multi-link devices when performing FT. Non-access point multi-link devices can use information from the MDE to determine the handover method recommended by the access point multi-link device and the protocols supported by the access point multi-link device.

[1019] The above-mentioned formats of the mobility domain element, FT capability, and policy fields are exemplary possible scenarios. In different embodiments or designs, the position of the mobility domain element, FT capability, and policy fields in the frame, their order relative to other fields, the number of bytes or bits occupied, the element name, or the field name may be changed. This embodiment does not limit this.

[1020] In one possible design of this embodiment, the transmission module 2810 is further configured to send and / or receive at least one second frame, where the second frame is used to synchronize context information related to a non-access point multi-link device between two access point multi-link devices, where the context information includes at least one of status information and buffer information.

[1021] In one possible design of this embodiment, the transmission module 2810 is configured to send a request frame, where the request frame is used to indicate that the non-access point multi-link device requests synchronization of context information related to the non-access point multi-link device between two access point multi-link devices;

[1022] A response frame is received, where the response frame is used to feed back to the non-access point multi-link device context information related to synchronization between the two access point multi-link devices.

[1023] In one possible design of this embodiment, the context information includes at least one of the following:

[1024] First context information, the first context information is information related to a block confirmation protocol context;

[1025] The second context information is information related to the security association context.

[1026] In a possible design of this embodiment, the first context information is carried in a block acknowledgement protocol context element.

[1027] In a possible design of this embodiment, the second context information is carried in a security association context element.

[1028] Block confirmation protocol context elements:

[1029] In a possible design of this embodiment, the block acknowledgment protocol context may also be described as a block acknowledgment protocol scenario (Block Ack context), a block acknowledgment context, or a block acknowledgment scenario, which is information about the maintained block acknowledgment process.

[1030] In one possible design of this embodiment, the block acknowledgment protocol context element includes block acknowledgment protocol context or state information that the specified MLD has established and maintained with one or more peer MLDs (i.e., non-access point multi-link devices). The block acknowledgment protocol context element includes a block acknowledgment protocol context parameter control field, which is used to indicate at least one of the following:

[1031] The device where the block confirmation protocol context element is located;

[1032] Whether the device containing the block acknowledgement protocol context element and the non-access point multi-link device for which the block acknowledgement protocol context is targeted are the same device;

[1033] If the device containing the block acknowledgment protocol context element and the non-access point multi-link device targeted by the block acknowledgment protocol context are the same device, the non-access point multi-link device targeted by the block acknowledgment protocol context;

[1034] • The number of Block Acknowledgement Protocol Context Parameter Sets included in the Block Acknowledgement Protocol Context element.

[1035] In a possible design of this embodiment, the device where the block acknowledgement protocol context element is located is a current access point multi-link device.

[1036] Figure 11 shows a schematic diagram of a block acknowledgment protocol context element format provided by an exemplary embodiment of the present application. The block acknowledgment protocol context element format includes at least one of the following: an element ID field, a length field, an element ID extension field, a block acknowledgment protocol context parameter control field, and a block acknowledgment protocol context parameter set list field. In the embodiment of the present application, a domain and a field have the same meaning, and a subdomain and a field have the same meaning.

[1037] Among them, the element ID field occupies 1 byte, the length field occupies 1 byte, the element ID extension field occupies 1 byte, the block confirmation protocol context parameter control field occupies 9 or 15 bytes, and the block confirmation protocol context parameter set list field occupies a variable number of bytes.

[1038] Regarding the above-mentioned block acknowledgment protocol context parameter control field, Figure 12 shows a format diagram of the block acknowledgment protocol context parameter control field provided by an exemplary embodiment of the present application. The block acknowledgment protocol context parameter control field includes at least one of the following: MLD MAC address field, whether the opposite MLD is the same MLD field, the opposite MLD MAC address field, the number of single block acknowledgment protocol context parameter sets field, and a reserved field.

[1039] The MLD MAC address field occupies 48 bits, whether the peer MLD is the same MLD field occupies 1 bit, the peer MLD MAC address field occupies 0 or 48 bits, the single block confirmation protocol context parameter set number field occupies 16 bits, and the reserved field occupies 7 bits.

[1040] The MLD MAC address field indicates the MAC address of the MLD where the block acknowledgment protocol context described by the block acknowledgment protocol context element is located. The MLD MAC address may be the MLD address of a roaming MLD.

[1041] The "Whether the opposite-end MLD is the same MLD" field indicates whether the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element is the same MLD. When its value is 0, it indicates that the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation context scenario element is the same MLD; when its value is 1, it indicates that the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element is multiple MLDs. Alternatively, when its value is 1, it indicates that the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation context scenario element is the same MLD; when its value is 0, it indicates that the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element is multiple MLDs. This is not limited in the embodiments of the present application.

[1042] The peer MLD MAC address indicates the MAC address of the peer MLD for the block acknowledgment protocol context described by the block acknowledgment protocol context element. When its value is 0, the peer MLD MAC address field is present in the block acknowledgment protocol context parameter control field; when its value is 1, the peer MLD MAC address field is not present in the block acknowledgment protocol context parameter control field. Alternatively, when its value is 1, the peer MLD MAC address field is present in the block acknowledgment protocol context parameter control field; when its value is 0, the peer MLD MAC address field is not present in the block acknowledgment protocol context parameter control field. This is not limited in this embodiment of the present application.

[1043] The Number of Single Block Acknowledgement Protocol Context Parameter Sets field is a 16-bit unsigned integer indicating the number of Single Block Acknowledgement Protocol Context Parameter Set fields in the Block Acknowledgement Protocol Context Parameter Set List field.

[1044] In a possible design of this embodiment, the block confirmation protocol context element includes a block confirmation protocol context parameter set list field, the block confirmation protocol context parameter set list field includes at least one block confirmation protocol context parameter set subfield, and a block confirmation protocol context parameter set subfield is used to indicate a block confirmation protocol context parameter set.

[1045] In one possible design of this embodiment, the block acknowledgment protocol context parameter set subfield is used to indicate at least one of the following:

[1046] The role of the device in the block acknowledgement protocol context;

[1047] Non-AP multi-link devices targeted by the Block Acknowledgement protocol context;

[1048] Block confirmation parameter set;

[1049] Block confirmation timeout value.

[1050] Regarding the above-mentioned block confirmation protocol context parameter set list field, Figure 13 shows a format diagram of the block confirmation protocol context parameter set list field provided by an exemplary embodiment of the present application. The block confirmation protocol context parameter set list field includes at least one of the following: one or more single block confirmation protocol context parameter set fields, and a padding field.

[1051] Among them, the number of bits occupied by a single block confirmation protocol context parameter set field is variable, and the number of bits occupied by the padding field is variable.

[1052] In one possible design of this embodiment, if the block acknowledgment protocol context parameter set subfield is used to indicate that the role of the device in the corresponding block acknowledgment protocol context is an initiator in the block acknowledgment protocol context, the block acknowledgment protocol context parameter set subfield is further used to indicate at least one of the following:

[1053] Send window starting sequence number;

[1054] Send window size.

[1055] In one possible design of this embodiment, if the block acknowledgment protocol context parameter set subfield is used to indicate that the device in the block acknowledgment protocol context has a role as a receiver in the block acknowledgment protocol context, the block acknowledgment protocol context parameter set subfield is further used to indicate at least one of the following:

[1056] Receive buffer starting sequence number;

[1057] Receive window size;

[1058] Record the starting sequence number of the bitmap;

[1059] Record the maximum sequence number of the bitmap;

[1060] Record the bitmap size.

[1061] For the above-mentioned single block acknowledgment protocol context parameter set field, when the MLD where the block acknowledgment protocol context is located is the initiator MLD role, Figure 14 shows a format diagram of a single block acknowledgment protocol context parameter set field provided by an exemplary embodiment of the present application. The single block acknowledgment protocol context parameter set field includes at least one of the following: MLD role field (initiator MLD), peer MLD (Peer MLD) field, block acknowledgment parameter set (Block Ack Parameter Set) field, block acknowledgment timeout value (Block Ack Timeout) field, send window starting sequence number (WinStartO) field, and send window size (WinSizeO) field.

[1062] Among them, the MLD role field (initiator MLD) occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the block confirmation parameter set field occupies 16 bits, the block confirmation timeout value field occupies 8 bits, the send window starting sequence number field occupies 12 bits, and the send window size field occupies 10 bits.

[1063] In the case where the MLD where the block acknowledgment protocol context is located is the receiver MLD role, Figure 15 shows a format diagram of a single block acknowledgment protocol context parameter set field provided by an exemplary embodiment of the present application. The single block acknowledgment protocol context parameter set field includes at least one of the following: MLD role field (receiver MLD), peer MLD (Peer MLD) field, block acknowledgment parameter set (Block Ack Parameter Set) field, block acknowledgment timeout value (Block Ack Timeout) field, receive buffer start sequence number (WinStartB) field, receive window size (WinSizeB) field, record bitmap start sequence number (WinStartR) field, record bitmap maximum sequence number (WinEndR) field, and record bitmap size (WinSizeR) field.

[1064] Among them, the MLD role field (receiver MLD) occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the block confirmation parameter set field occupies 48 bits, the block confirmation timeout value field occupies 16 bits, the receive buffer starting sequence number field occupies 12 bits, the receive window size field occupies 10 bits, the record bitmap starting sequence number field occupies 12 bits, the record bitmap maximum sequence number field occupies 12 bits, and the record bitmap size field occupies 10 bits.

[1065] The MLD role field indicates the role played by the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located in the block confirmation protocol. Exemplarily, when the value of the MLD role field is 0, it indicates that the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located plays the role of the initiator MLD in the block confirmation protocol; when the value of the MLD role field is 1, it indicates that the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located plays the role of the receiver MLD in the block confirmation protocol. Alternatively, when the value of the MLD role field is 1, it indicates that the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located plays the role of the initiator MLD in the block confirmation protocol; when the value of the MLD role field is 0, it indicates that the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located plays the role of the receiver MLD in the block confirmation protocol.

[1066] When the MLD where the block confirmation protocol context is located is the initiator role, the format of a single block confirmation protocol context parameter set is shown in Figure 14. When the MLD where the block confirmation protocol context is located is the receiver role, the format of a single block confirmation protocol context parameter set is shown in Figure 15.

[1067] The peer MLD field indicates the MAC address of the peer MLD for which the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set field is targeted.

[1068] The Block Acknowledgement Parameter Set field indicates the relevant parameter set of the established Block Acknowledgement protocol corresponding to the Block Acknowledgement Protocol Context described by the single Block Acknowledgement Protocol Context Parameter Set field.

[1069] The Block Ack Timeout Value field contains the duration, in TUs (1024 microseconds), after which the Block Ack protocol terminates if no frame exchange sequence occurs within this duration using the Block Ack protocol. Setting this field to 0 disables the timeout.

[1070] The send window starting sequence number field is a send buffer control parameter used to indicate the starting sequence number of the send window.

[1071] In one possible design of this embodiment, the block confirmation parameter set includes at least one of the following:

[1072] Indication information indicating whether aggregation of MSDUs is supported;

[1073] Block confirmation strategy;

[1074] Flow ID;

[1075] Buffer size.

[1076] Regarding the above-mentioned block acknowledgment parameter set field, Figure 16 shows a format diagram of the block acknowledgment parameter set field provided by an exemplary embodiment of the present application. The block acknowledgment parameter set field includes at least one of the following: A-MSDU support field, block acknowledgment policy (Block Ack Policy) field, flow identification (TID) field, and buffer size (Buffer Size) field.

[1077] Among them, the A-MSDU support field occupies 1 bit, the block confirmation policy field occupies 1 bit, the flow identification field occupies 4 bits, and the buffer size field occupies 10 bits.

[1078] The Send Window Size field is a send buffer control parameter that indicates the send window buffer size negotiated in the Block Ack protocol. The Send Window Size field indicates the number of buffers available for a given TID. When the A-MSDU Support field is 0, the number of bytes each buffer can accommodate is equal to the maximum MSDU size. When the STA Supported A-MSDU field is 1, the number of bytes each buffer can accommodate is equal to the maximum A-MSDU size supported by the STA.

[1079] The receive buffer starting sequence number field is a receive reordering buffer control parameter and indicates the value of the sequence number field of the first MSDU or A-MSDU (arranged in ascending sequence number order) that has not yet been received.

[1080] The receive window size field is a receive reordering buffer control parameter used to indicate the receive window size.

[1081] The Record Bitmap Starting Sequence Number field is a Scoreboard Context Control parameter and is a 12-bit unsigned integer starting sequence number that indicates the lowest sequence number position in the block confirmation record bitmap (indexed by sequence number).

[1082] Records the maximum sequence number field of the bitmap, indicating the highest sequence number in the current transmission window.

[1083] The Record Bitmap Size field is a scoreboard context control parameter used to indicate the maximum transmission window size and is set to the smaller of the value of the Bitmap Length field and the buffer size field of the associated response frame of the established block return protocol.

[1084] The above-mentioned block confirmation protocol context element format, block confirmation protocol context parameter control field format, block confirmation protocol context parameter set list field format, single block confirmation protocol context parameter set field format, and block confirmation parameter set field format are exemplary possible situations. In different embodiments or different designs, it is not ruled out that at least one of the positions of the above-mentioned fields in the frame, the arrangement order with other fields, the number of bytes occupied, the number of bits occupied, the element name, and the field name may be changed. This embodiment does not limit this.

[1085] Security Association Context Elements:

[1086] In a possible design of this embodiment, the security association context may also be described as a security association scenario, which is information about the security association process being maintained.

[1087] In one possible design of this embodiment, the security association context element includes the sender's PN configuration and PN counter status information, and / or the receiver's replay detection context and replay counter status information, which the designated MLD has established and maintained with one or more peer MLDs for encryption / decryption, and / or integrity protection and verification of security association-related data. FIG17 illustrates a schematic diagram of the security association context element format provided by an exemplary embodiment of the present application. The security association context element format includes at least one of the following: an Element ID field, a Length field, an Element ID Extension field, a Security Association (SA) Context Parameters Control field, and a Security Association Context Parameters Set List field.

[1088] Among them, the element ID field occupies 1 byte, the length field occupies 1 byte, the element ID extension field occupies 1 byte, the security association context parameter control field occupies 9 or 15 bytes, and the security association context parameter set list field occupies a variable number of bytes.

[1089] In one possible design of this embodiment, the security association context element includes a security association context parameter control field, where the security association context parameter control field is used to indicate at least one of the following:

[1090] The device where the security association context element resides;

[1091] Whether the device containing the security association context element and the non-access point multi-link device for which the security association context is targeted are the same device;

[1092] If the device containing the security association context element and the non-access point multi-link device targeted by the security association context are the same device, the non-access point multi-link device targeted by the security association context;

[1093] The number of security association context parameter sets included in the security association context element.

[1094] In a possible design of this embodiment, the device where the security association context element is located is a current access point multi-link device.

[1095] Regarding the above-mentioned security association context parameter control field, Figure 18 shows a format diagram of the security association context parameter control field provided by an exemplary embodiment of the present application. The security association context parameter control field includes at least one of the following: MLD MAC address field, whether the peer MLD is the same MLD field, peer MLD MAC address field, security association scenario parameter set quantity field, and reserved field.

[1096] Among them, the MLD MAC address field occupies 48 bits, whether the peer MLD is the same MLD field occupies 1 bit, the peer MLD MAC address field occupies 0 or 48 bits, the security association scenario parameter set number field occupies 16 bits, and the reserved field occupies 7 bits.

[1097] In a possible design of this embodiment, the security association context element includes a security association context parameter set list field, the security association context parameter set list field includes at least one security association context parameter set subfield, and a security association context parameter set subfield is used to indicate a security association context parameter set.

[1098] In one possible design of this embodiment, the security association context parameter set subfield is used to indicate at least one of the following:

[1099] The role of the device in the security association context;

[1100] The non-access point multi-link device for which the security association context is intended;

[1101] The security association type of the security association context.

[1102] Regarding the above-mentioned security association context parameter set list field, Figure 19 shows a format diagram of the security association context parameter set list field provided by an exemplary embodiment of the present application. The security association context parameter set list field includes at least one of the following: one or more security association context parameter set fields.

[1103] The number of bits occupied by the security association context parameter set field is variable.

[1104] In one possible design of this embodiment, if the security association context parameter set subfield is used to indicate that the role of the device in which the security association context resides is an initiator in the security association context, the security association context parameter set subfield is further used to indicate at least one of the following:

[1105] Replay counter number;

[1106] TID;

[1107] The count of the replay counter for the TID.

[1108] In one possible design of this embodiment, if the security association context parameter set subfield is used to indicate that the role of the device where the security association context resides in the security association context is a receiver, the security association context parameter set subfield is further used to indicate at least one of the following:

[1109] Packet number counter number;

[1110] TID;

[1111] The count of the packet number counter for the TID.

[1112] For the above-mentioned security association context parameter set field, when the MLD where the security association context described by the security association context parameter set field is located is the receiver MLD role, Figure 20 shows a format diagram of the security association context parameter set field provided by an exemplary embodiment of the present application. The security association context parameter set field includes at least one of the following: MLD role field, peer MLD (Peer MLD) field, PTKSA / GTKSA / TPKSA field, the number of replay counters field, one or more TID fields, and one or more replay counter count fields.

[1113] The MLD role field occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the PTKSA / GTKSA / TPKSA field occupies 2 bits, the replay counter number field occupies 5 bits, the TID field occupies 8 bits, and the replay counter count field occupies 48 bits.

[1114] In the case where the MLD where the security association context described by the security association context parameter set field is located is the sender MLD role, Figure 21 shows a format diagram of the security association context parameter set field provided by an exemplary embodiment of the present application. The security association context parameter set field includes at least one of the following: MLD role field, peer MLD (Peer MLD) field, PTKSA / GTKSA / TPKSA field, PN counter number (the number of PN counters) field, one or more TID fields, and one or more PN counter count (the count of the PN counter) fields.

[1115] Among them, the MLD role field occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the PTKSA / GTKSA / TPKSA field occupies 2 bits, the PN counter number field occupies 5 bits, the TID field occupies 8 bits, the middle PN counter count field occupies 0 or 48 bits, and the last PN counter count field occupies 48 bits.

[1116] The MLD role field indicates the role played by the MLD where the security association context described by the security association context parameter set field is located in the security association context. Exemplarily, when the value of the MLD role field is 0, it indicates that the MLD where the security association context described by the security association context parameter set field is located plays the role of a receiver MLD, that is, it describes the receiving-end replay context parameter set; when the value of the MLD role field is 1, it indicates that the MLD where the security association context described by the security association context parameter set field is located plays the role of a sender MLD, that is, it describes the sending-end PN counter context parameter set. Or, when the value of the MLD role field is 1, it indicates that the MLD where the security association context described by the security association context parameter set field is located plays the role of a receiver MLD; when the value of the MLD role field is 0, it indicates that the MLD where the security association context described by the security association context parameter set field is located plays the role of a sender MLD.

[1117] The PTKSA / GTKSA / TPKSA field indicates the security association type corresponding to the replay context described by the replay context parameter set field, as shown in Table 4.

[1118] The above-mentioned block confirmation protocol context element format, security association context parameter control format, security association context parameter set list field format, and security association context parameter set field format are exemplary possible situations. In different embodiments or different designs, it is not ruled out that at least one of the positions of the above-mentioned fields in the frame, the arrangement order with other fields, the number of bytes occupied, the number of bits occupied, the element name, and the field name may change. This embodiment does not limit this.

[1119] In a possible design of this embodiment, the second frame further includes: third indication information, where the third indication information is used to indicate that the context information includes information about a block acknowledgement protocol context and / or a security association context.

[1120] In a possible design of this embodiment, the two access point multi-link devices belong to the same mobility domain (MLD), and at least one of the request frame and the response frame further includes:

[1121] The first indication information is used to indicate the mobility domain MLD.

[1122] In a possible design of this embodiment, the switching is based on the FT, at least one of the request frame and the response frame, and further includes:

[1123] The second indication information is used to indicate whether FT is supported or permitted between two access point multi-link devices attached to the same mobility domain (MLD). Exemplarily, the second indication information is called the "Whether FT is in the same mobility domain (MLD)" field. When the value of this field is 1, it indicates that FT is supported or permitted between the two access point multi-link devices attached to the same mobility domain (MLD). When the value of this field is 0, it indicates that FT is not supported or permitted between the two access point multi-link devices attached to the same mobility domain (MLD).

[1124] In a possible design of this embodiment, the two access point multi-link devices include a current access point multi-link device and a target access point multi-link device:

[1125] The request frame is sent to the current access point multi-link device, and then sent by the current access point multi-link device to the target access point multi-link device;

[1126] The response frame is sent from the target access point multi-link device to the current access point multi-link device, and then fed back by the current access point multi-link device.

[1127] In a possible design of this embodiment, the switching is based on FT, the request frame is an FT confirmation frame, and the response frame is an FT acknowledgement frame.

[1128] The non-access point multi-link device sends an FT confirmation frame to the target access point multi-link device via the current access point multi-link device. Then, the target access point multi-link device sends an FT response frame to the non-access point multi-link device via the current access point multi-link device. The FT confirmation frame includes at least one of the following: non-access point multi-link device information, target access point multi-link device information, an MDE, a block acknowledgement protocol context element, a security association context element, and a basic multi-link element. The FT response frame includes at least one of the following: non-access point multi-link device information, target access point multi-link device information, an MDE, a timeout interval element, a block acknowledgement protocol context element, a security association context element, and a basic multi-link element.

[1129] The FT confirmation frame and the FT response frame carry a block confirmation protocol context element and a security association context element, indicating related block confirmation protocol context (or state) information and security association context (or state) information.

[1130] In one possible design of this embodiment, the two access point multi-link devices belong to the same mobility domain MLD, and the transmission module 2810 is further configured to send an FT request frame;

[1131] Receive FT response frame.

[1132] When a non-access point multi-link device determines that it needs to switch from a current access point multi-link device to a target access point multi-link device in a mobility domain (MLD) scenario, the non-access point multi-link device sends an FT request frame to the target access point multi-link device via the current access point multi-link device. Then, the target access point multi-link device sends an FT response frame to the non-access point multi-link device via the current access point multi-link device. The FT request frame includes at least one of the following: non-access point multi-link device information, target access point multi-link device information, an MDE, and a basic multi-link element. The FT response frame includes at least one of the following: non-access point multi-link device information, target access point multi-link device information, an MDE, and a basic multi-link element.

[1133] The FT request frame and the FT response frame carry an MDE (FTinMobileDomainMLD field, mobile domain MLD information field), indicating that FT is supported or allowed between two access point multi-link devices attached to the same mobile domain MLD.

[1134] In one possible design of this embodiment, the transmission module 2810 is further configured to send an association request frame;

[1135] Receives an association response frame.

[1136] The non-access point multi-link device sends an association request frame or a reassociation request frame to the current access point multi-link device, and then the current access point multi-link device feeds back an association response frame or a reassociation response frame to the non-access point multi-link device.

[1137] The non-access point multi-link device sends an association request frame or a reassociation request frame to the current access point multi-link device, including: a mobility domain element (MDE), a basic multi-link element;

[1138] The current access point multi-link device sends an association response frame or a reassociation response frame to the non-access point multi-link device, including: a mobility domain element (MDE) and a basic multi-link element.

[1139] The association request frame or reassociation request frame carries the MDE (FTinMobileDomainMLD field, mobile domain MLD information field), instructing the non-access point multi-link device to associate with the access point multi-link device in the mobile domain MLD scenario (or the non-access point multi-link device is associated with the access point multi-link device affiliated with the mobile domain MLD), and indicating that FT is supported or allowed between two access point multi-link devices affiliated with the same mobile domain MLD.

[1140] In a possible design of this embodiment, the switching is based on the FT, and link reconfiguration is performed when the first duration is less than or equal to the deadline for link reconfiguration;

[1141] The first duration represents the duration between the sending time of the FT request frame and the sending time of the link reconfiguration request frame, and the first frame includes the link reconfiguration request frame.

[1142] In a possible design of this embodiment, the transmission module 2810 is further used to send fourth indication information, and the fourth indication information is used to indicate the deadline or timeout time of the link reconfiguration.

[1143] Exemplarily, the fourth indication information is called a timeout interval element (TIE), which is used to specify a time interval and a timeout period.

[1144] In a possible design of this embodiment, the fourth indication information is indicated by a start time and a timeout interval, or,

[1145] The fourth indication information is indicated by a deadline.

[1146] In a possible design of this embodiment, the start time is implicitly represented by the sending time or receiving time of the fourth indication information;

[1147] The timeout interval is explicitly indicated by the fourth indication information.

[1148] In an embodiment of the present application, a timeout interval type value corresponding to the link reconfiguration deadline time interval is added to the timeout interval type field of the timeout interval element to indicate that the timeout interval value field represents the link reconfiguration deadline time interval. Figure 22 shows a schematic diagram of the timeout interval element format provided by an exemplary embodiment of the present application. The timeout interval element format includes at least one of the following: an element ID field, a length field, a timeout interval type field, and a timeout interval value field.

[1149] Among them, the element ID field occupies 1 byte, the length field occupies 1 byte, the timeout interval type field occupies 1 byte, and the timeout interval value field occupies 4 bytes.

[1150] The above-mentioned timeout interval element format is an exemplary possible situation. In different embodiments or different designs, it is not ruled out that the position of the timeout interval element in the frame, the arrangement order between other fields, the number of bytes occupied, and at least one of the element names may change. This embodiment does not limit this.

[1151] The Timeout Interval Value field contains a 32-bit unsigned integer, where the Link Reconfiguration Deadline Interval can be set to 0 to indicate that no deadline exists. The Timeout Interval Type field is defined as shown in Table 5.

[1152] In this embodiment, the transmission module 2810 can be divided into multiple transmission modules, such as a first transmission module and a second transmission module. The first transmission module is used to send the first frame, and the second transmission module is used to receive the first frame; or the first transmission module is used to receive the first frame, and the second transmission module is used to send the first frame. This embodiment does not limit the functions of the different transmission modules.

[1153] This embodiment is described by taking one transmission module 2810 as an example, and the number of transmission modules 2810 is not limited.

[1154] For an introduction to the functions of the transmission module 2810 , please refer to the contents of step 510 in the embodiment of FIG. 5 .

[1155] Figure 29 shows a block diagram of a current access point multi-link device provided by an exemplary embodiment of the present application. The device can be implemented as a current access point multi-link device or as a part of a current access point multi-link device through software or hardware or a combination of both. The device includes a transmission module 2910 and a processing module 2920, wherein the function of the transmission module 2910 is implemented by a receiver or transmitter in the current access point multi-link device, and the function of the processing module 2920 is implemented by a processor in the current access point multi-link device.

[1156] The transmission module 2910 is configured to send and / or receive at least one first frame, where the at least one first frame is used to implement switching between a non-access point multi-link device and a current access point multi-link device and a target access point multi-link device at different locations based on link reconfiguration.

[1157] In a possible design of this embodiment, the current access point multi-link device and the target access point multi-link device belong to the same mobility domain MLD, or the current access point multi-link device and the target access point multi-link device belong to the same mobility domain.

[1158] The mobility domain MLD, or logical access point multi-link device, treats multiple access point multi-link devices that are not in the same location as one MLD. This embodiment does not limit the specific name of the mobility domain MLD.

[1159] In a possible design of this embodiment, the non-access point multi-link device switches between the current access point multi-link device and the target access point multi-link device, including at least one of the following scenarios:

[1160] Handover scenario 1: When a non-access point multi-link device is associated with a mobility domain MLD, and the current access point multi-link device and the target access point multi-link device belong to the same mobility domain MLD, the non-access point multi-link device performs a handover of the access point multi-link device-level association level to the mobility domain MLD between the current access point multi-link device and the target access point multi-link device.

[1161] Handover scenario 2: When the non-access point multi-link device is associated with only one of the current access point multi-link device and the target access point multi-link device, and the current access point multi-link device and the target access point multi-link device are not affiliated with the same mobility domain (MLD), the non-access point multi-link device switches its association between the current access point multi-link device and the target access point multi-link device.

[1162] The switching (transition) in the embodiment of the present application can also be replaced by describing as conversion.

[1163] For handover scenario 1, handover of the access point multi-link device-level association to the mobility domain MLD means that, before the handover, the non-access point multi-link device is associated with the mobility domain MLD, and the non-access point multi-link device establishes a multi-link with an access point multi-link device affiliated with the mobility domain MLD (i.e., all or part of the link established between the non-access point multi-link device and the mobility domain MLD belongs to the link between the non-access point multi-link device and the access point multi-link device affiliated with the mobility domain MLD). After the handover, the non-access point multi-link device is still associated with the mobility domain MLD, and the non-access point multi-link device establishes a multi-link with another access point multi-link device affiliated with the mobility domain MLD (i.e., all or part of the link established between the non-access point multi-link device and the mobility domain MLD belongs to the link between the non-access point multi-link device and the other access point multi-link device affiliated with the mobility domain MLD).

[1164] For the second handover scenario, the non-access point multi-link device is associated with an access point multi-link device affiliated with different mobility domain MLDs before and after the handover, thereby performing the associated handover.

[1165] For the mobility domain MLD to which the current access point multi-link device belongs among the current access point multi-link device and the target access point multi-link device, the mobility domain MLD belongs to multiple access point multi-link devices including the current access point multi-link device.

[1166] For the mobility domain MLD to which the target access point multi-link device in the current access point multi-link device and the target access point multi-link device belongs, the mobility domain MLD belongs to multiple access point multi-link devices including the target access point multi-link device.

[1167] The switching provided in the embodiments of the present application may include BSS switching, FT, seamless BSS switching or seamless fast switching.

[1168] In a possible design of this embodiment, the current access point multi-link device and the target access point multi-link device belong to the same mobility domain (MLD), and the mobility domain (MLD) is used for at least one of the following:

[1169] Provide connection services between non-access point multi-link devices or current access point multi-link devices and target access point multi-link devices and DS;

[1170] Maintaining data continuity for non-AP multi-link devices during handover between the current AP multi-link device and the target AP multi-link device during roaming;

[1171] Authentication and / or association or reassociation of non-access point multi-link devices;

[1172] Security association for non-access point multi-link devices;

[1173] Distribution of all or part of the security association information for non-access point multi-link devices;

[1174] Synchronize all or part of the status and / or buffer information of the upper layer of the MAC of the current access point multi-link device and the target access point multi-link device;

[1175] Manage the distribution of authentication information for non-access point multi-link device links;

[1176] Managing access point multi-link device-level association or re-association between a non-access point multi-link device and a current access point multi-link device and a target access point multi-link device;

[1177] For the current access point multi-link device and the target access point multi-link device that has established a multi-link with the non-access point multi-link device, select the MAC corresponding to the target access point multi-link device for data transmission;

[1178] synchronization of first data between the current access point multi-link device and the target access point multi-link device, the first data being used to maintain data communication between the non-access point multi-link device and the current access point multi-link device and the target access point multi-link device or the DS;

[1179] • The MLD level information is exchanged or indicated via the MAC sublayers of the current access point multi-link device and the target access point multi-link device.

[1180] In one possible design of this embodiment, the transmission module 2910 is configured to send a link reconfiguration request frame, where the link reconfiguration request frame is used to instruct a non-access point multi-link device to request link reconfiguration with a current access point multi-link device and a target access point multi-link device to implement handover;

[1181] A link reconfiguration response frame is received, where the link reconfiguration response frame is used to feed back to the non-access point multi-link device the link reconfiguration performed with the current access point multi-link device and the target access point multi-link device.

[1182] In a possible design of this embodiment, the current access point multi-link device and the target access point multi-link device include the current access point multi-link device and the target access point multi-link device. The link reconfiguration request frame is sent by the non-access point multi-link device to the current access point multi-link device and is sent by the current access point multi-link device to the target access point multi-link device.

[1183] In a possible design of this embodiment, the current access point multi-link device and the target access point multi-link device include the current access point multi-link device and the target access point multi-link device, and the link reconfiguration response frame is sent by the target access point multi-link device to the current access point multi-link device, and then fed back by the current access point multi-link device.

[1184] When a non-access point multi-link device needs to switch from communicating with a current access point multi-link device to communicating with a target access point multi-link device, the non-access point multi-link device sends a link reconfiguration request frame to the current access point multi-link device, where the link reconfiguration request frame is used to request deletion of at least one link between the non-access point multi-link device and the current access point multi-link device; and the current access point multi-link device sends a link reconfiguration request frame to the target access point multi-link device, where the link reconfiguration request frame is used to request establishment of at least one link between the non-access point multi-link device and the target access point multi-link device.

[1185] The target access point multi-link device sends a link reconfiguration response frame to the current access point multi-link device. The link reconfiguration response frame is used to indicate the link reconfiguration status corresponding to the target access point multi-link device, such as whether a link is established with the non-access point multi-link device. The current access point multi-link device sends a link reconfiguration response frame to the non-access point multi-link device. The link reconfiguration response frame is used to indicate the link reconfiguration status corresponding to the current access point multi-link device and the target access point multi-link device, such as whether the current access point multi-link device deletes the link and whether the target access point multi-link device establishes a link with the non-access point multi-link device.

[1186] In one possible design of this embodiment, the current access point multi-link device and the target access point multi-link device include a current access point multi-link device and a target access point multi-link device;

[1187] The link reconfiguration request frame includes:

[1188] A first element corresponding to the current access point multi-link device, used to delete at least one link between the current access point multi-link device and the current access point multi-link device;

[1189] The second element corresponding to the target access point multi-link device is used to establish at least one link with the target access point multi-link device.

[1190] In one possible design of this embodiment, the first element includes a first reconfiguration multi-link element, which is used to describe reconfiguration multi-link information of the non-access point multi-link device and the current access point multi-link device;

[1191] The second element includes a second reconfiguration multi-link element, which is used to describe the reconfiguration multi-link information of the non-access point multi-link device and the target access point multi-link device.

[1192] In a possible design of this embodiment, the link reconfiguration request frame further includes:

[1193] The first flow identifier to link mapping element is used to perform flow identifier to link mapping on the link established with the target access point multi-link device.

[1194] In a possible design of this embodiment, the format of the link reconfiguration request frame is as shown in Table 1 in the embodiment of FIG4 .

[1195] In a possible design of this embodiment, the current access point multi-link device and the target access point multi-link device include a current access point multi-link device and a target access point multi-link device, and the link reconfiguration response frame includes:

[1196] a third element corresponding to the current access point multi-link device, used to indicate a link reconfiguration state corresponding to the current access point multi-link device;

[1197] The fourth element corresponding to the target access point multi-link device is used to indicate a link reconfiguration state corresponding to the target access point multi-link device.

[1198] In one possible design of this embodiment, the third element includes at least one of the following: a reconfiguration state list of the current access point multi-link device, including at least one reconfiguration state tuple; a number of reconfiguration state tuples of the current access point multi-link device;

[1199] The fourth element includes at least one of the following: a reconfiguration state list of the target access point multi-link device, including at least one reconfiguration state element; a number of reconfiguration state tuples of the target access point multi-link device;

[1200] The reconfiguration status element is used to indicate the reconfiguration status of a link.

[1201] In a possible design of this embodiment, the link reconfiguration response frame may be an action frame of protected EHT, UHR, or UHR+ type. The format of the link reconfiguration response frame is shown in Table 2 in the embodiment of FIG4 .

[1202] In a possible design of this embodiment, the current access point multi-link device and the target access point multi-link device belong to the same mobility domain (MLD), or the current access point multi-link device and the target access point multi-link device belong to the same mobility domain. The transmission module 2910 is configured to send and / or receive first indication information, where the first indication information is used to indicate the mobility domain (MLD).

[1203] In a possible design of this embodiment, the first indication information is carried in at least one of the following frames:

[1204] Link reconfiguration request frame;

[1205] Link reconfiguration response frame;

[1206] Request frame;

[1207] Response frame;

[1208] FT request frame;

[1209] FT response frame;

[1210] FT confirmation frame;

[1211] FT response frame;

[1212] Association request frame;

[1213] Association response frame;

[1214] Reassociation request frame;

[1215] Reassociation response frame;

[1216] The request frame is used to instruct the non-access point multi-link device to request the replication or migration of context information between the current access point multi-link device and the target access point multi-link device to maintain data connectivity during the handover process, and the response frame is used to indicate to the non-access point multi-link device the result of the replication or migration of context information between the current access point multi-link device and the target access point multi-link device.

[1217] In one possible design of this embodiment, the first indication information includes at least one of the following:

[1218] Mobile domain MLD identifier;

[1219] Mobility domain MLD MAC address.

[1220] Exemplarily, the first indication information is called a Mobility Domain Element (MDE), which is used to indicate link reconfiguration in a mobility domain MLD scenario and carries information such as mobility domain MLD information (e.g., a mobility domain MLD identifier or a MAC address of the mobility domain MLD), whether FT is within the same mobility domain MLD, etc. The access point multi-link device can use the MDE to notify that the access point multi-link device is included in or affiliated with a mobility domain MLD, notify the access point multi-link device of its support for the FT function, and notify FT policy information, including whether FT is supported or permitted between the current access point multi-link device and a target access point multi-link device affiliated with the same mobility domain MLD.

[1221] In a possible design of this embodiment, the switching is based on FT, and the transmission module 2910 is configured to send and / or receive second indication information, where the second indication information is used to indicate whether FT is supported or allowed between the current access point multi-link device and the target access point multi-link device affiliated with the same mobility domain MLD.

[1222] Performing FT between the current access point multi-link device and the target access point multi-link device attached to the same mobility domain MLD is used to maintain data connectivity during handover, compared with performing FT between the current access point multi-link device and the target access point multi-link device.

[1223] In a possible design of this embodiment, the second indication information is carried in at least one of the following frames:

[1224] Link reconfiguration request frame;

[1225] Link reconfiguration response frame;

[1226] Request frame;

[1227] Response frame;

[1228] FT request frame;

[1229] FT response frame;

[1230] FT confirmation frame;

[1231] FT response frame;

[1232] Association request frame;

[1233] Association response frame;

[1234] Reassociation request frame;

[1235] Reassociation response frame;

[1236] The request frame is used to instruct the non-access point multi-link device to request the replication or migration of context information between the current access point multi-link device and the target access point multi-link device to maintain data connectivity during the handover process, and the response frame is used to indicate to the non-access point multi-link device the result of the replication or migration of context information between the current access point multi-link device and the target access point multi-link device.

[1237] In one possible design of this embodiment, based on the mobility domain MLD architecture, a high-level system architecture of the mobility domain MLD and its subordinate access point multi-link devices and non-access point multi-link devices for switching a non-access point multi-link device (or STA) for data connectivity from a current access point multi-link device (or AP) to a target access point multi-link device (or AP) is shown in FIG6 .

[1238] The high-level system architecture includes at least one of the following: DS610, mobile domain MLD general sublayer 620, first switching module 630, auxiliary MLD upper MAC sublayer 640, auxiliary MLD lower MAC sublayer 650, second switching module 660, non-access point multi-link device lower MAC sublayer 670, non-access point multi-link device upper MAC sublayer 680.

[1239] The DS610 is an architecture for distributing computing and communication functions across multiple nodes or devices. The primary function of the DS is to coordinate and manage computing and communication tasks in a distributed environment to achieve efficient data transmission and collaboration.

[1240] The mobility domain MLD general sublayer 620 includes a mobility domain access point multi-link device 621 . The mobility domain access point multi-link device 621 has an MLD MAC address of Q and performs data communication with the DS 610 through a first MAC-Service Access Point (SAP).

[1241] Access point multi-link device 1 with an MLD MAC address of M and access point multi-link device 2 with an MLD MAC address of N have the same functions. Access point multi-link device 1 is used as an example for description. Mobility domain access point multi-link device 621 communicates data with access point multi-link device 1 via first switching module 630. First switching module 630 is a module within mobility domain access point multi-link device 621, a module within access point multi-link device 1, or a module within another access point multi-link device.

[1242] Access point multi-link device 1 communicates data with AP1 (MAC address w) and AP2 (MAC address x) via a second MAC-SAP. AP1 and AP2 have identical functions, and AP1 is used as an example for illustration. AP1 communicates data with second switching module 660 via link 1. Second switching module 660 may be a module not in access point multi-link device 681, a module in access point multi-link device 1, or a module in another access point multi-link device.

[1243] Non-AP STA1 with MAC address y and non-AP STA2 with MAC address z have the same functions. Non-AP STA1 is associated with AP1 and AP3 with MAC address r, while non-AP STA2 is associated with AP2 and AP4 with MAC address s. Non-AP STA1 is used as an example for this description. The non-access point multi-link device with MLD MAC address P communicates data with non-AP STA1 via the fourth MAC-SAP.

[1244] The functions of the mobility domain MLD general sublayer 620 include at least one of the following:

[1245] (1) Providing a distributed system access function (DSAF) to the attached access point multi-link devices (e.g., access point multi-link device 1 and access point multi-link device 2) of the mobility domain MLD;

[1246] (2) Authentication, association, and re-association functions between the non-access point multi-link device 681 and the mobile domain access point multi-link device 621;

[1247] (3) Security associations, such as Pairwise Master Key Security Association (PMKSA) and Pairwise Transient Key Security Association (PTKSA), and managing the distribution of GTK / IGTK / BIGTK;

[1248] (4) managing the partial association and re-association functions between the non-access point multi-link device 681 and the subordinate access point multi-link device of the mobile domain access point multi-link device;

[1249] (5) For the subordinate access point multi-link device associated with the non-access point multi-link device 681, select the MAC address of the subordinate access point multi-link device for data transmission;

[1250] (6) Synchronize (copy or migrate) all or part of the state and buffer information of the upper layer of the MAC layer of the subordinate MLD of the mobility domain MLD;

[1251] (7) MLD-level management information exchange / indication is performed through the MAC sublayer of the MLD-attached layer.

[1252] The synchronization of all or part of the upper layer status and buffer information of the MAC layer above the MLD of the mobility domain MLD includes:

[1253] For a designated non-access point multi-link device associated with a mobility domain MLD, the non-access point multi-link device switches from the current access point multi-link device to which it is associated to the target access point multi-link device to be associated, involving synchronization of all or part of the state and buffer information of the upper layers of the MAC layer above the subordinate MLD, so as to maintain the continuity of the data communication session and the continuity of data transmission during the process of the non-access point multi-link device associating with different subordinate access point multi-link devices due to roaming.

[1254] All or part of the upper layer status and buffer information of the MAC layer above the subordinate MLD of the mobility domain MLD, i.e., the session or protocol status and buffer information maintained for data exchange with the designated non-access point multi-link device (for the designated non-access point multi-link device), including at least one of the following:

[1255] (1) Unicast frame sequence number (SN) / packet number (PN) allocation status and related buffer data;

[1256] (2) SN allocation status and related buffer data of group-addressed MAC Service Data Unit (MSDU);

[1257] (3) buffer data for energy saving in individually addressed frames;

[1258] (4) Block Ack session status and duplicate detection and reordering buffer data for received frames;

[1259] (5) The PN counter status of the sending end and the replay detection status and related buffer data of the receiving end.

[1260] In a possible design of this embodiment, the link reconfiguration response frame includes: a status code, which is used to indicate the status code of link reconfiguration in the mobility domain MLD scenario. When the status code value is the first value, it is used to indicate rejection of the mobility domain link reconfiguration.

[1261] The format of the link reconfiguration response frame is shown in Table 2 in the embodiment of FIG4 .

[1262] In one possible design of this embodiment, the reconfiguration status list subfield of the current access point multi-link device and the reconfiguration status list subfield of the target access point multi-link device both adopt the reconfiguration status list format. The reconfiguration status list contains one or more reconfiguration status tuples, as shown in Figure 7 . Figure 7 shows a schematic diagram of the reconfiguration status list subfield format provided by an exemplary embodiment of the present application. The reconfiguration status list subfield format includes at least one of the following: a link ID information (Link ID Info) field and a status (Status) field. In this embodiment of the present application, domains and fields have the same meaning, and subdomains and fields have the same meaning.

[1263] The Link ID Information field occupies one byte, and the Status field occupies two bytes. The format of the Link ID Information field follows the IEEE 802.11be definition. The Link ID field in the Link ID Information field represents the link identifier corresponding to the access point multi-link device and is used to delete existing links or add new links in the corresponding Link Reconfiguration Request frame. The Status field indicates the status of the Link Reconfiguration operation for the link corresponding to the Link ID field.

[1264] The above-mentioned reconfiguration status list subfield format is an exemplary possible situation. In different embodiments or different designs, it is not ruled out that the position of the reconfiguration status list subfield field in the frame, the arrangement order with other fields, the number of bytes occupied, and at least one of the field names may change. This embodiment does not limit this.

[1265] In one possible design of this embodiment, the link reconfiguration response frame includes group key data, which indicates the group key successfully added to the link corresponding to the target access point multi-link device. The group key data subfield optionally appears and contains the group key successfully added to the link corresponding to the target access point multi-link device (status code value equal to SUCCESS). Figure 8 shows a schematic diagram of the format of the group key data subfield provided in an exemplary embodiment of the present application. The group key data subfield format includes at least one of the following: a Key Data Length field and a Key Data field.

[1266] Among them, the key data length field occupies 2 bytes, and the number of bytes occupied by the key data field is variable.

[1267] The Group Key Data subfield contains an MLO GTK KDE, an MLO IGTK KDE, and an MLO BIGTK KDE, which provide the group key identified by the Link ID subfield for the link added by the target access point multi-link device.

[1268] In the case where the link reconfiguration response frame includes a group key data subfield and includes an OCI element, an OCI element subfield may optionally appear.

[1269] The above-mentioned group key data subfield format is an exemplary possible situation. In different embodiments or different designs, it is not ruled out that the position of the group key data subfield field in the frame, the arrangement order with other fields, the number of bytes occupied, and at least one of the field names may change. This embodiment does not limit this.

[1270] In a possible design of this embodiment, the link reconfiguration response frame includes: a basic multi-link element, which is used to provide a STA-granularity configuration file for one or more subordinate APs of the target access point multi-link device.

[1271] If the target access point multi-link device adds at least one link, the link reconfiguration response frame includes a basic multi-link element for providing STA profiles to one or more subordinate APs of the target access point multi-link device, each of which corresponds to a link successfully added to the multi-link reconfiguration of the non-access point multi-link device. If the target access point multi-link device does not add a link, the link reconfiguration response frame does not include the basic multi-link element.

[1272] In a possible design of this embodiment, the link reconfiguration response frame includes: a second flow identifier to link mapping element, which is used to respond to the flow identifier to link mapping on the link established with the target access point multi-link device.

[1273] In one possible design of this embodiment, the link reconfiguration response frame is used by an access point multi-link device (including a current access point multi-link device and a target access point multi-link device) in a mobility domain MLD scenario to respond to a link reconfiguration request frame sent from a non-access point multi-link device, thereby accepting or rejecting a request by the non-access point multi-link device to delete a link and / or add a link to an established multi-link.

[1274] For FT, the link reconfiguration response frame is used by access point multi-link devices (including the current access point multi-link device and the target access point multi-link device) to respond to link reconfiguration request frames sent from non-access point multi-link devices in the mobility domain MLD scenario, thereby accepting or rejecting the non-access point multi-link device's request to delete a link on the current access point multi-link device's established multi-link and its request to add a new link on the target access point multi-link device.

[1275] In a possible design of this embodiment, the switching is based on the FT, and at least one of the link reconfiguration request frame and the link reconfiguration response frame further includes:

[1276] The second indication information is used to indicate whether to support or allow FT between the current access point multi-link device and the target access point multi-link device attached to the same mobility domain MLD.

[1277] Exemplarily, the second indication information is called the "Whether FT is in the same mobility domain MLD" field. When the value of this field is 1, it indicates that FT is supported or allowed between the current access point multi-link device and the target access point multi-link device attached to the same mobility domain MLD. When the value of this field is 0, it indicates that FT is not supported or allowed between the current access point multi-link device and the target access point multi-link device attached to the same mobility domain MLD.

[1278] Figure 9 shows a schematic diagram of a mobility domain element format provided by an exemplary embodiment of the present application. The mobility domain element format includes at least one of the following: an element identifier (Element IDentifier, Element ID) field, a length (Length) field, a mobility domain identifier (Mobility Domain IDentifier, MDID) field, an FT capability and policy (FT Capability and Policy) field, a mobility domain MLD identifier field, and a mobility domain MLD MAC address field.

[1279] The Element ID field occupies 1 byte, the Length field occupies 1 byte, the MDID field occupies 2 bytes, the FT Capability and Policy field occupies 1 byte, the Mobility Domain MLD Identifier field occupies 0 or 1 byte, and the Mobility Domain MLD MAC Address field occupies 0 or 6 bytes.

[1280] Regarding the above-mentioned FT capability and policy fields, Figure 10 shows a schematic diagram of the FT capability and policy field format provided by an exemplary embodiment of the present application. The FT capability and policy fields include at least one of the following: FT field through DS, resource request protocol capability field, whether FT is in the same mobile domain MLD (FTinMobileDomainMLD) field, and reserved field.

[1281] Among them, the FT field through DS occupies 1 bit, the resource request protocol capability field occupies 1 bit, the MLD field whether FT is in the same mobility domain occupies 1 bit, and the reserved field occupies 5 bits.

[1282] The "Is FT in the Same Mobility Domain MLD" field indicates whether FT is supported or permitted between the current access point multi-link device and the target access point multi-link device affiliated with the same mobility domain MLD. For example, when the value of the "Is FT in the Same Mobility Domain MLD" field is 1, it indicates that FT is supported or permitted between the current access point multi-link device and the target access point multi-link device affiliated with the same mobility domain MLD. When the value of the "Is FT in the Same Mobility Domain MLD" field is 0, it indicates that FT is not supported or permitted between the current access point multi-link device and the target access point multi-link device affiliated with the same mobility domain MLD. Alternatively, when the value of the "Is FT in the Same Mobility Domain MLD" field is 0, it indicates that FT is supported or permitted between the current access point multi-link device and the target access point multi-link device affiliated with the same mobility domain MLD. When the value of the "Is FT in the Same Mobility Domain MLD" field is 1, it indicates that FT is not supported or permitted between the current access point multi-link device and the target access point multi-link device affiliated with the same mobility domain MLD. This embodiment is not limited to this.

[1283] The "FT in the same mobility domain MLD" field controls the behavior of STAs or non-access point multi-link devices when performing FT. Non-access point multi-link devices can use information from the MDE to determine the handover method recommended by the access point multi-link device and the protocols supported by the access point multi-link device.

[1284] The above-mentioned formats of the mobility domain element, FT capability, and policy fields are exemplary possible scenarios. In different embodiments or designs, the position of the mobility domain element, FT capability, and policy fields in the frame, their order relative to other fields, the number of bytes or bits occupied, the element name, or the field name may be changed. This embodiment does not limit this.

[1285] In one possible design of this embodiment, the transmission module 2910 is configured to send and / or receive at least one second frame, where the second frame is used to synchronize context information related to the non-access point multi-link device between the current access point multi-link device and the target access point multi-link device, where the context information includes at least one of status information and buffer information.

[1286] In one possible design of this embodiment, the transmission module 2910 is configured to send a request frame, where the request frame is used to indicate that the non-access point multi-link device requests synchronization of context information related to the non-access point multi-link device between the current access point multi-link device and the target access point multi-link device;

[1287] A response frame is received, where the response frame is used to feed back to the non-access point multi-link device context information related to synchronization between the current access point multi-link device and the target access point multi-link device.

[1288] In one possible design of this embodiment, the context information includes at least one of the following:

[1289] First context information, the first context information is information related to a block confirmation protocol context;

[1290] The second context information is information related to the security association context.

[1291] In a possible design of this embodiment, the first context information is carried in a block acknowledgement protocol context element.

[1292] In a possible design of this embodiment, the second context information is carried in a security association context element.

[1293] Block confirmation protocol context elements:

[1294] In a possible design of this embodiment, the block acknowledgment protocol context may also be described as a block acknowledgment protocol scenario (Block Ack context), a block acknowledgment context, or a block acknowledgment scenario, which is information about the maintained block acknowledgment process.

[1295] In one possible design of this embodiment, the block acknowledgment protocol context element includes block acknowledgment protocol context or state information that the specified MLD has established and maintained with one or more peer MLDs (i.e., non-access point multi-link devices). The block acknowledgment protocol context element includes a block acknowledgment protocol context parameter control field, which is used to indicate at least one of the following:

[1296] The device where the block confirmation protocol context element is located;

[1297] Whether the device containing the block acknowledgement protocol context element and the non-access point multi-link device for which the block acknowledgement protocol context is targeted are the same device;

[1298] If the device containing the block acknowledgment protocol context element and the non-access point multi-link device targeted by the block acknowledgment protocol context are the same device, the non-access point multi-link device targeted by the block acknowledgment protocol context;

[1299] • The number of Block Acknowledgement Protocol Context Parameter Sets included in the Block Acknowledgement Protocol Context element.

[1300] In a possible design of this embodiment, the device where the block acknowledgement protocol context element is located is a current access point multi-link device.

[1301] Figure 11 shows a schematic diagram of a block acknowledgment protocol context element format provided by an exemplary embodiment of the present application. The block acknowledgment protocol context element format includes at least one of the following: an element ID field, a length field, an element ID extension field, a block acknowledgment protocol context parameter control field, and a block acknowledgment protocol context parameter set list field. In the embodiment of the present application, a domain and a field have the same meaning, and a subdomain and a field have the same meaning.

[1302] Among them, the element ID field occupies 1 byte, the length field occupies 1 byte, the element ID extension field occupies 1 byte, the block confirmation protocol context parameter control field occupies 9 or 15 bytes, and the block confirmation protocol context parameter set list field occupies a variable number of bytes.

[1303] Regarding the above-mentioned block acknowledgment protocol context parameter control field, Figure 12 shows a format diagram of the block acknowledgment protocol context parameter control field provided by an exemplary embodiment of the present application. The block acknowledgment protocol context parameter control field includes at least one of the following: MLD MAC address field, whether the opposite MLD is the same MLD field, the opposite MLD MAC address field, the number of single block acknowledgment protocol context parameter sets field, and a reserved field.

[1304] The MLD MAC address field occupies 48 bits, whether the peer MLD is the same MLD field occupies 1 bit, the peer MLD MAC address field occupies 0 or 48 bits, the single block confirmation protocol context parameter set number field occupies 16 bits, and the reserved field occupies 7 bits.

[1305] The MLD MAC address field indicates the MAC address of the MLD where the block acknowledgment protocol context described by the block acknowledgment protocol context element is located. The MLD MAC address may be the MLD address of a roaming MLD.

[1306] The "Whether the opposite-end MLD is the same MLD" field indicates whether the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element is the same MLD. When its value is 0, it indicates that the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation context scenario element is the same MLD; when its value is 1, it indicates that the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element is multiple MLDs. Alternatively, when its value is 1, it indicates that the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation context scenario element is the same MLD; when its value is 0, it indicates that the opposite-end MLD targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element is multiple MLDs. This is not limited in the embodiments of the present application.

[1307] The peer MLD MAC address indicates the MAC address of the peer MLD for the block acknowledgment protocol context described by the block acknowledgment protocol context element. When its value is 0, the peer MLD MAC address field is present in the block acknowledgment protocol context parameter control field; when its value is 1, the peer MLD MAC address field is not present in the block acknowledgment protocol context parameter control field. Alternatively, when its value is 1, the peer MLD MAC address field is present in the block acknowledgment protocol context parameter control field; when its value is 0, the peer MLD MAC address field is not present in the block acknowledgment protocol context parameter control field. This is not limited in this embodiment of the present application.

[1308] The Number of Single Block Acknowledgement Protocol Context Parameter Sets field is a 16-bit unsigned integer indicating the number of Single Block Acknowledgement Protocol Context Parameter Set fields in the Block Acknowledgement Protocol Context Parameter Set List field.

[1309] In a possible design of this embodiment, the block confirmation protocol context element includes a block confirmation protocol context parameter set list field, the block confirmation protocol context parameter set list field includes at least one block confirmation protocol context parameter set subfield, and a block confirmation protocol context parameter set subfield is used to indicate a block confirmation protocol context parameter set.

[1310] In one possible design of this embodiment, the block acknowledgment protocol context parameter set subfield is used to indicate at least one of the following:

[1311] The role of the device in the block acknowledgement protocol context;

[1312] Non-AP multi-link devices targeted by the Block Acknowledgement protocol context;

[1313] Block confirmation parameter set;

[1314] Block confirmation timeout value.

[1315] Regarding the above-mentioned block confirmation protocol context parameter set list field, Figure 13 shows a format diagram of the block confirmation protocol context parameter set list field provided by an exemplary embodiment of the present application. The block confirmation protocol context parameter set list field includes at least one of the following: one or more single block confirmation protocol context parameter set fields, and a padding field.

[1316] Among them, the number of bits occupied by a single block confirmation protocol context parameter set field is variable, and the number of bits occupied by the padding field is variable.

[1317] In one possible design of this embodiment, if the block acknowledgment protocol context parameter set subfield is used to indicate that the role of the device in the corresponding block acknowledgment protocol context is an initiator in the block acknowledgment protocol context, the block acknowledgment protocol context parameter set subfield is further used to indicate at least one of the following:

[1318] Send window starting sequence number;

[1319] Send window size.

[1320] In one possible design of this embodiment, if the block acknowledgment protocol context parameter set subfield is used to indicate that the device in the block acknowledgment protocol context has a role as a receiver in the block acknowledgment protocol context, the block acknowledgment protocol context parameter set subfield is further used to indicate at least one of the following:

[1321] Receive buffer starting sequence number;

[1322] Receive window size;

[1323] Record the starting sequence number of the bitmap;

[1324] Record the maximum sequence number of the bitmap;

[1325] Record the bitmap size.

[1326] For the above-mentioned single block acknowledgment protocol context parameter set field, when the MLD where the block acknowledgment protocol context is located is the initiator MLD role, Figure 14 shows a format diagram of a single block acknowledgment protocol context parameter set field provided by an exemplary embodiment of the present application. The single block acknowledgment protocol context parameter set field includes at least one of the following: MLD role field (initiator MLD), peer MLD (Peer MLD) field, block acknowledgment parameter set (Block Ack Parameter Set) field, block acknowledgment timeout value (Block Ack Timeout) field, send window starting sequence number (WinStartO) field, and send window size (WinSizeO) field.

[1327] Among them, the MLD role field (initiator MLD) occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the block confirmation parameter set field occupies 16 bits, the block confirmation timeout value field occupies 8 bits, the send window starting sequence number field occupies 12 bits, and the send window size field occupies 10 bits.

[1328] In the case where the MLD where the block acknowledgment protocol context is located is the receiver MLD role, Figure 15 shows a format diagram of a single block acknowledgment protocol context parameter set field provided by an exemplary embodiment of the present application. The single block acknowledgment protocol context parameter set field includes at least one of the following: MLD role field (receiver MLD), peer MLD (Peer MLD) field, block acknowledgment parameter set (Block Ack Parameter Set) field, block acknowledgment timeout value (Block Ack Timeout) field, receive buffer start sequence number (WinStartB) field, receive window size (WinSizeB) field, record bitmap start sequence number (WinStartR) field, record bitmap maximum sequence number (WinEndR) field, and record bitmap size (WinSizeR) field.

[1329] Among them, the MLD role field (receiver MLD) occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the block confirmation parameter set field occupies 48 bits, the block confirmation timeout value field occupies 16 bits, the receive buffer starting sequence number field occupies 12 bits, the receive window size field occupies 10 bits, the record bitmap starting sequence number field occupies 12 bits, the record bitmap maximum sequence number field occupies 12 bits, and the record bitmap size field occupies 10 bits.

[1330] The MLD role field indicates the role played by the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located in the block confirmation protocol. Exemplarily, when the value of the MLD role field is 0, it indicates that the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located plays the role of the initiator MLD in the block confirmation protocol; when the value of the MLD role field is 1, it indicates that the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located plays the role of the receiver MLD in the block confirmation protocol. Alternatively, when the value of the MLD role field is 1, it indicates that the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located plays the role of the initiator MLD in the block confirmation protocol; when the value of the MLD role field is 0, it indicates that the MLD where the block confirmation protocol context described by a single block confirmation protocol context parameter set is located plays the role of the receiver MLD in the block confirmation protocol.

[1331] When the MLD where the block confirmation protocol context is located is the initiator role, the format of a single block confirmation protocol context parameter set is shown in Figure 14. When the MLD where the block confirmation protocol context is located is the receiver role, the format of a single block confirmation protocol context parameter set is shown in Figure 15.

[1332] The peer MLD field indicates the MAC address of the peer MLD for which the block acknowledgment p...

Claims

1. A switching method, characterized in that: The method is performed by a non-access point multi-link device non-AP MLD, and the method includes: At least one first frame is sent and / or received, where the at least one first frame is used to implement switching between two access point multi-link devices AP MLD at different locations based on link reconfiguration.

2. The method according to claim 1, characterized in that The two AP MLDs belong to the same mobility domain MLD, or the two AP MLDs belong to the same mobility domain.

3. The method according to claim 1 or 2, characterized in that: The two AP MLDs belong to the same mobility domain MLD, and the mobility domain MLD is used for at least one of the following: Providing a connection service between the non-AP MLD or the two AP MLDs and a distributed system DS; Maintaining data continuity of the non-AP MLD switching between the two AP MLDs during roaming; Authentication and / or association or re-association of the non-AP MLD; The security association of the non-AP MLD; Distribution of all or part of the security association information of the non-AP MLD; Synchronization of all or part of the status and / or buffer information of the upper layers of the medium access control MAC of the two AP MLD upper layers; Managing the distribution of authentication information of the non-AP MLD link; managing an AP MLD-level association or re-association between the non-AP MLD and the two AP MLDs; For the target AP MLD that establishes a multilink with the non-access point multilink device among the two AP MLDs, selecting a MAC corresponding to the target AP MLD for data transmission; synchronization of first data between the two AP MLDs, the first data being used to maintain data communication between the non-AP MLD and the two AP MLDs or DSs; The MLD level information is exchanged or indicated through the MAC sublayers of the two AP MLDs.

4. The method according to any one of claims 1 to 3, characterized in that: The sending and / or receiving at least one first frame comprises: Sending a link reconfiguration request frame, where the link reconfiguration request frame is used to instruct the non-AP MLD to request link reconfiguration with the two AP MLDs to achieve switching; A link reconfiguration response frame is received, where the link reconfiguration response frame is used to feed back to the non-AP MLD the link reconfiguration performed with the two AP MLDs.

5. The method according to claim 4, characterized in that The two AP MLDs include a current AP MLD and a target AP MLD; The link reconfiguration request frame includes: A first element corresponding to the current AP MLD, used to delete at least one link between the current AP MLD and the current AP MLD; The second element corresponding to the target AP MLD is used to establish at least one link with the target AP MLD.

6. The method according to claim 5, characterized in that The first element includes a first reconfiguration multilink element, which is used to describe the reconfiguration multilink information of the non-AP MLD and the current AP MLD; The second element includes a second reconfiguration multilink element, which is used to describe the reconfiguration multilink information of the non-AP MLD and the target AP MLD.

7. The method according to claim 5, characterized in that The link reconfiguration request frame also includes: The first flow identifier to link mapping element is used to perform flow identifier to link mapping on the link established with the target AP MLD.

8. The method according to claim 4, characterized in that The two AP MLDs include a current AP MLD and a target AP MLD; The link reconfiguration response frame includes: A third element corresponding to the current AP MLD, used to indicate a link reconfiguration state corresponding to the current AP MLD; The fourth element corresponding to the target AP MLD is used to indicate a link reconfiguration state corresponding to the target AP MLD.

9. The method according to claim 8, characterized in that The third element includes at least one of the following: a reconfiguration state list of the current AP MLD, including at least one reconfiguration state tuple; the number of reconfiguration state tuples of the current AP MLD; The fourth element includes at least one of the following: a reconfiguration status list of the target AP MLD, including at least one reconfiguration status element; the number of reconfiguration status tuples of the target AP MLD; The reconfiguration status element is used to indicate the reconfiguration status of a link.

10. The method according to any one of claims 5 to 9, characterized in that: The two AP MLDs belong to the same mobility domain MLD, or the two AP MLDs belong to the same mobility domain, and the method further includes: Send and / or receive first indication information, where the first indication information is used to indicate the mobility domain MLD.

11. The method according to claim 10, characterized in that The first indication information is carried in at least one of the following frames: Link reconfiguration request frame; Link reconfiguration response frame; Request frame; Response frame; Fast basic service set BSS switching FT request frame; FT response frame; FT confirmation frame; FT response frame; Association request frame; Association response frame; Reassociation request frame; Reassociation response frame; The request frame is used to indicate that the non-AP MLD requests to copy or migrate context information between the two AP MLDs to maintain data connectivity during the switching process, and the response frame is used to indicate to the non-AP MLD the result of copying or migrating context information between the two AP MLDs.

12. The method according to claim 10 or 11, characterized in that: The first indication information includes at least one of the following: Mobile domain MLD identifier; Mobility domain MLD MAC address.

13. The method according to any one of claims 5 to 9, characterized in that: The switching is based on FT, and the method further includes: Sending and / or receiving second indication information, where the second indication information is used to indicate whether to support or allow FT between two AP MLDs attached to the same mobility domain MLD.

14. The method according to claim 13, characterized in that The FT is performed between the two AP MLDs attached to the same mobility domain MLD to maintain data connectivity during the switching process.

15. The method according to claim 13, characterized in that The second indication information is carried in at least one of the following frames: Link reconfiguration request frame; Link reconfiguration response frame; Request frame; Response frame; FT request frame; FT response frame; FT confirmation frame; FT response frame; Association request frame; Association response frame; Reassociation request frame; Reassociation response frame; The request frame is used to indicate that the non-AP MLD requests to copy or migrate context information between the two AP MLDs to maintain data connectivity during the switching process, and the response frame is used to indicate to the non-AP MLD the result of copying or migrating context information between the two AP MLDs.

16. The method according to claim 13, characterized in that The link reconfiguration response frame includes: Status code, used to indicate the status code of link reconfiguration in the mobility domain MLD scenario.

17. The method according to claim 16, characterized in that When the value of the status code is the first value, it is used to indicate rejection of mobility domain link reconfiguration.

18. The method according to claim 8, characterized in that The link reconfiguration response frame includes: The group key data is used to indicate the group key of the link successfully added to the target AP MLD.

19. The method according to claim 8, characterized in that The link reconfiguration response frame includes: The basic multi-link element is used to provide a configuration file of site STA granularity for one or more subordinate APs of the target AP MLD.

20. The method according to claim 8, characterized in that The link reconfiguration response frame includes: The second flow identifier to link mapping element is used to respond to the flow identifier to link mapping performed on the link established with the target AP MLD. Mapping.

21. The method according to any one of claims 4 to 20, characterized in that: The two AP MLDs include a current AP MLD and a target AP MLD. The link reconfiguration request frame is sent to the current AP MLD and is sent by the current AP MLD to the target AP MLD.

22. The method according to any one of claims 4 to 20, characterized in that: The two AP MLDs include a current AP MLD and a target AP MLD. The link reconfiguration response frame is sent by the target AP MLD to the current AP MLD and then fed back by the current AP MLD.

23. The method according to any one of claims 1 to 22, characterized in that: The method further comprises: At least one second frame is sent and / or received, where the second frame is used to synchronize context information related to the non-AP MLD between the two AP MLDs, where the context information includes at least one of state information and buffer information.

24. The method according to claim 23, characterized in that The sending and / or receiving at least one second frame comprises: Sending a request frame, where the request frame is used to indicate that the non-AP MLD requests synchronization of context information related to the non-AP MLD between the two AP MLDs; A response frame is received, where the response frame is used to feed back to the non-AP MLD context information related to the non-AP MLD that is synchronized between the two AP MLDs.

25. The method according to claim 24, characterized in that The context information includes at least one of the following: first context information, wherein the first context information is information related to a block confirmation protocol context; The second context information is information related to a security association context.

26. The method according to claim 25, characterized in that The first context information is carried in a block confirmation protocol context element.

27. The method according to claim 26, characterized in that The block confirmation protocol context element includes a block confirmation protocol context parameter control field, and the block confirmation protocol context parameter control field is used to indicate at least one of the following: The device where the block confirmation protocol context element is located; Whether the device where the block acknowledgment protocol context element is located and the non-AP MLD targeted by the block acknowledgment protocol context are the same device; When the device where the block acknowledgment protocol context element is located and the non-AP MLD targeted by the block acknowledgment protocol context are the same device, the non-AP MLD targeted by the block acknowledgment protocol context; The block confirmation protocol context element includes the number of block confirmation protocol context parameter sets.

28. The method according to any one of claims 25 to 27, characterized in that: The block confirmation protocol context element includes a block confirmation protocol context parameter set list field, the block confirmation protocol context parameter set list field includes at least one block confirmation protocol context parameter set subfield, and one block confirmation protocol context parameter set subfield is used to indicate a block confirmation protocol context parameter set.

29. The method according to claim 28, characterized in that The block confirmation protocol context parameter set subfield is used to indicate at least one of the following: The role of the device where the block confirmation protocol context is located in the block confirmation protocol context; The non-AP MLD for which the block ACK protocol context is targeted; Block confirmation parameter set; Block confirmation timeout value.

30. The method according to claim 29, characterized in that If the block confirmation protocol context parameter set subfield is used to indicate that the role of the device where the block confirmation protocol context is located in the block confirmation protocol context is the initiator; the block confirmation protocol context parameter set subfield is also used to indicate at least one of the following: Send window starting sequence number; Send window size.

31. The method according to claim 29, characterized in that If the block confirmation protocol context parameter set subfield is used to indicate that the role of the device where the block confirmation protocol context is located in the block confirmation protocol context is a receiver; the block confirmation protocol context parameter set subfield is also used to indicate at least one of the following: Receive buffer starting sequence number; Receive window size; Record the starting sequence number of the bitmap; Record the maximum sequence number of the bitmap; Record the bitmap size.

32. The method according to any one of claims 29 to 31, characterized in that: The block confirmation parameter set includes at least one of the following: Indication information indicating whether aggregated MAC service data units are supported; Block confirmation strategy; Stream ID; Buffer size.

33. The method according to any one of claims 25 to 32, characterized in that: The second context information is carried in a security association context element.

34. The method according to claim 33, characterized in that The security association context element includes a security association context parameter control field, and the security association context parameter control field is used to indicate at least one of the following: The device where the security association context element is located; Whether the device where the security association context element is located and the non-AP MLD targeted by the security association context are the same device; When the device where the security association context element is located and the non-AP MLD targeted by the security association context are the same device, the non-AP MLD targeted by the security association context; The security association context element includes the number of security association context parameter sets.

35. The method according to claim 33 or 34, characterized in that The security association context element includes a security association context parameter set list field, the security association context parameter set list field includes at least one security association context parameter set subfield, and one of the security association context parameter set subfields is used to indicate a security association context parameter set.

36. The method according to claim 35, characterized in that The security association context parameter set subfield is used to indicate at least one of the following: The role of the device where the security association context is located in the security association context; the non-AP MLD for which the security association context is targeted; The security association type of the security association context.

37. The method according to claim 36, characterized in that If the security association context parameter set subfield is used to indicate that the role of the device where the security association context is located in the security association context is an initiator; the security association context parameter set subfield is also used to indicate at least one of the following: Replay counter number; Stream identifier TID; The count of the replay counter for the TID.

38. The method according to claim 36, characterized in that If the security association context parameter set subfield is used to indicate that the role of the device where the security association context is located in the security association context is a receiver; the security association context parameter set subfield is also used to indicate at least one of the following: Packet number counter quantity; TID; The count of the packet number counter for the TID.

39. The method according to any one of claims 23 to 38, characterized in that The second frame also includes: The third indication information is used to indicate that the context information includes information of a block confirmation protocol context and / or a security association context.

40. The method according to claim 24, characterized in that The two AP MLDs include the current AP MLD and the target AP MLD: The request frame is sent to the current AP MLD, and then sent by the current AP MLD to the target AP MLD; The response frame is sent by the target AP MLD to the current AP MLD, and then fed back by the current AP MLD.

41. The method according to claim 24, characterized in that The switching is based on FT; The request frame is an FT confirmation frame, and the response frame is an FT acknowledgement frame.

42. The method according to any one of claims 1 to 41, characterized in that: The two AP MLDs belong to the same mobility domain MLD; the method further includes: Send FT request frame; Receive FT response frame.

43. The method according to any one of claims 1 to 42, characterized in that: The method further comprises: Send an association request frame; Receive an association response frame.

44. The method according to any one of claims 1 to 43, characterized in that The switching is based on FT, When the first duration is less than or equal to the deadline of the link reconfiguration, executing the link reconfiguration; The first duration indicates the duration between the sending time of the FT request frame and the sending time of the link reconfiguration request frame, and the first frame includes the link reconfiguration request frame.

45. The method according to any one of claims 1 to 44, characterized in that The method further comprises: Send fourth indication information, where the fourth indication information is used to indicate a deadline or a timeout period for the link reconfiguration.

46. ​​The method according to claim 45, characterized in that The fourth indication information is indicated by using the start time and the timeout interval, or, The fourth indication information is indicated by using the deadline.

47. The method according to claim 46, characterized in that The start time is implicitly represented by the sending time or receiving time of the fourth indication information; The timeout interval is explicitly indicated by the fourth indication information.

48. A switching method, characterized in that: The method is performed by a current access point multi-link device AP MLD, and the method includes: At least one first frame is sent and / or received, where the at least one first frame is used to implement switching between a non-access point multi-link device non-AP MLD and the current AP MLD and the target AP MLD at different locations based on link reconfiguration.

49. The method according to claim 48, characterized in that The current AP MLD and the target AP MLD belong to the same mobility domain MLD, or the current AP MLD and the target AP MLD belong to the same mobility domain.

50. The method according to claim 48 or 49, characterized in that The current AP MLD and the target AP MLD belong to the same mobility domain MLD, and the mobility domain MLD is used for at least one of the following: Providing a connection service between the non-AP MLD or the current AP MLD and the target AP MLD and a distributed system DS; Maintaining data continuity of the non-AP MLD switching between the current AP MLD and the target AP MLD during roaming; Authentication and / or association or re-association of the non-AP MLD; The security association of the non-AP MLD; Distribution of all or part of the security association information of the non-AP MLD; Synchronize all or part of the status and / or buffer information of the upper layer of the current AP MLD and the media access control MAC of the target AP MLD; Managing the distribution of authentication information of the non-AP MLD link; Managing the association or re-association at the AP MLD level between the non-AP MLD and the current AP MLD and the target AP MLD; For the target AP MLD, select a MAC corresponding to the target AP MLD for data transmission; synchronization of first data between the current AP MLD and the target AP MLD, the first data being used to maintain data communication between the non-AP MLD and the current AP MLD and the target AP MLD or DS; The MLD level information is exchanged or indicated through the MAC sublayer of the current AP MLD and the target AP MLD.

51. The method according to any one of claims 48 to 50, characterized in that The sending and / or receiving at least one first frame comprises: receiving a link reconfiguration request frame sent by the non-AP MLD, and sending the link reconfiguration request frame to the target AP MLD, wherein the link reconfiguration request frame is used to indicate that the non-AP MLD requests to perform link reconfiguration with the current AP MLD and the target AP MLD to achieve switching; A link reconfiguration response frame is received from the target AP MLD, and the link reconfiguration response frame is sent to the non-AP MLD, wherein the link reconfiguration response frame is used to feed back to the non-AP MLD the link reconfiguration performed with the current AP MLD and the target AP MLD.

52. The method according to claim 51, characterized in that The link reconfiguration request frame includes: a first element corresponding to the current AP MLD, used to delete at least one link between the non-AP MLD and the current AP MLD; The second element corresponding to the target AP MLD is used to establish at least one link between the non-AP MLD and the target AP MLD.

53. The method according to claim 52, characterized in that The first element includes a first reconfiguration multilink element, which is used to describe the reconfiguration multilink information of the non-AP MLD and the current AP MLD; The second element includes a second reconfiguration multilink element, which is used to describe the reconfiguration multilink information of the non-AP MLD and the target AP MLD.

54. The method according to claim 52, characterized in that The link reconfiguration request frame also includes: The first flow identifier to link mapping element is used for the non-AP MLD to perform flow identifier to link mapping on the link established between the non-AP MLD and the target AP MLD.

55. The method according to claim 51, characterized in that The link reconfiguration response frame includes: A third element corresponding to the current AP MLD, used to indicate a link reconfiguration state corresponding to the current AP MLD; The fourth element corresponding to the target AP MLD is used to indicate a link reconfiguration state corresponding to the target AP MLD.

56. The method according to claim 55, characterized in that The third element includes at least one of the following: a reconfiguration state list of the current AP MLD, including at least one reconfiguration state tuple; the number of reconfiguration state tuples of the current AP MLD; The fourth element includes at least one of the following: a reconfiguration status list of the target AP MLD, including at least one reconfiguration status element; the number of reconfiguration status tuples of the target AP MLD; The reconfiguration status element is used to indicate the reconfiguration status of a link.

57. The method according to any one of claims 52 to 56, characterized in that The current AP MLD and the target AP MLD belong to the same mobility domain MLD, or the current AP MLD and the target AP MLD belong to the same mobility domain, and the method further includes: Send and / or receive first indication information, where the first indication information is used to indicate the mobility domain MLD.

58. The method according to claim 57, characterized in that The first indication information is carried in at least one of the following frames: Link reconfiguration request frame; Link reconfiguration response frame; Request frame; Response frame; Fast basic service set BSS switching FT request frame; FT response frame; FT confirmation frame; FT response frame; Association request frame; Association response frame; Reassociation request frame; Reassociation response frame; The request frame is used to indicate that the non-AP MLD requests to copy or migrate context information between the current AP MLD and the target AP MLD to maintain data connectivity during the switching process, and the response frame is used to indicate to the non-AP MLD the result of copying or migrating context information between the current AP MLD and the target AP MLD.

59. The method according to claim 57 or 58, characterized in that The first indication information includes at least one of the following: Mobile domain MLD identifier; Mobility domain MLD MAC address.

60. The method according to any one of claims 52 to 56, characterized in that The switching is based on FT, and the method further includes: Sending and / or receiving second indication information, where the second indication information is used to indicate whether to support or allow FT between the current AP MLD and the target AP MLD which are attached to the same mobility domain MLD.

61. The method according to claim 60, characterized in that FT is performed between the current AP MLD and the target AP MLD attached to the same mobility domain MLD, so as to maintain data connectivity during the switching process.

62. The method according to claim 60, characterized in that The second indication information is carried in at least one of the following frames: Link reconfiguration request frame; Link reconfiguration response frame; Request frame; Response frame; FT request frame; FT response frame; FT confirmation frame; FT response frame; Association request frame; Association response frame; Reassociation request frame; Reassociation response frame; The request frame is used to indicate that the non-AP MLD requests to copy or migrate context information between the current AP MLD and the target AP MLD to maintain data connectivity during the switching process, and the response frame is used to indicate to the non-AP MLD the result of copying or migrating context information between the current AP MLD and the target AP MLD.

63. The method according to claim 60, characterized in that The link reconfiguration response frame includes: Status code, used to indicate the status code of link reconfiguration in the mobility domain MLD scenario.

64. The method according to claim 63, characterized in that When the value of the status code is the first value, it is used to indicate rejection of mobility domain link reconfiguration.

65. The method of claim 55, wherein: The link reconfiguration response frame includes: The group key data is used to indicate the group key of the link successfully added to the target AP MLD.

66. The method of claim 55, wherein: The link reconfiguration response frame includes: The basic multi-link element is used to provide a configuration file of site STA granularity for one or more subordinate APs of the target AP MLD.

67. The method of claim 55, wherein: The link reconfiguration response frame includes: The second flow identifier to link mapping element is used to respond to the non-AP MLD performing flow identifier to link mapping on the link established between the non-AP MLD and the target AP MLD.

68. The method according to any one of claims 51 to 67, characterized in that The link reconfiguration request frame is sent by the non-AP MLD to the current AP MLD, and is sent by the current AP MLD to the target AP MLD.

69. The method according to any one of claims 51 to 67, characterized in that: The link reconfiguration response frame is sent from the target AP MLD to the current AP MLD, and then sent from the current AP MLD to the non-AP MLD.

70. The method according to any one of claims 48 to 69, characterized in that The method further comprises: Send and / or receive at least one second frame, where the second frame is used to synchronize context information related to the non-AP MLD between the current AP MLD and the target AP MLD, where the context information includes at least one of state information and buffer information.

71. The method according to claim 70, characterized in that The sending and / or receiving at least one second frame comprises: receiving a request frame sent by the non-AP MLD, and sending the request frame to the target AP MLD, wherein the request frame is used to indicate that the non-AP MLD requests synchronization of context information related to the non-AP MLD between the current AP MLD and the target AP MLD; A response frame sent by the target AP MLD is received, and the response frame is sent to the non-AP MLD, wherein the response frame is used to feed back to the non-AP MLD context information related to the non-AP MLD that is synchronized between the current AP MLD and the target AP MLD.

72. The method according to claim 71, characterized in that The context information includes at least one of the following: first context information, wherein the first context information is information related to a block confirmation protocol context; The second context information is information related to a security association context.

73. The method according to claim 72, characterized in that The first context information is carried in a block confirmation protocol context element.

74. The method according to claim 73, characterized in that The block confirmation protocol context element includes a block confirmation protocol context parameter control field, and the block confirmation protocol context parameter control field is used to indicate at least one of the following: The device where the block confirmation protocol context element is located; Whether the device where the block acknowledgment protocol context element is located and the non-AP MLD targeted by the block acknowledgment protocol context are the same device; When the device where the block acknowledgment protocol context element is located and the non-AP MLD targeted by the block acknowledgment protocol context are the same device, the non-AP MLD targeted by the block acknowledgment protocol context; The block confirmation protocol context element includes the number of block confirmation protocol context parameter sets.

75. The method according to any one of claims 72 to 74, characterized in that The block confirmation protocol context element includes a block confirmation protocol context parameter set list field, the block confirmation protocol context parameter set list field includes at least one block confirmation protocol context parameter set subfield, and one block confirmation protocol context parameter set subfield is used to indicate a block confirmation protocol context parameter set.

76. The method according to claim 75, characterized in that The block confirmation protocol context parameter set subfield is used to indicate at least one of the following: The role of the device where the block confirmation protocol context is located in the block confirmation protocol context; The non-AP MLD for which the block ACK protocol context is targeted; Block confirmation parameter set; Block confirmation timeout value.

77. The method according to claim 76, characterized in that If the block confirmation protocol context parameter set subfield is used to indicate that the role of the device where the block confirmation protocol context is located in the block confirmation protocol context is the initiator; the block confirmation protocol context parameter set subfield is also used to indicate at least one of the following: Send window starting sequence number; Send window size.

78. The method according to claim 76, characterized in that If the block confirmation protocol context parameter set subfield is used to indicate that the role of the device where the block confirmation protocol context is located in the block confirmation protocol context is a receiver; the block confirmation protocol context parameter set subfield is also used to indicate at least one of the following: Receive buffer starting sequence number; Receive window size; Record the starting sequence number of the bitmap; Record the maximum sequence number of the bitmap; Record the bitmap size.

79. The method according to any one of claims 76 to 78, characterized in that The block confirmation parameter set includes at least one of the following: Indication information indicating whether aggregated MAC service data units are supported; Block confirmation strategy; Stream ID; Buffer size.

80. The method according to any one of claims 72 to 79, characterized in that The second context information is carried in a security association context element.

81. The method according to claim 80, characterized in that The security association context element includes a security association context parameter control field, and the security association context parameter control field is used to indicate at least one of the following: The device where the security association context element is located; Whether the device where the security association context element is located and the non-AP MLD targeted by the security association context are the same device; When the device where the security association context element is located and the non-AP MLD targeted by the security association context are the same device, the non-AP MLD targeted by the security association context; The security association context element includes the number of security association context parameter sets.

82. The method according to claim 80 or 81, characterized in that The security association context element includes a security association context parameter set list field, the security association context parameter set list field includes at least one security association context parameter set subfield, and one of the security association context parameter set subfields is used to indicate a security association context parameter set.

83. The method according to claim 82, characterized in that The security association context parameter set subfield is used to indicate at least one of the following: The role of the device where the security association context is located in the security association context; the non-AP MLD for which the security association context is targeted; The security association type of the security association context.

84. The method according to claim 83, characterized in that If the security association context parameter set subfield is used to indicate that the role of the device where the security association context is located in the security association context is an initiator; the security association context parameter set subfield is also used to indicate at least one of the following: Replay counter number; Stream identifier TID; The count of the replay counter for the TID.

85. The method according to claim 83, characterized in that If the security association context parameter set subfield is used to indicate that the role of the device where the security association context is located in the security association context is a receiver; the security association context parameter set subfield is also used to indicate at least one of the following: Packet number counter quantity; TID; The count of the packet number counter for the TID.

86. The method according to any one of claims 70 to 85, characterized in that The second frame also includes: The third indication information is used to indicate that the context information includes information of a block confirmation protocol context and / or a security association context.

87. The method according to claim 71, characterized in that The request frame is sent by the non-AP MLD to the current AP MLD, and then sent by the current AP MLD to the target AP MLD; The response frame is sent from the target AP MLD to the current AP MLD, and then sent from the current AP MLD to the non-AP MLD.

88. The method of claim 71, wherein: The switching is based on FT; The request frame is an FT confirmation frame, and the response frame is an FT acknowledgement frame.

89. The method according to any one of claims 48 to 88, characterized in that The current AP MLD and the target AP MLD belong to the same mobility domain MLD, and the method further includes: receiving an FT request frame sent by the non-AP MLD, and sending the FT request frame to the target AP MLD; receiving an FT response frame sent by the target AP MLD, and sending the FT response frame to the non-AP MLD.

90. The method according to any one of claims 48 to 89, characterized in that The method further comprises: receiving an association request frame sent by the non-AP MLD, and sending the association request frame to the target AP MLD; receiving an association response frame sent by the target AP MLD, and sending the association response frame to the non-AP MLD.

91. The method according to any one of claims 48 to 90, characterized in that The switching is based on FT, In a case where the first duration is less than or equal to a deadline for link reconfiguration, the link reconfiguration is performed by the non-AP MLD; The first duration indicates the duration between the sending time of the FT request frame and the sending time of the link reconfiguration request frame, and the first frame includes the link reconfiguration request frame.

92. The method according to any one of claims 48 to 91, characterized in that The method further comprises: Receive fourth indication information, where the fourth indication information is used to indicate a deadline or a timeout period for the link reconfiguration.

93. The method according to claim 92, characterized in that The fourth indication information is indicated by using the start time and the timeout interval, or, The fourth indication information is indicated by using the deadline.

94. The method according to claim 93, characterized in that The start time is implicitly represented by the sending time or receiving time of the fourth indication information; The timeout interval is explicitly indicated by the fourth indication information.

95. The method according to any one of claims 48 to 94, characterized in that The method further comprises: In the case where the target AP MLD agrees to establish at least one link, the current AP MLD agrees to delete all links; In the case that the target AP MLD refuses to establish all links, the current AP MLD refuses to delete at least one link.

96. The method according to claim 95, characterized in that The current AP MLD agrees to delete all links when the target AP MLD agrees to establish at least one link, including: In the case that the target AP MLD agrees to establish at least one link, the current AP MLD agrees to delete all links except the link required to be retained.

97. A switching method, characterized in that: The method is performed by a target access point multi-link device AP MLD, and the method includes: At least one first frame is sent and / or received, where the at least one first frame is used to implement switching between a non-access point multi-link device non-AP MLD and a current AP MLD at different locations and the target AP MLD based on link reconfiguration.

98. The method according to claim 97, characterized in that The current AP MLD and the target AP MLD belong to the same mobility domain MLD, or the current AP MLD and the target AP MLD belong to the same mobility domain.

99. The method according to claim 97 or 98, characterized in that The current AP MLD and the target AP MLD belong to the same mobility domain MLD, and the mobility domain MLD is used for at least one of the following: Providing a connection service between the non-AP MLD or the current AP MLD and the target AP MLD and a distributed system DS; Maintaining data continuity of the non-AP MLD switching between the current AP MLD and the target AP MLD during roaming; Authentication and / or association or re-association of the non-AP MLD; The security association of the non-AP MLD; Distribution of all or part of the security association information of the non-AP MLD; Synchronize all or part of the status and / or buffer information of the upper layer of the current AP MLD and the media access control MAC of the target AP MLD; Managing the distribution of authentication information of the non-AP MLD link; Managing the association or re-association at the AP MLD level between the non-AP MLD and the current AP MLD and the target AP MLD; For the target AP MLD, select a MAC corresponding to the target AP MLD for data transmission; synchronization of first data between the current AP MLD and the target AP MLD, the first data being used to maintain data communication between the non-AP MLD and the current AP MLD and the target AP MLD or DS; The MLD level information is exchanged or indicated through the MAC sublayer of the current AP MLD and the target AP MLD.

100. The method according to any one of claims 97 to 99, characterized in that: The sending and / or receiving at least one first frame comprises: receiving a link reconfiguration request frame sent by the current AP MLD, wherein the link reconfiguration request frame is used to instruct the non-AP MLD to request link reconfiguration with the current AP MLD and the target AP MLD to achieve switching; A link reconfiguration response frame is sent to the current AP MLD, where the link reconfiguration response frame is used to feed back to the non-AP MLD the link reconfiguration performed with the current AP MLD and the target AP MLD.

101. The method according to claim 100, characterized in that The link reconfiguration request frame includes: a first element corresponding to the current AP MLD, used to delete at least one link between the non-AP MLD and the current AP MLD; The second element corresponding to the target AP MLD is used to establish at least one relationship between the non-AP MLD and the target AP MLD. A link.

102. The method according to claim 101, characterized in that The first element includes a first reconfiguration multilink element, which is used to describe the reconfiguration multilink information of the non-AP MLD and the current AP MLD; The second element includes a second reconfiguration multilink element, which is used to describe the reconfiguration multilink information of the non-AP MLD and the target AP MLD.

103. The method according to claim 101, characterized in that The link reconfiguration request frame also includes: The first flow identifier to link mapping element is used for the non-AP MLD to perform flow identifier to link mapping on the link established between the non-AP MLD and the target AP MLD.

104. The method according to claim 100, characterized in that The link reconfiguration response frame includes: A third element corresponding to the current AP MLD, used to indicate a link reconfiguration state corresponding to the current AP MLD; The fourth element corresponding to the target AP MLD is used to indicate a link reconfiguration state corresponding to the target AP MLD.

105. The method according to claim 104, characterized in that The third element includes at least one of the following: a reconfiguration state list of the current AP MLD, including at least one reconfiguration state tuple; the number of reconfiguration state tuples of the current AP MLD; The fourth element includes at least one of the following: a reconfiguration status list of the target AP MLD, including at least one reconfiguration status element; the number of reconfiguration status tuples of the target AP MLD; The reconfiguration status element is used to indicate the reconfiguration status of a link.

106. The method according to any one of claims 101 to 105, characterized in that: The current AP MLD and the target AP MLD belong to the same mobility domain MLD, or the current AP MLD and the target AP MLD belong to the same mobility domain, and the method further includes: Send and / or receive first indication information, where the first indication information is used to indicate the mobility domain MLD.

107. The method according to claim 106, characterized in that The first indication information is carried in at least one of the following frames: Link reconfiguration request frame; Link reconfiguration response frame; Request frame; Response frame; Fast basic service set BSS switching FT request frame; FT response frame; FT confirmation frame; FT response frame; Association request frame; Association response frame; Reassociation request frame; Reassociation response frame; The request frame is used to indicate that the non-AP MLD requests to copy or migrate context information between the current AP MLD and the target AP MLD to maintain data connectivity during the switching process, and the response frame is used to indicate to the non-AP MLD the result of copying or migrating context information between the current AP MLD and the target AP MLD.

108. The method according to claim 106 or 107, characterized in that The first indication information includes at least one of the following: Mobile domain MLD identifier; Mobility domain MLD MAC address.

109. The method according to any one of claims 101 to 105, characterized in that: The switching is based on FT, and the method further includes: Sending and / or receiving second indication information, where the second indication information is used to indicate whether to support or allow FT between the current AP MLD and the target AP MLD which are attached to the same mobility domain MLD.

110. The method according to claim 109, characterized in that FT is performed between the current AP MLD and the target AP MLD attached to the same mobility domain MLD, so as to maintain data connectivity during the switching process.

111. The method according to claim 109, characterized in that The second indication information is carried in at least one of the following frames: Link reconfiguration request frame; Link reconfiguration response frame; Request frame; Response frame; FT request frame; FT response frame; FT confirmation frame; FT response frame; Association request frame; Association response frame; Reassociation request frame; Reassociation response frame; The request frame is used to indicate that the non-AP MLD requests to copy or migrate context information between the current AP MLD and the target AP MLD to maintain data connectivity during the switching process, and the response frame is used to indicate to the non-AP MLD the result of copying or migrating context information between the current AP MLD and the target AP MLD.

112. The method according to claim 109, characterized in that The link reconfiguration response frame includes: Status code, used to indicate the status code of link reconfiguration in the mobility domain MLD scenario.

113. The method according to claim 112, characterized in that When the value of the status code is the first value, it is used to indicate rejection of mobility domain link reconfiguration.

114. The method according to claim 104, characterized in that The link reconfiguration response frame includes: The group key data is used to indicate the group key of the link successfully added to the target AP MLD.

115. The method according to claim 104, characterized in that The link reconfiguration response frame includes: The basic multi-link element is used to provide a configuration file of site STA granularity for one or more subordinate APs of the target AP MLD.

116. The method according to claim 104, characterized in that The link reconfiguration response frame includes: The second flow identifier to link mapping element is used to respond to the non-AP MLD performing flow identifier to link mapping on the link established between the non-AP MLD and the target AP MLD.

117. The method according to any one of claims 100 to 116, characterized in that: The link reconfiguration request frame is sent by the non-AP MLD to the current AP MLD, and is sent by the current AP MLD to the target AP MLD.

118. The method according to any one of claims 100 to 116, characterized in that: The link reconfiguration response frame is sent from the target AP MLD to the current AP MLD, and then sent from the current AP MLD to the non-AP MLD.

119. The method according to any one of claims 97 to 118, characterized in that: The method further comprises: Send and / or receive at least one second frame, where the second frame is used to synchronize context information related to the non-AP MLD between the current AP MLD and the target AP MLD, where the context information includes at least one of state information and buffer information.

120. The method according to claim 119, characterized in that The sending and / or receiving at least one second frame comprises: receiving a request frame sent by the current AP MLD, where the request frame is used to indicate that the non-AP MLD requests synchronization of context information related to the non-AP MLD between the current AP MLD and the target AP MLD; A response frame is sent to the current AP MLD, where the response frame is used to feed back to the non-AP MLD context information related to the non-AP MLD that is synchronized between the current AP MLD and the target AP MLD.

121. The method according to claim 120, characterized in that The context information includes at least one of the following: first context information, wherein the first context information is information related to a block confirmation protocol context; The second context information is information related to a security association context.

122. The method according to claim 121, characterized in that The first context information is carried in a block confirmation protocol context element.

123. The method according to claim 122, characterized in that The block confirmation protocol context element includes a block confirmation protocol context parameter control field, and the block confirmation protocol context parameter control field is used to indicate at least one of the following: The device where the block confirmation protocol context element is located; Whether the device where the block acknowledgment protocol context element is located and the non-AP MLD targeted by the block acknowledgment protocol context are the same device; When the device where the block acknowledgment protocol context element is located and the non-AP MLD targeted by the block acknowledgment protocol context are the same device, the non-AP MLD targeted by the block acknowledgment protocol context; The block confirmation protocol context element includes the number of block confirmation protocol context parameter sets.

124. The method according to any one of claims 121 to 123, characterized in that: The block confirmation protocol context element includes a block confirmation protocol context parameter set list field, the block confirmation protocol context parameter set list field includes at least one block confirmation protocol context parameter set subfield, and one block confirmation protocol context parameter set subfield is used to indicate a block confirmation protocol context parameter set.

125. The method according to claim 124, characterized in that The block confirmation protocol context parameter set subfield is used to indicate at least one of the following: The role of the device where the block confirmation protocol context is located in the block confirmation protocol context; The non-AP MLD for which the block ACK protocol context is targeted; Block confirmation parameter set; Block confirmation timeout value.

126. The method according to claim 125, characterized in that If the block confirmation protocol context parameter set subfield is used to indicate that the role of the device where the block confirmation protocol context is located in the block confirmation protocol context is the initiator; the block confirmation protocol context parameter set subfield is also used to indicate at least one of the following: Send window starting sequence number; Send window size.

127. The method according to claim 125, characterized in that If the block confirmation protocol context parameter set subfield is used to indicate that the role of the device where the block confirmation protocol context is located in the block confirmation protocol context is a receiver; the block confirmation protocol context parameter set subfield is also used to indicate at least one of the following: Receive buffer starting sequence number; Receive window size; Record the starting sequence number of the bitmap; Record the maximum sequence number of the bitmap; Record the bitmap size.

128. The method according to any one of claims 125 to 127, characterized in that The block confirmation parameter set includes at least one of the following: Indication information indicating whether aggregated MAC service data units are supported; Block confirmation strategy; Stream ID; Buffer size.

129. The method according to any one of claims 121 to 128, characterized in that The second context information is carried in a security association context element.

130. The method according to claim 129, characterized in that The security association context element includes a security association context parameter control field, and the security association context parameter control field is used to indicate at least one of the following: The device where the security association context element is located; Whether the device where the security association context element is located and the non-AP MLD targeted by the security association context are the same device; When the device where the security association context element is located and the non-AP MLD targeted by the security association context are the same device, the non-AP MLD targeted by the security association context; The security association context element includes the number of security association context parameter sets.

131. The method according to claim 129 or 130, characterized in that The security association context element includes a security association context parameter set list field, the security association context parameter set list field includes at least one security association context parameter set subfield, and one of the security association context parameter set subfields is used to indicate a security association context parameter set.

132. The method according to claim 131, characterized in that The security association context parameter set subfield is used to indicate at least one of the following: The role of the device where the security association context is located in the security association context; the non-AP MLD for which the security association context is targeted; The security association type of the security association context.

133. The method according to claim 132, characterized in that If the security association context parameter set subfield is used to indicate that the role of the device where the security association context is located in the security association context is an initiator; the security association context parameter set subfield is also used to indicate at least one of the following: Replay counter number; Stream identifier TID; The count of the replay counter for the TID.

134. The method according to claim 133, characterized in that If the security association context parameter set subfield is used to indicate that the role of the device where the security association context is located in the security association context is a receiver; the security association context parameter set subfield is also used to indicate at least one of the following: Packet number counter quantity; TID; The count of the packet number counter for the TID.

135. The method according to any one of claims 119 to 134, characterized in that: The second frame also includes: The third indication information is used to indicate that the context information includes a block confirmation protocol context and / or a security association context. Text information.

136. The method according to claim 120, characterized in that The request frame is sent by the non-AP MLD to the current AP MLD, and then sent by the current AP MLD to the target AP MLD; The response frame is sent from the target AP MLD to the current AP MLD, and then sent from the current AP MLD to the non-AP MLD.

137. The method according to claim 120, characterized in that The switching is based on fast BSS switching FT; The request frame is an FT confirmation frame, and the response frame is an FT acknowledgement frame.

138. The method according to any one of claims 97 to 137, characterized in that: The current AP MLD and the target AP MLD belong to the same mobility domain MLD, and the method further includes: Receiving an FT request frame sent by the current AP MLD; Send an FT response frame to the current AP MLD.

139. The method according to any one of claims 97 to 138, characterized in that: The method further comprises: Receiving an association request frame sent by the current AP MLD; Send an association response frame to the current AP MLD.

140. The method according to any one of claims 97 to 139, characterized in that: The switching is based on FT, In a case where the first duration is less than or equal to a deadline for link reconfiguration, the link reconfiguration is performed by the non-AP MLD; The first duration indicates the duration between the sending time of the FT request frame and the sending time of the link reconfiguration request frame, and the first frame includes the link reconfiguration request frame.

141. The method according to any one of claims 97 to 140, characterized in that The method further comprises: Receive fourth indication information, where the fourth indication information is used to indicate a deadline or a timeout period for the link reconfiguration.

142. The method according to claim 141, characterized in that The fourth indication information is indicated by using the start time and the timeout interval, or, The fourth indication information is indicated by using the deadline.

143. The method according to claim 142, characterized in that The start time is implicitly represented by the sending time or receiving time of the fourth indication information; The timeout interval is explicitly indicated by the fourth indication information.

144. A non-access point multi-link device, characterized in that: The device comprises: The transmission module is used to send and / or receive at least one first frame, where the at least one first frame is used to implement switching between two access point multi-link devices at different locations based on link reconfiguration.

145. A current access point multi-link device, characterized in that: The device comprises: The transmission module is used to send and / or receive at least one first frame, wherein the at least one first frame is used to implement switching between a non-access point multi-link device and a current access point multi-link device and a target access point multi-link device at different locations based on link reconfiguration.

146. A target access point multi-link device, characterized in that: The device comprises: The transmission module is used to send and / or receive at least one first frame, wherein the at least one first frame is used to implement switching between a non-access point multi-link device and a current access point multi-link device and a target access point multi-link device at different locations based on link reconfiguration.

147. A non-access point multi-link device, characterized in that: The non-access point multi-link device comprises: processor; a transceiver connected to the processor; a memory for storing executable instructions for the processor; Wherein, the processor is configured to load and execute the executable instructions to implement the switching method as described in any one of claims 1 to 47.

148. A current access point multi-link device, characterized in that: The current access point multi-link device comprises: processor; a transceiver connected to the processor; a memory for storing executable instructions for the processor; Wherein, the processor is configured to load and execute the executable instructions to implement the switching method as described in any one of claims 48 to 96.

149. A target access point multi-link device, characterized in that: The target access point multi-link device comprises: processor; a transceiver connected to the processor; a memory for storing executable instructions for the processor; Wherein, the processor is configured to load and execute the executable instructions to implement the switching method as described in any one of claims 97 to 143.

150. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one program, and the at least one program is loaded and executed by the processor to implement the switching method as described in any one of claims 1 to 143.

151. A computer program product, characterized in that The computer program product includes computer instructions, which are stored in a computer-readable storage medium. The processor obtains the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to implement the switching method as described in any one of claims 1 to 143.

Images