Switching method, device, equipment, medium and program product

Abstract

The invention discloses a switching method and device, equipment, a medium and a program product, and belongs to the field of Wi-Fi. The method is executed by a non-AP MLD, and the method comprises the steps of sending and / or receiving at least one first frame, and the at least one first frame is used for realizing switching between two AP MLDs at different positions based on link reconfiguration. According to the method, at least one first frame is sent and / or received, and the at least one first frame is used for realizing switching between two AP MLDs at different positions based on link reconfiguration, so that a link reconfiguration protocol between the two AP MLDs at different positions is optimized, and switching of a non-AP MLD between the two AP MLDs in a communication process is realized.

Description

[0001] Case Analysis This application is a divisional application of Chinese patent application number 202380097937.2, which entered the Chinese national phase of PCT international patent application PCT / CN2023 / 110849, filed on August 2, 2023, and entitled "Switching Method, Apparatus, Device, Medium and Program Product". Technical Field

[0002] This application relates to the field of Wireless-Fidelity (Wi-Fi), and particularly to a switching method, apparatus, device, medium, and program product. Background Technology

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

[0004] Related technologies offer Fast Basic Service Set (BSS) Transition (FT). Fast BSS Transition can reduce the duration of lost connectivity between a site (STA) and the distribution system (DS), or between a non-AP multi-link device (non-AP MLD) and the DS, during BSS transition. However, since the STA (or non-AP MLD) needs to re-associate and re-establish data transmission protocols and scenarios when switching to the target AP or target AP MLD, it is impossible to maintain data continuity between the STA and the DS, or between the non-AP MLD and the DS. Summary of the Invention

[0005] This application provides a switching method, apparatus, device, medium, and program product, the technical solution of which includes at least: According to one aspect of the embodiments of this application, a switching method is provided, the method being performed by a non-AP MLD, the method comprising: Send and / or receive at least one first frame, the first frame being used to enable handover between two AP MLDs in different locations based on link reconfiguration.

[0006] According to another aspect of the embodiments of this application, a switching method is provided, the method being executed by the current AP MLD, the method comprising: Send and / or receive at least one first frame, the first frame being used to enable switching between a non-AP MLD and a current AP MLD and a target AP MLD at different locations based on link reconfiguration.

[0007] According to another aspect of the embodiments of this application, a switching method is provided, the method being performed by a target AP MLD, the method comprising: Send and / or receive at least one first frame, the first frame being used to enable switching between a non-AP MLD and a current AP MLD and a target AP MLD at different locations based on link reconfiguration.

[0008] According to another aspect of the embodiments of this application, a non-access point multi-link device is provided, the device comprising: A transmission module for sending and / or receiving at least one first frame, wherein the at least one first frame is used to enable switching between two access point multi-link devices at different locations based on link reconfiguration.

[0009] According to another aspect of the embodiments of this application, a current access point multi-link device is provided, the device comprising: 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 enable switching between a non-access point multilink device and a current access point multilink device and a target access point multilink device at different locations based on link reconfiguration.

[0010] According to another aspect of the embodiments of this application, a target access point multi-link device is provided, the device comprising: 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 enable switching between a non-access point multilink device and a current access point multilink device and a target access point multilink device at different locations based on link reconfiguration.

[0011] According to another aspect of the embodiments of this application, a non-access point multi-link device is provided, the non-access point multi-link device comprising: processor; A transceiver connected to the processor; Memory used to store the processor's executable instructions; The processor is configured to load and execute executable instructions to implement the switching methods described above.

[0012] According to another aspect of the embodiments of this application, a current access point multi-link device is provided, the current access point multi-link device comprising: processor; A transceiver connected to the processor; Memory used to store the processor's executable instructions; The processor is configured to load and execute executable instructions to implement the switching methods described above.

[0013] According to another aspect of the embodiments of this application, a target access point multi-link device is provided, the target access point multi-link device comprising: processor; A transceiver connected to the processor; Memory used to store the processor's executable instructions; The processor is configured to load and execute executable instructions to implement the switching methods described above.

[0014] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, which stores at least one program that is loaded and executed by a processor to implement the switching methods as described above.

[0015] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium, a processor retrieving the computer instructions from the computer-readable storage medium, and the processor executing the computer instructions to implement the switching methods as described above.

[0016] The technical solutions provided in this application embodiment may include the following beneficial effects: This method optimizes the link reconfiguration protocol between two AP MLDs in different locations by sending and / or receiving at least one first frame, which is used to achieve switching between two AP MLDs in different locations based on link reconfiguration, and realizes the switching of non-AP MLDs between two AP MLDs during communication. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A schematic diagram of a communication system provided in an exemplary embodiment of this application is shown; Figure 2 A schematic diagram illustrating a method for establishing multiple links provided by related technologies is shown; Figure 3A schematic diagram of the connection between the logical AP MLD and the STA provided by the related technology is shown; Figure 4 A flowchart illustrating a switching method provided in an exemplary embodiment of this application is shown; Figure 5 A flowchart illustrating a switching method provided in an exemplary embodiment of this application is shown; Figure 6 A schematic diagram of the high-level architecture of a mobile domain MLD and its associated AP MLD provided in an exemplary embodiment of this application is shown; Figure 7 This illustration shows a schematic diagram of a reconfigurable state list subdomain format provided in an exemplary embodiment of this application; Figure 8 A schematic diagram of a group key data subfield format provided in an exemplary embodiment of this application is shown; Figure 9 A schematic diagram of a mobile domain element format provided in an exemplary embodiment of this application is shown; Figure 10 This illustration shows a schematic diagram of the FT capability and policy field format provided in an exemplary embodiment of this application; Figure 11 A schematic diagram of the block confirmation protocol context element format provided in an exemplary embodiment of this application is shown; Figure 12 This illustration shows a schematic diagram of the format of the block confirmation protocol context parameter control field provided in an exemplary embodiment of this application; Figure 13 This illustration shows a schematic diagram of the format of the block confirmation protocol context parameter set list field provided in an exemplary embodiment of this application; Figure 14 This illustration shows a schematic diagram of the format of a single block acknowledgment protocol context parameter set field provided in an exemplary embodiment of this application; Figure 15 This illustration shows a schematic diagram of the format of a single block acknowledgment protocol context parameter set field provided in an exemplary embodiment of this application; Figure 16 This illustration shows a schematic diagram of the format of the block confirmation parameter set field provided in an exemplary embodiment of this application; Figure 17 This illustration shows a schematic diagram of a security association context element format provided in an exemplary embodiment of this application; Figure 18 This illustration shows a schematic diagram of the format of a security association context parameter control field provided in an exemplary embodiment of this application; Figure 19 This illustration shows a schematic diagram of the format of a security association context parameter set list field provided in an exemplary embodiment of this application; Figure 20 This illustration shows a schematic diagram of the format of a security association context parameter set field provided in an exemplary embodiment of this application; Figure 21 This illustration shows a schematic diagram of the format of a security association context parameter set field provided in an exemplary embodiment of this application; Figure 22 A schematic diagram of a timeout interval element format provided in an exemplary embodiment of this application is shown; Figure 23 A flowchart illustrating a switching method provided in an exemplary embodiment of this application is shown; Figure 24 A flowchart illustrating a switching method provided in an exemplary embodiment of this application is shown; Figure 25 A flowchart illustrating a switching method provided in an exemplary embodiment of this application is shown; Figure 26 A flowchart illustrating a switching method provided in an exemplary embodiment of this application is shown; Figure 27 A flowchart illustrating a switching method provided in an exemplary embodiment of this application is shown; Figure 28 A block diagram of a non-access point multilink apparatus provided in an exemplary embodiment of this application is shown; Figure 29 A block diagram of a current access point multilink device provided in an exemplary embodiment of this application is shown; Figure 30 A block diagram of a target access point multilink apparatus provided in an exemplary embodiment of this application is shown; Figure 31 This illustration shows a 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 in an exemplary embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. Exemplary embodiments will be described in detail here, examples of which are illustrated 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 this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0020] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also 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 includes any and all possible combinations of one or more of the associated listed items.

[0021] 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 used only to distinguish information of the same type from one another. 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 "when," "when," or "in response to determination."

[0022] Figure 1 A schematic diagram of a communication system 10 provided in an exemplary embodiment of this application is shown. The communication system 10 includes terminals interacting with each other, or terminals interacting with network devices, or APs interacting with STAs; however, this embodiment of the application does not limit the specific interactions. In this embodiment, the communication system 10 is illustrated as including a mobile domain MLD 110 (AP) and a non-AP MLD 120 (STA), wherein the mobile domain MLD 110 includes the current AP MLD 111 and the target AP MLD 112.

[0023] In some scenarios, an AP can be called an AP STA, meaning that in a sense, an AP is also a type of STA. In other scenarios, a STA can be called a non-AP STA.

[0024] In some embodiments, the STA may include AP STA and non-AP STA.

[0025] Communication in a communication system can be between an AP and a non-AP STA, between two non-AP STAs, or between a STA and a peer STA. A peer STA can refer to a device that communicates with the STA from the other end. For example, a peer STA may be an AP or a non-AP STA.

[0026] An access point (AP) acts as a bridge connecting wired and wireless networks. Its main function is to connect various wireless network clients together and then connect the wireless network to the Ethernet. AP devices can be terminal devices with Wi-Fi chips (such as mobile phones) or network devices (such as routers).

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

[0028] AP and non-AP STA can be devices used in vehicle networking, 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.

[0029] In some embodiments, the non-AP STA may support, but is not limited to, the 802.11be standard. The non-AP STA may also support various current and future 802.11 family of Wireless Local Area Network (WLAN) standards, such as 802.11ax, 802.11ac, 802.11n, 802.11g, 802.11b, and 802.11a.

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

[0031] In some embodiments, STA can 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 autonomous driving, vehicle 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.

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

[0033] One or more links exist between a site and an access point. In some embodiments, the site and access point support multi-band communication, for example, simultaneously communicating on the 2.4 GHz, 5 GHz, 6 GHz, and 60 GHz bands, or simultaneously communicating on different channels within the same (or different) bands, improving communication throughput and / or reliability between devices. Such devices are commonly referred to as multi-band devices, or multi-link devices (MLDs), and sometimes also as multi-link entities or multi-band entities. A multi-link device can be an access point device or a site device. If the multi-link device is an access point device, it contains one or more access points (APs); if the multi-link device is a site device, it contains one or more non-AP STAs.

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

[0035] In some embodiments, an AP may include multiple APs, and non-APs may include multiple STAs. Multiple links can be formed between the multiple APs in the AP and the multiple STAs in the non-AP, and data communication can be performed between the corresponding APs in the AP and the corresponding STAs in the non-AP through these links. Figure 1 As shown, non-AP MLD120 communicates with the current AP MLD111 via multiple links, and also communicates with the target AP MLD112 via multiple links. After being moved, non-AP MLD120 disconnects its link with the current AP MLD111 and switches to communicating only with the target AP MLD112 via multiple links.

[0036] An AP is a device deployed in a wireless local area network to provide wireless communication functions for a STA. A STA may include: User Equipment (UE), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, wireless communication equipment, user agent, or user device. Optionally, a STA may also 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 functions, computing device, or other processing device connected to a wireless modem, in-vehicle device, or wearable device. This application does not limit the scope of the embodiments described herein.

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

[0038] • Establish multiple links; Figure 2 A schematic diagram of a method for establishing multiple links provided by related technologies is shown. This method is performed by AP MLD210 and non-AP MLD220. AP MLD210 includes: AP1 supporting 2.4 GHz, AP2 supporting 5 GHz, and AP3 supporting 6 GHz. Non-AP MLD220 includes: STA1 supporting 2.4 GHz, STA2 supporting 5 GHz, and STA3 supporting 6 GHz.

[0039] The relevant standards define Multi-Link Operation (MLO) and AP MLD210 and non-AP MLD220 devices with multi-link operation capabilities. AP MLD210 and non-AP MLD220 can establish multiple links on multiple different frequency bands / channels.

[0040] like Figure 2 As shown, AP MLD210 and non-AP MLD220 establish three links on 2.4GHz, 5GHz, and 6GHz, referred to as Link 1, Link 2, and Link 3, respectively. These three links can operate simultaneously. Among them, AP1 operating on Link 1 (2.4GHz), AP2 operating on Link 2 (5GHz), and AP3 operating on Link 3 (6GHz) are referred to as affiliated APs of AP MLD210.

[0041] Similarly, STA1 operating on link 1 (2.4GHz), STA2 operating on link 2 (5GHz), and non-AP STA3 operating on link 3 (6GHz) are respectively called affiliated non-APSTAs of non-AP MLD.

[0042] • Logical AP MLD; Figure 3The diagram illustrates the connection between a logical AP MLD and a STA provided by related technologies. Multiple non-collocated APs are considered as one logical AP MLD310. When a STA connects to this logical AP MLD310, the multiple non-collocated APs can be regarded as different affiliated APs of the logical AP MLD310. This allows the logical AP MLD310 to use different affiliated APs and different links to provide services to the STA, thereby better achieving uninterrupted roaming for the STA. A logical AP MLD can also be called a mobile domain MLD.

[0043] like Figure 3 As shown, STA1 uses multiple links to connect to AP1 and AP2 respectively. When STA1 moves, the link connection to AP1 is disconnected but the link connection to AP2 is not affected. Therefore, the mobility support of STA1 is improved. STA1 can be a single STA or multiple STAs. This application embodiment does not limit this.

[0044] • Multi-link reconfiguration; If a non-AP MLD has already established a multi-link connection with an AP MLD and is associated with the AP MLD, then if the non-AP MLD updates the link through a re-association method (such as adding or deleting a link), the existing association, security, and other context information between the AP MLD and the non-AP MLD will be dismantled. This disrupts ongoing data communication on the established multi-link connection, resulting in the additional network overhead of re-establishing all context information. Therefore, relevant standards have proposed multi-link reconfiguration operations.

[0045] Multi-link reconfiguration operations include: (1) Operate from the perspective of AP MLD so that AP MLD can dynamically add or delete its affiliated APs; (2) Operations are performed from the perspective of the non-AP MLD, enabling the non-AP MLD to seamlessly add and / or delete links to the established multi-link network without requiring the non-AP MLD to re-associate with the AP MLD, i.e., to perform multi-link (re)establishment. For example, when a new affiliated AP is added to the AP MLD associated with the non-AP MLD, the non-AP MLD can add the new link to the established multi-link network through multi-link reconfiguration; similarly, the non-AP MLD can delete unused links from the established multi-link network (for whatever reason) through multi-link reconfiguration to free up resources and simplify link management.

[0046] The relevant standards define a new protected Extremely High Throughput (EHT) action frame for link reconfiguration request / response messages to support seamlessly adding and / or deleting links to existing multilinks in non-AP MLDs without requiring association or reassociation between the non-AP MLD and the peer MLD.

[0047] The addition and / or deletion of links to existing multi-link networks in a non-AP MLD is initiated by the non-AP MLD itself. Its main definitions include: (1) Enhanced Reconfiguration Multi-Link element to support adding and / or deleting links. The Reconfiguration Multi-Link element carries one or more Per-STAProfile subelements, each containing an OperationUpdate Type subfield. This subfield is set to indicate the MLO update type (including AP removal, operation parameter update, link addition, link deletion, etc.) of the link indicated by the LinkIDentifier (Link ID) subfield contained within the subfield. In the Reconfiguration Multi-Link element transmitted by the 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 the non-AP MLD, the Link ID subfield specifies the link to be reconfigured.

[0048] (2) A single link reconfiguration request frame may indicate the addition and / or deletion of links. The AP MLD may accept multiple link reconfiguration requests in part or in part, and indicate the result status of the link reconfiguration in the link reconfiguration response frame accordingly.

[0049] (3) The link reconfiguration response frame provides a Group Temporal Key (GTK) / Integrity Group Temporal Key (IGTK) / Beacon Integrity Group Temporal Key (BIGTK) for any new link added to an existing multi-link network. The MLO Key Data Encapsulation (KDE) of GTK / IGTK / BIGTK is sent in the link reconfiguration response frame. No additional message exchange is required to establish a group key for the newly added link.

[0050] (4) A new link reconfiguration notification frame is defined for AP MLD to recommend which links to add and / or delete in the associated non-AP MLD MLD settings.

[0051] Although FT can reduce the duration of lost connectivity between STA and DS or between non-AP MLD and DS during BSS handover, it cannot maintain data continuity between STA (or non-AP MLD) and DS because the STA (or non-AP MLD) needs to re-associate and re-establish the data transmission and reception protocol when switching to the target AP (or target AP MLD).

[0052] While the logical AP MLD scheme theoretically supports multiple APs located in different locations attached to a single logical AP MLD using different links to provide services to the same non-AP MLD, thus achieving uninterrupted roaming for the non-AP MLD, a significant challenge arises when multiple APs in different locations communicate with the same non-AP MLD via different links. This makes it difficult to synchronize and confirm the data communication status between the APs based on the non-AP MLD, placing high demands on the communication quality of the backhaul links between the APs.

[0053] This application proposes a link reconfiguration method for a non-AP MLD to switch from the current AP MLD to the target AP MLD. Figure 4 A flowchart of a switching method provided by an exemplary embodiment of this application is shown. The method is performed by a non-AP MLD410, a current AP MLD420, and a target AP MLD430. The method includes: Step 401: Non-AP MLD410 sends a link reconfiguration request frame to the current AP MLD420.

[0054] The link reconfiguration request frame is used to instruct the non-AP MLD410 to request link reconfiguration with the current AP MLD420 and the target AP MLD430 to achieve handover.

[0055] In some embodiments, the link reconfiguration request frame includes: 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. The second element corresponding to the target AP MLD430 is used to establish at least one link with the target AP MLD430.

[0056] In some embodiments, the first element includes a first reconfiguration multilink element for describing the reconfiguration multilink information between the non-AP MLD and the current AP MLD; The second element includes a second reconfiguration multilink element, which describes the reconfiguration multilink information for the non-AP MLD and the target AP MLD.

[0057] In some embodiments, the link reconfiguration request frame further includes: The first flow identifier to link mapping element is used to request the mapping of flow identifiers to links on the link established between the target AP MLD.

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

[0059] For example, the first reconfiguration multilink element is the reconfiguration multilink element with the order 5, the second reconfiguration multilink element is the reconfiguration multilink element with the order 6, and the first flow identifier to link mapping element is the flow identifier to link mapping element with the order 8.

[0060] The above-mentioned link reconfiguration request frame format is an exemplary possible case. In different embodiments or different designs, it is possible that at least one of the following designs may change: the arrangement order of the link reconfiguration request frame and other fields, the order of information, the information contained therein, the number of bytes occupied, and the information name. This embodiment does not limit this.

[0061] Step 402: The current AP MLD420 sends a link reconfiguration request frame to the target AP MLD430.

[0062] For details on the link reconfiguration request frame, please refer to step 401, which will not be repeated here.

[0063] Step 403: The target AP MLD430 sends a link reconfiguration response frame to the current AP MLD420.

[0064] The link reconfiguration response frame is used to report the link reconfiguration with the target AP MLD430 to the non-AP MLD410.

[0065] In some embodiments, the link reconfiguration response frame includes: The third element corresponding to the current AP MLD is used to indicate the link reconfiguration status corresponding to the current AP MLD; The fourth element corresponding to the target AP MLD is used to indicate the link reconfiguration status corresponding to the target AP MLD.

[0066] The third element includes at least one of the following: a list of reconfiguration states 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 list of reconfiguration states of the target AP MLD, including at least one reconfiguration state tuple; the number of reconfiguration state tuples of the target AP MLD; The reconfiguration status tuple is used to indicate the reconfiguration status of a link.

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

[0068] For example, the third element includes the number of reconfiguration state tuples of the current AP MLD in order 6, and the list of reconfiguration states of the current AP MLD in order 7; the fourth element includes the number of reconfiguration state tuples of the target AP MLD in order 8, and the list of reconfiguration states of the target AP MLD in order 9.

[0069] The above-described link reconfiguration response frame format is an exemplary possibility. In different embodiments or designs, it is possible that at least one of the following designs may change: the order of the link reconfiguration response frame and other fields, the order of information, the information contained therein, the number of bytes occupied, or the information name. This embodiment does not limit this.

[0070] Step 404: The current AP MLD420 sends a link reconfiguration response frame to the non-AP MLD410.

[0071] The link reconfiguration response frame is used to report the link reconfiguration with the current AP MLD420 and the target AP MLD430 to the non-AP MLD410.

[0072] Compared to step 403, in step 404, the current AP MLD420 adds information about the link reconfiguration performed on the current AP MLD420 to the link reconfiguration response frame. For details of the link reconfiguration response frame, please refer to Table 2, which will not be repeated here.

[0073] In summary, the method provided in this embodiment sends and / or receives link reconfiguration request frames and link reconfiguration response frames. These frames are used to switch between the current AP MLD and the target AP MLD at different locations based on link reconfiguration. This optimizes the link reconfiguration protocol between the current AP MLD and the target AP MLD at different locations and enables the switching of non-AP MLD between the current AP MLD and the target AP MLD during communication.

[0074] Figure 5 A flowchart of a switching method provided by an exemplary embodiment of this application is shown. The method is performed by a non-APMLD and includes: Step 510: Send and / or receive at least one first frame.

[0075] At least one first frame is used to enable switching between two AP MLDs in different locations based on link reconfiguration.

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

[0077] A Mobile Domain MLD, also known as a Logical AP MLD, treats multiple AP MLDs that are not located in the same location as a single MLD. This embodiment does not limit the specific name of the Mobile Domain MLD.

[0078] In some embodiments, the non-AP MLD switches between two AP MLDs, including at least one of the following scenarios: Scenario 1: When a non-AP MLD is associated with a mobile domain MLD, and the two AP MLDs belong to the same mobile domain MLD, the non-AP MLD will switch between the two AP MLDs at the AP MLD level associated with the mobile domain MLD. Scenario 2: When a non-AP MLD is associated with only one of two AP MLDs, and the two AP MLDs are not attached to the same mobile domain MLD, the non-AP MLD is switched between the two AP MLDs.

[0079] The term "transition" in this application embodiment can also be replaced with "conversion".

[0080] For handover scenario one, handover at the AP MLD level associated with a mobile domain MLD means that before the handover, a non-AP MLD is associated with a mobile domain MLD, and the non-AP MLD establishes multiple links with one AP MLD attached to the mobile domain MLD (i.e., all or part of the links established between the non-AP MLD and the mobile domain MLD belong to the links between the non-AP MLD and one AP MLD attached to the mobile domain MLD). After the handover, the non-AP MLD is still associated with the mobile domain MLD, and the non-AP MLD establishes multiple links with another AP MLD attached to the mobile domain MLD (i.e., all or part of the links established between the non-AP MLD and the mobile domain MLD belong to the links between the non-AP MLD and another AP MLD attached to the mobile domain MLD).

[0081] For the second handover scenario, the non-AP MLD associates with the access point multi-link devices attached to different mobile domain MLDs before and after the handover, thereby performing the associated handover.

[0082] For the mobile domain MLD to which the current AP MLD belongs in one of two AP MLDs, the mobile domain MLD to which multiple AP MLDs belong, including the current AP MLD.

[0083] For a mobile domain MLD to which the target AP MLD belongs in two AP MLDs, the mobile domain MLD belongs to multiple AP MLDs including the target AP MLD.

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

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

[0086] In some embodiments, two AP MLDs belong to the same mobile domain MLD, and the mobile domain MLD is used for at least one of the following: • Provides connection services between non-AP MLD or two AP MLDs and DS; • Maintain data continuity during roaming when a non-AP MLD switches between two AP MLDs; • Authentication and / or association or re-association of non-AP MLDs; • Security associations of non-AP MLDs; • Distribution of all or part of the security-related information of non-AP MLD; • Synchronize all or part of the status and / or buffer information of the higher-level MAC layer of the two AP MLDs; • Manage the distribution of authentication information for non-AP MLD links; • Manage the association or re-association of non-AP MLDs with two AP MLDs at the AP MLD level; • For the target AP MLD that establishes a multi-link with the non-access point multi-link device in the two AP MLDs, select the MAC corresponding to the target AP MLD for data transmission; • The first data is synchronized between the two AP MLDs. The first data is used to maintain data communication between the non-AP MLD and the two AP MLDs or DS. • Exchange or indicate MLD-level information through the MAC sublayers of the two AP MLDs.

[0087] In some embodiments, sending and / or receiving at least one first frame includes: Send a link reconfiguration request frame. The link reconfiguration request frame is used to instruct the non-AP MLD to request link reconfiguration with the two APMLDs to achieve handover. Receive link reconfiguration response frames, which are used to report the link reconfiguration with the two AP MLDs to the non-AP MLD.

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

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

[0090] When a 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 the deletion of at least one link between the non-AP MLD and the current AP MLD. The current AP MLD sends a link reconfiguration request frame to the target AP MLD. The link reconfiguration request frame is used to request the establishment of at least one link between the non-AP MLD and the target AP MLD.

[0091] The target AP MLD sends a link reconfiguration response frame to the current AP MLD. The link reconfiguration response frame is used to indicate the link reconfiguration status corresponding to the target AP MLD, such as whether a link has been 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 is used to indicate the link reconfiguration status corresponding to the current AP MLD and the target AP MLD, such as whether the current AP MLD has deleted the link and whether the target AP MLD has established a link with the non-AP MLD.

[0092] In some embodiments, the two AP MLDs include the current AP MLD and the target AP MLD; The link reconfiguration request frame includes: The first element corresponding to the current AP MLD is used to delete at least one link between 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.

[0093] In some embodiments, the first element includes a first reconfiguration multilink element for describing the reconfiguration multilink information between the non-AP MLD and the current AP MLD; The second element includes a second reconfiguration multilink element, which describes the reconfiguration multilink information for the non-AP MLD and the target AP MLD.

[0094] In some embodiments, the link reconfiguration request frame further includes: The first flow identifier to link mapping element is used to request the mapping of flow identifiers to links on the link established between the target AP MLD.

[0095] In some embodiments, the format of the link reconfiguration request frame is as follows: Figure 4 As shown in Table 1 of the embodiments, for example, the first reconfiguration multilink element is the reconfiguration multilink element with the order 5, the second reconfiguration multilink element is the reconfiguration multilink element with the order 6, and the first flow identifier to link mapping element is the flow identifier to link mapping element with the order 8.

[0096] In some embodiments, the two AP MLDs include the current AP MLD and the target AP MLD, and the link reconfiguration response frame includes: The third element corresponding to the current AP MLD is used to indicate the link reconfiguration status corresponding to the current AP MLD; The fourth element corresponding to the target AP MLD is used to indicate the link reconfiguration status corresponding to the target AP MLD.

[0097] In some embodiments, the third element includes at least one of the following: a list of reconfiguration states 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 list of reconfiguration states of the target AP MLD, including at least one reconfiguration state tuple; the number of reconfiguration state tuples of the target AP MLD; The reconfiguration status tuple is used to indicate the reconfiguration status of a link.

[0098] In some embodiments, the link reconfiguration response frame can be a protected EHT or UHR, UHR+ type action frame. The format of the link reconfiguration response frame is as follows: Figure 4 As shown in Table 2 of the embodiment, for example, the third element includes the number of reconfiguration state tuples of the current AP MLD in order 6, and the reconfiguration state list of the current AP MLD in order 7; the fourth element includes the number of reconfiguration state tuples of the target AP MLD in order 8, and the reconfiguration state list of the target AP MLD in order 9.

[0099] In some embodiments, where the two AP MLDs belong to the same mobile domain MLD, or where the two AP MLDs belong to the same mobile domain, the method further includes: Send and / or receive first indication information, which is used to indicate the mobile domain (MLD).

[0100] In some embodiments, 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; • FT request frame; •FT response frame; •FT confirmation frame; •FT response frame; • Associated request frame; • Associated response frame; • Reassociation request frame; • Reassociate response frames; The request frame is used to instruct the non-AP MLD to request the copying or migration of context information between the two AP MLDs in order to maintain data connectivity during the handover process, and the response frame is used to instruct the non-AP MLD on the result of the copying or migration of context information between the two AP MLDs.

[0101] In some embodiments, the first indication information includes at least one of the following: • Mobile Domain MLD Identifier; • Mobile Domain (MLD) MAC address.

[0102] For example, the first indication information is called a Mobile Domain Element (MDE), which is used to indicate link reconfiguration in a Mobile Domain MLD scenario. It carries Mobile Domain MLD information (such as the Mobile Domain MLD identifier or the Mobile Domain MLD's MAC address), whether the FT is in the same Mobile Domain MLD, and other information. The AP MLD can use the MDE to announce that the AP MLD is included in or attached to a Mobile Domain MLD, announce the AP MLD's support for FT functionality, and FT policy information, including whether it supports or allows FT between two AP MLDs attached to the same Mobile Domain MLD.

[0103] In some embodiments, the switching is based on FT, and the method further includes: Send and / or receive second indication information, which indicates whether FT is supported or permitted between two AP MLDs attached to the same mobile domain MLD.

[0104] FT is performed between two AP MLDs belonging to the same mobile domain MLD, compared to FT between two AP MLDs, to maintain data connectivity during handover.

[0105] In some embodiments, 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; • Associated request frame; • Associated response frame; • Reassociation request frame; • Reassociate response frames; The request frame is used to instruct the non-AP MLD to request the copying or migration of context information between the two AP MLDs in order to maintain data connectivity during the handover process, and the response frame is used to instruct the non-AP MLD on the result of the copying or migration of context information between the two AP MLDs.

[0106] In some embodiments, under the mobile domain MLD architecture, the high-level architecture of the mobile domain MLD and its associated AP MLD and non-AP MLD, where a data connectivity-oriented non-AP MLD (or STA) switches from the current AP MLD (or AP) to the target AP MLD (or AP), is as follows: Figure 6 As shown.

[0107] The high-level architecture includes at least one of the following: DS610, Mobile Domain MLD General Sublayer 620, First Handover Module 630, Auxiliary MLD Upper Layer MAC Sublayer 640, Auxiliary MLD Lower Layer MAC Sublayer 650, Second Handover Module 660, Non-AP MLD Lower Layer MAC Sublayer 670, and Non-AP MLD Upper Layer MAC Sublayer 680.

[0108] The DS610 is an architecture designed to distribute computing and communication functions across multiple nodes or devices. The primary function of DS is to coordinate and manage computing and communication tasks in a distributed environment to achieve efficient data transfer and collaboration.

[0109] The Mobile Domain MLD General Sublayer 620 includes the Mobile Domain AP MLD621, whose MLD MAC address is Q. It communicates with the DS610 via the first MAC-Service Access Point (SAP).

[0110] AP MLD1 with MLD MAC address M and AP MLD2 with MLD MAC address N have the same function. We will use AP MLD1 as an example for explanation. Mobile domain AP MLD621 communicates with AP MLD1 via a first handover module 630. The first handover module 630 can be a module within mobile domain AP MLD621, AP MLD1, or another AP MLD.

[0111] AP MLD1 communicates with AP1 (MAC address w) and AP2 (MAC address x) via a second MAC-SAP. AP1 and AP2 have the same function; AP1 will be used as an example for explanation. AP1 communicates with the second switching module 660 via link 1. The second switching module 660 can be a module in non-AP MLD681, a module in AP MLD1, or a module in other AP MLDs.

[0112] Non-AP STA1 with MAC address y and non-AP STA2 with MAC address z have the same function. 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. We will use non-AP STA1 as an example for explanation. The non-AP MLD with MAC address P communicates with non-AP STA1 via the fourth MAC-SAP.

[0113] The functionality of the Mobile Domain MLD General Sublayer 620 includes at least one of the following: (1) Provide a distributed system access function (DSAF) to the subordinate AP MLDs (e.g., AP MLD1, AP MLD2) of the mobile domain MLD. (2) Authentication, association, and reassociation functions between non-AP MLD681 and mobile domain AP MLD621; (3) Security associations, such as Pairwise Master Key Security Association (PMKSA) and Pairwise Transient Key Security Association (PTKSA), and manage the distribution of GTK / IGTK / BIGTK; (4) Manage partial association and re-association functions between non-AP MLD681 and the affiliated AP MLD of the mobile domain AP MLD; (5) For the auxiliary AP MLD associated with the non-AP MLD681, select the MAC of the corresponding auxiliary AP MLD for data transmission; (6) Synchronization (copying or migration) of all or part of the state and buffer information of the upper layer MAC of the subordinate MLD of the mobile domain MLD. (7) Exchange / instructions for MLD-level management information through the MAC sub-layer of the attached MLD.

[0114] This includes the synchronization of all or part of the state and buffer information of the higher-level MAC layer of the mobile domain MLD's upper-layer MLD, including: For a designated non-AP MLD associated with a mobile domain MLD, the non-AP MLD switches from the currently associated AP MLD to the target AP MLD to be associated. This involves synchronizing all or part of the higher-level state and buffer information of the upper-layer MAC of the associated MLD to maintain the continuity of data communication sessions and data transmission during the process of the non-AP MLD associating with different associated AP MLDs due to roaming.

[0115] All or part of the higher-level state and buffer information of the upper-layer MAC of the mobile domain MLD, i.e., the session or protocol state and buffer information maintained when exchanging data with the specified non-AP MLD (for the specified non-AP MLD), including at least one of the following: (1) The allocation status of sequence number (SN) / packet number (PN) of unicast frames and related buffer data; (2) SN allocation status and related buffer data of the group-addressed MAC Service Data Unit (MSDU); (3) Energy-saving buffer data for individually addressed frames; (4) Block Ack session status and duplicate detection and reordering buffer data of received frames; (5) The PN counter status of the transmitting end and the replay detection status and related buffer data of the receiving end.

[0116] In some embodiments, the link reconfiguration response frame includes a status code indicating the status of link reconfiguration in a mobile domain (MLD) scenario. If the status code takes a first value, it indicates that mobile domain link reconfiguration is rejected.

[0117] The format of the link reconfiguration response frame is as follows: Figure 4 As shown in Table 2 of the embodiment, the status code values, names and meanings of the newly added status code subfield with the order 5 are shown in Table 3. When the status code value is 142 or other values, it is used to indicate that the mobile domain link reconfiguration is rejected, the mobile domain link reconfiguration request has failed, and the target AP MLD has not successfully added a link.

[0118]

[0119] In some embodiments, both the reconfiguration state list subfield of the current AP MLD and the reconfiguration state list subfield of the target AP MLD adopt the reconfiguration state list format. The reconfiguration state list contains one or more reconfiguration state tuples, such as... Figure 7 As shown. Figure 7 This illustration shows a schematic diagram of a reconfiguration status list subdomain format provided in an exemplary embodiment of this application. The reconfiguration status list subdomain format includes at least one of the following: a Link ID Info field and a Status field. In this embodiment, the fields and subdomains have the same meaning.

[0120] The link ID information field occupies 1 byte, and the status field occupies 2 bytes. The format definition 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 AP MLD, and is used in the corresponding link reconfiguration request frame to delete an existing link or add a new link. The status field indicates the status of the link reconfiguration operation corresponding to the link ID field.

[0121] The above-described reconfiguration status list subfield format is an exemplary possibility. In different embodiments or designs, it is possible that at least one of the following designs may change: the position of the reconfiguration status list subfield field in the frame, its arrangement order with other fields, the number of bytes occupied, or the field name. This embodiment does not limit this.

[0122] In some embodiments, the link reconfiguration response frame includes: group key data, indicating a group key successfully added to the link corresponding to the target AP MLD. The group key data subfield may optionally appear and contain the group key successfully added to the link corresponding to the target AP MLD (status code value equal to SUCCESS). Figure 8 A schematic diagram of a group key data subfield format provided in an exemplary embodiment of this application is shown. The group key data subfield format includes at least one of the following: a key data length field and a key data field.

[0123] The key data length field occupies 2 bytes, and the number of bytes occupied by the key data field is variable.

[0124] The group key data subfield contains an MLO GTK KDE, an MLO IGTK KDE, and an MLO BIGTKKDE, providing a group key identified by the link ID subfield for the link added to the target AP MLD.

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

[0126] The above-described group key data subfield format is an exemplary possibility. In different embodiments or designs, it is possible that at least one of the following designs may change: the position of the group key data subfield field in the frame, its arrangement order with other fields, the number of bytes occupied, or the field name. This embodiment does not limit this.

[0127] In some embodiments, the link reconfiguration response frame includes: a basic multilink element for providing STA-granular profiles for one or more affiliated APs of the target AP MLD.

[0128] When at least one link is added to the target AP MLD, the link reconfiguration response frame includes a basic multilink element for providing STA profiles for one or more affiliated APs of the target AP MLD, each corresponding to a link successfully added to the multilink reconfiguration of the non-AP MLD. When no link is added to the target AP MLD, the link reconfiguration response frame does not include the basic multilink element.

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

[0130] 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 mobile domain MLD scenario to respond to the link reconfiguration request frame sent from the non-AP MLD, thereby accepting or rejecting the request from the non-AP MLD to delete links and / or add links on the established multi-link network.

[0131] 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 from the non-AP MLD in the mobile domain MLD scenario, to accept or reject the non-AP MLD's request to delete links on the existing multiple links on the current AP MLD, and to add links on the target AP MLD.

[0132] In some embodiments, switching on at least one of a FT-based link reconfiguration request frame and a link reconfiguration response frame further includes: The second instruction information is used to indicate whether FT is supported or allowed between two AP MLDs attached to the same mobile domain MLD.

[0133] For example, the second indication information is called the "FT in the same mobile 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 mobile domain MLD. When the value of this field is 0, it indicates that FT is not supported or not allowed between two AP MLDs attached to the same mobile domain MLD.

[0134] Figure 9 The illustration shows a schematic diagram of a mobile domain element format provided in an exemplary embodiment of this application. The mobile domain element format includes at least one of the following: an element ID (Element ID) field, a length field, a mobility domain ID (MDID) field, an FT Capability and Policy field, a mobile domain MLD identifier field, and a mobile domain MLD MAC address field.

[0135] 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 mobile domain MLD identifier field occupies 0 or 1 byte, and the mobile domain MLD MAC address field occupies 0 or 6 bytes.

[0136] Regarding the aforementioned FT capabilities and strategy fields, Figure 10 The illustration shows a schematic diagram of the FT capability and policy field format provided in an exemplary embodiment of this application. The FT capability and policy field includes at least one of the following: FT field via DS, resource request protocol capability field, whether FT is in the same mobile domain MLD (FTinMobileDomainMLD) field, and reserved field.

[0137] Among them, the FT field through DS occupies 1 bit, the resource request protocol capability field occupies 1 bit, the FT whether it is in the same mobile domain MLD field occupies 1 bit, and the reservation field occupies 5 bits.

[0138] The "FT in the same mobile domain MLD" field indicates whether FT is supported or permitted between two AP MLDs belonging to the same mobile domain MLD. For example, a value of 1 indicates support or permission for FT between two AP MLDs belonging to the same mobile domain MLD, while a value of 0 indicates that FT is not supported or not permitted between two AP MLDs belonging to the same mobile domain MLD. Alternatively, a value of 0 may indicate support or permission for FT between two AP MLDs belonging to the same mobile domain MLD, while a value of 1 may indicate that FT is not supported or not permitted between two AP MLDs belonging to the same mobile domain MLD. This embodiment does not limit this approach.

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

[0140] The above-described format of mobile domain elements, FT capabilities, and policy fields is an exemplary possibility. In different embodiments or designs, it is possible that at least one of the following designs may change: the position of mobile domain elements, FT capabilities, and policy fields in the frame, their arrangement order with other fields, the number of bytes occupied, the number of bits occupied, the element name, and the field name. This embodiment does not limit this.

[0141] In some embodiments, the method further includes: Send and / or receive at least one second frame, the second frame being used to synchronize context information related to the non-APMLD between the two AP MLDs, the context information including at least one of status information and buffer information.

[0142] In some embodiments, sending and / or receiving at least one second frame includes: Send a request frame, which instructs the non-AP MLD to request the synchronization of context information related to the non-AP MLD between the two AP MLDs; Receive a response frame, which is used to feed back context information related to the non-AP MLD to the non-AP MLD for synchronization between the two AP MLDs.

[0143] In some embodiments, the context information includes at least one of the following: First context information, which is information related to the block acknowledgment protocol context; Second context information is information related to the security-associated context.

[0144] In some embodiments, the first context information is carried in the block acknowledgment protocol context element.

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

[0146] Block confirmation protocol context element: In some embodiments, the block acknowledgment protocol context can also be described as a block acknowledgment protocol scenario, which is information about the maintained block acknowledgment process.

[0147] In some embodiments, the block acknowledgment protocol context element includes block acknowledgment protocol context or state information specifying that the MLD has established and maintained block acknowledgment protocol contexts or state information 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 indicates at least one of the following: • The device where the block confirmation protocol context element resides; • Whether the device where the block confirmation protocol context element resides is the same device as the non-AP MLD to which the block confirmation protocol context is targeted; • If the device where the block confirmation protocol context element resides is the same device as the non-AP MLD to which the block confirmation protocol context is targeted, then the non-AP MLD to which the block confirmation protocol context is targeted. • The number of block acknowledgment protocol context parameters included in the block acknowledgment protocol context element.

[0148] In some embodiments, the device containing the block acknowledgment protocol context element is the current AP MLD.

[0149] Figure 11 This illustration shows a schematic diagram of a block acknowledgment protocol context element format provided in an exemplary embodiment of this 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 embodiments of this application, the domain and field have the same meaning, and the subdomain and field have the same meaning.

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

[0151] Regarding the block acknowledgment protocol context parameter control fields mentioned above, Figure 12 The illustration shows a schematic diagram of the format of a block acknowledgment protocol context parameter control field provided in an exemplary embodiment of this application. The block acknowledgment protocol 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, number of single block acknowledgment protocol context parameter sets field, and reserved field.

[0152] The MLD MAC address field occupies 48 bits, the field indicating whether the peer MLD is the same MLD occupies 1 bit, the peer MLD MAC address field occupies 0 or 48 bits, the field indicating the number of single block acknowledgment protocol context parameters occupies 16 bits, and the reserved field occupies 7 bits.

[0153] The MLD MAC address field indicates the MAC address of the MLD containing the Block Acknowledgment Protocol Context described by the Block Acknowledgment Protocol Context element. The MLD MAC address can be the MLD address of a roaming MLD.

[0154] The "Whether the peer MLD is the same MLD" field indicates whether the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element are the same MLD. A value of 0 indicates that the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation context element are the same MLD; a value of 1 indicates that the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element are multiple MLDs. Alternatively, a value of 1 indicates that the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation context element are the same MLD; a value of 0 indicates that the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element are multiple MLDs. This application embodiment does not limit this.

[0155] The peer MLD MAC address field indicates the MAC address of the peer MLD to which the block acknowledgment protocol context of the MLD described by the block acknowledgment protocol context element is located. When the value of the "Whether the peer MLD is the same MLD" field is 0, the peer MLD MAC address field exists in the block acknowledgment protocol context parameter control field; when the value of the "Whether the peer MLD is the same MLD" field is 1, the peer MLD MAC address field does not exist in the block acknowledgment protocol context parameter control field. Alternatively, when the value of the "Whether the peer MLD is the same MLD" field is 1, the peer MLD MAC address field exists in the block acknowledgment protocol context parameter control field; when the value of the "Whether the peer MLD is the same MLD" field is 0, the peer MLD MAC address field does not exist in the block acknowledgment protocol context parameter control field. This application embodiment does not limit this specific case.

[0156] The Single Block Acknowledgment Protocol Context Parameter Set Count field is a 16-bit unsigned integer indicating the number of single block acknowledgment protocol context parameter set fields in the Block Acknowledgment Protocol Context Parameter Set List field.

[0157] In some embodiments, the block confirmation protocol context element includes a block confirmation protocol context parameter set list field, which 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.

[0158] In some embodiments, the block acknowledgment protocol context parameter set subfield is used to indicate at least one of the following: • The role of the device within the block acknowledgment protocol context; • The non-AP MLD that the block confirmation protocol context refers to; • Block confirmation parameter set; • Block confirmation timeout value.

[0159] Regarding the block acknowledgment protocol context parameter set list fields mentioned above, Figure 13 The illustration shows a format diagram of a block confirmation protocol context parameter set list field provided in an exemplary embodiment of this application. The block confirmation protocol context parameter set list field includes at least one of the following: one or more individual block confirmation protocol context parameter set fields, and padding fields.

[0160] The number of bits occupied by the single block confirmation protocol context parameter set field is variable, and the number of bits occupied by the padding field is also variable.

[0161] In some embodiments, if the block acknowledgment protocol context parameter set subfield is used to indicate that the device in the corresponding block acknowledgment protocol context plays the role of an initiator in the block acknowledgment protocol context, the block acknowledgment protocol context parameter set subfield is also used to indicate at least one of the following: • Send window start sequence number; • Send window size.

[0162] In some embodiments, if the Block Acknowledgment Protocol Context Parameter Set subfield is used to indicate that the device residing in the Block Acknowledgment Protocol Context plays the role of a receiver within the Block Acknowledgment Protocol Context; the Block Acknowledgment Protocol Context Parameter Set subfield is also used to indicate at least one of the following: • Start sequence number of the receive buffer; • Receive window size; • Record the starting sequence number of the bitmap; • Record the maximum sequence number of the bitmap; Record bitmap size.

[0163] Regarding the single block acknowledgment protocol context parameter set fields mentioned above, if the MLD containing the block acknowledgment protocol context is the initiator MLD role, Figure 14 The illustration shows a format diagram of a single block acknowledgment protocol context parameter set field provided in an exemplary embodiment of this application. The single block acknowledgment protocol context parameter set field includes at least one of the following: MLD role field (initiator MLD), peer MLD field, block acknowledgment parameter set field, block acknowledgment timeout field, send window start sequence number field (WinStart0), and send window size field (WinSize0).

[0164] The MLD role field (initiator MLD) occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the block acknowledgment parameter set field occupies 16 bits, the block acknowledgment timeout value field occupies 8 bits, the send window start sequence number field occupies 12 bits, and the send window size field occupies 10 bits.

[0165] When the MLD in the block confirmation protocol context is the receiver MLD role. Figure 15The illustration shows a format diagram of a single block acknowledgment protocol context parameter set field provided in an exemplary embodiment of this application. The single block acknowledgment protocol context parameter set field includes at least one of the following: MLD role field (receiver MLD), peer MLD field, block acknowledgment parameter set field, block acknowledgment 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.

[0166] The MLD role field (receiver MLD) occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the block acknowledgment parameter set field occupies 48 bits, the block acknowledgment timeout value field occupies 16 bits, the receive buffer start sequence number field occupies 12 bits, the receive window size field occupies 10 bits, the record bitmap start 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.

[0167] The MLD Role field indicates the role of the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set in the block acknowledgment protocol. For example, a value of 0 indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set acts as the initiator MLD in the block acknowledgment protocol; a value of 1 indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set acts as the receiver MLD in the block acknowledgment protocol. Alternatively, a value of 1 indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set acts as the initiator MLD in the block acknowledgment protocol; a value of 0 indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set acts as the receiver MLD in the block acknowledgment protocol.

[0168] When the MLD containing the block acknowledgment protocol context is the initiator role, the format of a single block acknowledgment protocol context parameter set is as follows: Figure 14 As shown, when the MLD containing the block acknowledgment protocol context is in the receiver role, the format of a single block acknowledgment protocol context parameter set is as follows: Figure 15 As shown.

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

[0170] The Block Acknowledgment Parameter Set field indicates the set of parameters associated with the established block acknowledgment protocol corresponding to the block acknowledgment protocol context described by the Block Acknowledgment Protocol Context Parameter Set field.

[0171] The Block Acknowledgment Timeout field contains the duration in TU (1024 microseconds). If no frame exchange sequence occurs within this duration using the Block Acknowledgment protocol, the Block Acknowledgment protocol will terminate after this duration. Setting this field to 0 indicates a disabled timeout.

[0172] The Send Window Start Sequence Number field is a send buffer control parameter used to indicate the start sequence number of the send window.

[0173] In some embodiments, the block confirmation parameter set includes at least one of the following: • Indicator information indicating whether aggregated MSDUs are supported; • Block confirmation strategy; • Flow identifier; • Buffer size.

[0174] Regarding the aforementioned block confirmation parameter set fields, Figure 16 The illustration shows a schematic diagram of the format of the block acknowledgment parameter set fields provided in an exemplary embodiment of this application. The block acknowledgment parameter set fields include at least one of the following: AggregateMSDU (A-MSDU) support field, Block Ack Policy field, Stream Identifier (TID) field, and Buffer Size field.

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

[0176] The transmit window size field is a transmit buffer control parameter that indicates the buffer size of the transmit window negotiated in the block acknowledgment protocol. Specifically, the transmit window size field indicates the number of buffers available for a given TID. When the A-MSDU support field is equal to 0, the number of bytes each buffer can hold is equal to the maximum size of the MSDU. When the STA-supported A-MSDU field is equal to 1, the number of bytes each buffer can hold is equal to the maximum size of the A-MSDU supported by the STA.

[0177] The Receive Buffer Start Sequence Number field is a control parameter for the Receive Reordering Buffer, representing the value of the sequence number field of the first MSDU or A-MSDU (arranged in ascending order of sequence number) that has not yet been received.

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

[0179] The Record Bitmap Start Sequence Number field is a Scoreboard Context Control parameter. It is a 12-bit unsigned integer start sequence number that represents the lowest sequence number position in the block confirmation record bitmap (indexed by sequence number).

[0180] The record bitmap maximum sequence number field indicates the highest sequence number in the current transmission window.

[0181] The record bitmap size field is a scoreboard context control parameter used to indicate the maximum transmission window size, set to the smaller of the bitmap length and the buffer size field of the relevant response frame of the build block return protocol.

[0182] The above-described block acknowledgment protocol context element format, block acknowledgment protocol context parameter control field format, block acknowledgment protocol context parameter set list field format, single block acknowledgment protocol context parameter set field format, and block acknowledgment parameter set field format are exemplary possibilities. In different embodiments or different designs, it is not excluded that at least one of the following designs may change: the position of the above fields in the frame, the order of arrangement with other fields, the number of bytes occupied, the number of bits occupied, the element name, and the field name. This embodiment does not limit this.

[0183] Security-related context elements: In some embodiments, the security association context can also be described as a security association scenario, which is information about the security association process being maintained.

[0184] In some embodiments, the security association context element includes sender PN configuration and PN counter status information that the specified MLD has established and maintained with one or more peer MLDs for security association-related data encryption / decryption and / or integrity protection and verification, and / or receiver replay detection context and replay counter status information. Figure 17The illustration shows a schematic diagram of a security association context element format provided in an exemplary embodiment of this 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 parameter control field, and a security association context parameter set list field.

[0185] 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.

[0186] In some embodiments, a security association context element includes a security association context parameter control field, which is used to indicate at least one of the following: • The device where the security association context element resides; • Whether the device where the security association context element resides and the non-AP MLD to which the security association context targets are the same device; • If the device where the security association context element resides and the non-AP MLD to which the security association context is targeted are the same device, then the non-AP MLD to which the security association context is targeted. • The number of security association context parameter sets included in the security association context element.

[0187] In some embodiments, the device containing the security association context element is the current AP MLD.

[0188] Regarding the aforementioned security association context parameter control fields, Figure 18 The illustration shows a schematic diagram of the format of a security association context parameter control field provided in an exemplary embodiment of this 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, number of security association scenario parameter sets field, and reserved field.

[0189] The MLD MAC address field occupies 48 bits, the field indicating whether the peer MLD is the same MLD occupies 1 bit, the peer MLD MAC address field occupies 0 or 48 bits, the field indicating the number of security association scenario parameter sets occupies 16 bits, and the reserved field occupies 7 bits.

[0190] In some embodiments, a security association context element includes a security association context parameter set list field, which 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.

[0191] In some embodiments, the security association context parameter set subfield is used to indicate at least one of the following: • The role of the device within the security association context; • The non-AP MLD targeted by the security association context; • Security association type of security association context.

[0192] Regarding the fields in the aforementioned security association context parameter set list, Figure 19 The illustration shows a format diagram of a security association context parameter set list field provided in an exemplary embodiment of this 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.

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

[0194] In some embodiments, if the security association context parameter set subfield is used to indicate that the device in the security association context plays the role of initiator in the security association context; the security association context parameter set subfield is also used to indicate at least one of the following: • Number of replay counters; ·TID; • Counting of the replay counter for TID.

[0195] In some embodiments, if the security association context parameter set subfield is used to indicate that the device in the security association context plays the role of a receiver in the security association context; the security association context parameter set subfield is also used to indicate at least one of the following: • Package number counter count; ·TID; • Counting for the package number counter for TID.

[0196] Regarding the aforementioned security association context parameter set fields, if the MLD containing the security association context described by the security association context parameter set fields is the receiver MLD role, Figure 20The illustration shows a schematic diagram of the format of the security association context parameter set fields provided in an exemplary embodiment of this application. The security association context parameter set fields include at least one of the following: MLD role field, peer MLD field, PTKSA / Group Temporal Key Security Association (GTKSA) / Tunneled direct link setup PeerKey Security Association (TPKSA) field, number of replay counters field, one or more TID fields, and one or more replay counter count fields.

[0197] 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 replay counter count field occupies 5 bits, the TID field occupies 8 bits, and the replay counter count field occupies 48 bits.

[0198] When the MLD containing the security association context described in the security association context parameter set field is the sender's MLD role. Figure 21 The illustration shows a schematic diagram of the format of a security association context parameter set field provided in an exemplary embodiment of this application. The security association context parameter set field includes at least one of the following: MLD role field, PeerMLD field, PTKSA / GTKSA / TPKSA field, PN counter number field, one or more TID fields, and one or more PN counter count fields.

[0199] 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 count field occupies 5 bits, the TID field occupies 8 bits, the intermediate PN counter count field occupies 0 or 48 bits, and the final PN counter count field occupies 48 bits.

[0200] The MLD Role field indicates the role of the MLD containing the security association context described by the Security Association Context Parameter Set field within that security association context. For example, a value of 0 in the MLD Role field indicates that the MLD containing the security association context described by the Security Association Context Parameter Set field acts as a receiver MLD, meaning it describes the receiver's replay context parameter set; a value of 1 in the MLD Role field indicates that the MLD containing the security association context described by the Security Association Context Parameter Set field acts as a sender MLD, meaning it describes the sender's PN counter context parameter set. Alternatively, a value of 1 in the MLD Role field indicates that the MLD containing the security association context described by the Security Association Context Parameter Set field acts as a receiver MLD; a value of 0 in the MLD Role field indicates that the MLD containing the security association context described by the Security Association Context Parameter Set field acts as a sender MLD.

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

[0202]

[0203] The above-mentioned security association context element format, security association context parameter control field format, security association context parameter set list field format, and security association context parameter set field format are exemplary possible cases. In different embodiments or different designs, it is not excluded that at least one of the following designs may change: the position of the above fields in the frame, the order of arrangement with other fields, the number of bytes occupied, the number of bits occupied, the element name, and the field name. This embodiment does not limit this.

[0204] In some embodiments, the second frame further includes: third indication information, which is used to indicate that the context information includes information on the block acknowledgment protocol context and / or security association context.

[0205] In some embodiments, the two AP MLDs belong to the same mobile domain MLD, and at least one of the request frame and response frame further includes: The first indication information is used to indicate the mobile domain (MLD).

[0206] In some embodiments, switching based on at least one of the FT, request frame, and response frame further includes: The second indication information is used to indicate whether FT is supported or permitted between two AP MLDs attached to the same mobile domain MLD. For example, the second indication information is called the "FT in the same mobile domain MLD" field. When the value of this field is 1, it indicates that FT is supported or permitted between two AP MLDs attached to the same mobile domain MLD; when the value of this field is 0, it indicates that FT is not supported or permitted between two AP MLDs attached to the same mobile domain MLD.

[0207] In some embodiments, 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 the current AP MLD sends it to the target AP MLD; The response frame is sent from the target AP MLD to the current AP MLD, and then fed back by the current AP MLD.

[0208] In some embodiments, the switching is based on FT, the request frame is an FT acknowledgment frame, and the response frame is an FT reply frame.

[0209] The non-AP MLD sends an FT acknowledgment frame to the target AP MLD via the current AP MLD. Then, the target AP MLD sends an FT response frame to the non-AP MLD via the current AP MLD. The FT acknowledgment frame includes at least one of the following: non-AP MLD information, target AP MLD information, MDE, block acknowledgment 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 acknowledgment protocol context element, security association context element, and basic multilink element.

[0210] The FT acknowledgment frame and the FT response frame carry block acknowledgment protocol context elements and security association context elements, indicating the relevant block acknowledgment protocol context (or status) information and security association context (or status) information.

[0211] In some embodiments, the two AP MLDs belong to the same mobile domain MLD, and the method further includes: Send an FT request frame; Receive FT response frames.

[0212] When a non-AP MLD determines that it needs to switch from the current AP MLD to the target AP MLD in a mobile domain MLD scenario, the non-AP MLD sends an FT request frame to the target AP MLD through the current AP MLD. Then, the target AP MLD sends an FT response frame to the non-AP MLD through 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.

[0213] The FT request frame and FT response frame carry the MDE (FTinMobileDomainMLD field, Mobile Domain MLD information field), indicating that FT is supported or permitted between two AP MLDs belonging to the same Mobile Domain MLD.

[0214] In some embodiments, the method further includes: Send association request frame; Receive associated response frames.

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

[0216] The non-AP MLD sends an association request frame or reassociation request frame to the current AP MLD, including: Mobile Domain Element (MDE) and Basic Multilink Element; The current AP MLD sends association response frames or reassociation response frames to the Non-AP MLD, including: Mobile Domain Element (MDE) and Basic Multilink Element.

[0217] The association request frame or reassociation request frame carries the MDE (FTinMobileDomainMLD field, Mobile Domain MLD information field), which instructs the non-AP MLD to associate with the AP MLD in the Mobile Domain MLD scenario (or the non-AP MLD is associated with the AP MLD attached to the Mobile Domain MLD), and indicates that FT is supported or allowed between two AP MLDs attached to the same Mobile Domain MLD.

[0218] In some embodiments, the switch is based on FT, and link reconfiguration is performed if the first duration is less than or equal to the link reconfiguration deadline. The first duration refers to the duration between the transmission time of the FT request frame and the transmission time of the link reconfiguration request frame, and the first frame includes the link reconfiguration request frame.

[0219] In some embodiments, the method further includes sending a fourth indication message, the fourth indication message being used to indicate a deadline or timeout for link reconfiguration.

[0220] For example, the fourth indication information is called the Timeout Interval Element (TIE), which is used to specify the time interval and the timeout period.

[0221] In some embodiments, the fourth indication information uses a start time and a timeout interval to indicate, or, The fourth instruction uses a deadline as the indication.

[0222] In some embodiments, the start time is implicitly represented by the time the fourth indication information is sent or received; The timeout interval is explicitly indicated by the fourth indication information.

[0223] In this embodiment of the 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, which is used to indicate that the timeout interval value field represents the link reconfiguration deadline time interval. Figure 22 The illustration shows a schematic diagram of a timeout interval element format provided in an exemplary embodiment of this 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.

[0224] 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.

[0225] The above-described timeout interval element format is an exemplary possibility. In different embodiments or designs, it is possible that at least one of the following designs may change: the position of the timeout interval element in the frame, its arrangement order with other fields, the number of bytes occupied, or the element name. This embodiment does not limit this.

[0226] 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 definitions of the timeout interval type field are shown in Table 5.

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

[0228] The method provided in this embodiment also eliminates the time when the non-AP MLD loses data connectivity with the two AP MLDs by copying or migrating the block acknowledgment protocol context and the security association context, thus maintaining the data continuity between the non-AP MLD and the two AP MLDs. The block acknowledgment protocol context is used to ensure the connectivity of data transmission, and the security association context is used to eliminate the need to renegotiate the key after the switch by omitting the key negotiation process.

[0229] Figure 23 A flowchart of a switching method provided by an exemplary embodiment of this application is shown. The method is performed by a non-AP MLD410, a current AP MLD420, and a target AP MLD430. The method includes: Step 2310: Non-AP MLD410 sends a request frame to the current AP MLD420.

[0230] The request frame is used to instruct the non-AP MLD410 to request the synchronization of context information related to the non-AP MLD410 between the current AP MLD420 and the target AP MLD430.

[0231] In some embodiments, the context information includes at least one of the following: First context information, which is information related to the block acknowledgment protocol context; Second context information is information related to the security-associated context.

[0232] In some embodiments, the first context information is carried in the block acknowledgment protocol context element.

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

[0234] For detailed implementation information, please refer to... Figure 5 The block confirmation protocol context element portion and the security association context element portion of the embodiment will not be described again here.

[0235] In some embodiments, where the current AP MLD420 and the target AP MLD430 belong to the same mobile domain MLD, at least one of the request frame and response frame further includes: The first indication information is used to indicate the mobile domain (MLD).

[0236] In some embodiments, the first indication information includes at least one of the following: • Mobile Domain MLD Identifier; • Mobile Domain (MLD) MAC address.

[0237] For example, the first indication information is called a Mobile Domain Element (MDE), which is used to indicate link reconfiguration in a Mobile Domain MLD scenario. It carries Mobile Domain MLD information (such as the Mobile Domain MLD identifier or the Mobile Domain MLD's MAC address), whether the FT is in the same Mobile Domain MLD, and other information. The AP MLD can use the MDE to announce that the AP MLD is included in or attached to a Mobile Domain MLD, announce the AP MLD's support for FT functionality, and FT policy information, including whether it supports or allows FT between two AP MLDs attached to the same Mobile Domain MLD.

[0238] Step 2311: The current AP MLD420 sends a request frame to the target AP MLD430.

[0239] For details regarding the request frame, please refer to step 2310, which will not be repeated here.

[0240] Step 2320: The target AP MLD430 sends a response frame to the current AP MLD420.

[0241] The response frame is used to feed back context information related to the non-AP MLD410 to the non-AP MLD410 for synchronization between the current AP MLD420 and the target AP MLD430.

[0242] Step 2321: The current AP MLD420 sends a response frame to the non-AP MLD410.

[0243] For details on the response frame, please refer to step 2320, which will not be repeated here.

[0244] Step 2330: Non-AP MLD410 sends a link reconfiguration request frame to the current AP MLD420.

[0245] Step 2331: The current AP MLD420 sends a link reconfiguration request frame to the target AP MLD430.

[0246] Step 2340: The target AP MLD430 sends a link reconfiguration response frame to the current AP MLD420.

[0247] Step 2341: The current AP MLD420 sends a link reconfiguration response frame to the non-AP MLD410.

[0248] Refer to steps 2330 to 2341 Figure 4 Steps 401 to 404 of the embodiment will not be repeated here.

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

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

[0251] Step 2310 can be implemented as a standalone embodiment, such as by implementing a separate method for sending a request frame; Step 2311 can be implemented as a standalone embodiment, such as by implementing it separately as a method for sending a request frame; Step 2320 can be implemented as a standalone embodiment, such as a separate method for sending a response frame; Step 2321 can be implemented as a standalone embodiment, such as by implementing a separate method for sending a response frame; Step 2330 can be implemented as a standalone embodiment, such as as a separate method for sending a link reconfiguration request frame; Step 2331 can be implemented as a standalone embodiment, such as by implementing it separately as a method for sending a link reconfiguration request frame; Step 2340 can be implemented as a standalone embodiment, such as as a method for sending a link reconfiguration response frame; Step 2341 can be implemented as a standalone embodiment, such as a method for sending a link reconfiguration response frame.

[0252] In summary, the method provided in this embodiment sends and / or receives link reconfiguration request frames and link reconfiguration response frames. These frames are used to switch between the current AP MLD and the target AP MLD at different locations based on link reconfiguration. This optimizes the link reconfiguration protocol between the current AP MLD and the target AP MLD at different locations and enables the switching of non-AP MLD between the current AP MLD and the target AP MLD during communication.

[0253] The method provided in this embodiment also eliminates the time when the non-AP MLD loses data connectivity with the current AP MLD and the target AP MLD by sending request frames to indicate the copy or migration block confirmation protocol context and security association context, thus maintaining the data continuity between the non-AP MLD and the current AP MLD and the target AP MLD. The block confirmation protocol context is used to ensure the connectivity of data transmission, and the security association context is used to eliminate the need to renegotiate the key after the switch by omitting the key negotiation process.

[0254] Figure 24 A flowchart of a switching method provided by an exemplary embodiment of this application is shown. The method is performed by a non-AP MLD410, a current AP MLD420, and a target AP MLD430. The method includes: Step 2410: Non-AP MLD410 sends an FT request frame to the current AP MLD420.

[0255] 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.

[0256] In some embodiments, the current AP MLD420 and the target AP MLD430 belong to the same mobile domain MLD, and the FT request frame further includes: first indication information for indicating the mobile domain MLD.

[0257] In some embodiments, the FT request frame further includes: The second instruction information is used to indicate whether FT is supported or allowed between the current AP MLD420 and the target AP MLD430, which are attached to the same mobile domain MLD.

[0258] The FT request frame carries the MDE (FTinMobileDomainMLD field, Mobile Domain MLD Information field), indicating that FT is supported or permitted between the current AP MLD420 and the target AP MLD430, which belong to the same Mobile Domain MLD.

[0259] Step 2411: The current AP MLD420 sends an FT request frame to the target AP MLD430.

[0260] For details on the FT request frame, please refer to step 2410, which will not be repeated here.

[0261] Step 2420: The target AP MLD430 sends an FT response frame to the current AP MLD420.

[0262] 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.

[0263] In some embodiments, the current AP MLD420 and the target AP MLD430 belong to the same mobile domain MLD, and the FT response frame further includes: first indication information for indicating the mobile domain MLD.

[0264] In some embodiments, the FT response frame further includes: The second instruction information is used to indicate whether FT is supported or allowed between the current AP MLD420 and the target AP MLD430, which are attached to the same mobile domain MLD.

[0265] The FT response frame carries the MDE (FTinMobileDomainMLD field, Mobile Domain MLD Information field), indicating that FT is supported or permitted between the current AP MLD420 and the target AP MLD430, which belong to the same Mobile Domain MLD.

[0266] Step 2421: The current AP MLD420 sends an FT response frame to the non-AP MLD410.

[0267] For details on the FT response frame, please refer to step 2420, which will not be repeated here.

[0268] Step 2430: Non-AP MLD410 sends an FT acknowledgment frame to the current AP MLD420.

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

[0270] The FT confirmation frame carries a block confirmation protocol context element and a security association context element, indicating the relevant block confirmation protocol context (or status) information and security association context (or status) information.

[0271] Step 2431: The current AP MLD420 sends an FT acknowledgment frame to the target AP MLD430.

[0272] For details on the FT confirmation frame, please refer to step 2430, which will not be repeated here.

[0273] Step 2440: The target AP MLD430 sends an FT response frame to the current AP MLD420.

[0274] 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 acknowledgment protocol context element, security association context element, and basic multilink element.

[0275] The FT response frame carries a block acknowledgment protocol context element and a security association context element, indicating the relevant block acknowledgment protocol context (or status) information and security association context (or status) information.

[0276] Step 2441: The current AP MLD420 sends an FT response frame to the non-AP MLD410.

[0277] For details on the FT response frame, please refer to step 2440, which will not be repeated here.

[0278] Refer to steps 2430 to 2441 Figure 23 Steps 2310 to 2321 of the embodiment will not be repeated here.

[0279] Step 2450: Non-AP MLD410 sends a link reconfiguration request frame to the current AP MLD420.

[0280] Step 2451: The current AP MLD420 sends a link reconfiguration request frame to the target AP MLD430.

[0281] Step 2460: The target AP MLD430 sends a link reconfiguration response frame to the current AP MLD420.

[0282] Step 2461: The current AP MLD420 sends a link reconfiguration response frame to the non-AP MLD410.

[0283] References for steps 2450 to 2461 Figure 4 Steps 401 to 404 of the embodiment will not be repeated here.

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

[0285] Steps 2410 to 2421 can be implemented as independent embodiments, steps 2430 to 2441 can be implemented as independent embodiments, and steps 2450 to 2461 can be implemented as independent embodiments, but are not limited thereto.

[0286] Step 2410 can be implemented as a standalone embodiment, such as a separate method for sending an FT request frame; Step 2411 can be implemented as a standalone embodiment, such as a separate method for sending an FT request frame; Step 2420 can be implemented as a standalone embodiment, such as a separate method for transmitting an FT response frame; Step 2421 can be implemented as a standalone embodiment, such as a separate method for transmitting an FT response frame; Step 2430 can be implemented as a standalone embodiment, such as a separate method for sending an FT confirmation frame; Step 2431 can be implemented as a standalone embodiment, such as implementing a separate method for sending an FT confirmation frame; Step 2440 can be implemented as a standalone embodiment, such as a separate method for transmitting an FT response frame; Step 2441 can be implemented as a standalone embodiment, such as a separate method for transmitting an FT response frame; Step 2450 can be implemented as a standalone embodiment, such as as a separate method for sending a link reconfiguration request frame; Step 2451 can be implemented as a standalone embodiment, such as as a separate method for sending a link reconfiguration request frame; Step 2460 can be implemented as a standalone embodiment, such as as a method for sending a link reconfiguration response frame; Step 2461 can be implemented as a standalone embodiment, such as a method for sending a link reconfiguration response frame.

[0287] In summary, the method provided in this embodiment sends and / or receives link reconfiguration request frames and link reconfiguration response frames. These frames are used to switch between the current AP MLD and the target AP MLD at different locations based on link reconfiguration. This optimizes the link reconfiguration protocol between the current AP MLD and the target AP MLD at different locations and enables the switching of non-AP MLD between the current AP MLD and the target AP MLD during communication.

[0288] The method provided in this embodiment also eliminates the time when the non-AP MLD loses data connectivity with the current AP MLD and the target AP MLD by sending FT confirmation frames to indicate the copy or migration block confirmation protocol context and security association context, thus maintaining the data continuity between the non-AP MLD and the current AP MLD and the target AP MLD. The block confirmation protocol context is used to ensure the connectivity of data transmission, and the security association context is used to eliminate the need to renegotiate the key after the switch by omitting the key negotiation process.

[0289] Figure 25 The flowchart illustrates a handover method provided by an exemplary embodiment of this application, which is executed by a non-AP MLD410, a current AP MLD420, and a target AP MLD430. The non-AP MLD410 is an FT initiator (FTO), and the current AP MLD420 and target AP MLD430 are FT responders (FTRs). The current AP MLD420 and target AP MLD430 belong to the same mobility domain MLD400. The method includes: Step 2510: The non-AP MLD410 sends an authentication request frame to the current AP MLD420.

[0290] If the non-AP MLD410 determines that data information needs to be transmitted to the current AP MLD420, proceed to step 2510.

[0291] An authentication request frame is an authentication frame whose authentication transaction sequence number (AuthenticationTransaction Sequence Number) field value is 1.

[0292] Step 2520: The current AP MLD420 sends an authentication response frame to the non-AP MLD410.

[0293] Upon receiving an authentication request frame from a non-AP MLD410, the current AP MLD420 sends back an authentication response frame. The authentication response frame is an authentication frame with an authentication transaction sequence number field value of 2.

[0294] Step 2530: Non-AP MLD410 sends a (re)association request frame to the current AP MLD420.

[0295] In some embodiments, the non-AP MLD410 is associated with the current AP MLD420 and performs mobile domain MLD scene association or FT initial mobile domain MLD scene association.

[0296] The association was successfully established if the time between the first association request frame and the authentication request frame and the reassociation request frame exceeded the reassociation deadline.

[0297] Reassociation was successfully performed if the time between the authentication request frame and the reassociation request frame did not exceed the reassociation deadline.

[0298] The (re)association request frame includes at least one of the following: MDE (FTinMobileDomainMLD field, Mobile Domain MLD Information field) or Basic Multilink Element. Specifically, the (re)association request frame carries the MDE, instructing the non-AP MLD410 to associate with the AP MLD in the Mobile Domain MLD400 scenario (or, in other words, the non-AP MLD410 is associated with an AP MLD attached to the Mobile Domain MLD400), and instructing that FT is supported or permitted between the current AP MLD420 and the target AP MLD430, both attached to the same Mobile Domain MLD.

[0299] Step 2540: The current AP MLD420 sends a (re)association response frame to the non-AP MLD410.

[0300] Upon receiving a (re)association request frame from a non-AP MLD410, the current AP MLD420 sends back a (re)association response frame.

[0301] (Re)Associated response frames include at least one of the following: MDE (FTinMobileDomainMLD field, Mobile Domain MLD information field) or basic multilink element.

[0302] Step 2550: Non-AP MLD410 sends an FT request frame to the current AP MLD420.

[0303] Step 2551: The current AP MLD420 sends an FT request frame to the target AP MLD430.

[0304] Step 2560: The target AP MLD430 sends an FT response frame to the current AP MLD420.

[0305] Step 2561: The current AP MLD420 sends an FT response frame to the non-AP MLD410.

[0306] In some embodiments, the non-AP MLD410 initiates a FT process from the current AP MLD420 to the target AP MLD430 in a mobile domain MLD scenario.

[0307] Refer to steps 2550 to 2561 Figure 24 Steps 2410 to 2421 of the embodiment will not be repeated here.

[0308] Step 2570: Non-AP MLD410 sends an FT acknowledgment frame to the current AP MLD420.

[0309] In some embodiments, for a non-AP MLD410, the mobile domain MLD context, state, and / or all or part of the context, state, and buffer of the corresponding affiliated MLD of the mobile domain MLD are copied or migrated from the current AP MLD420 to the target AP MLD430.

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

[0311] The FT confirmation frame carries a block confirmation protocol context element and a security association context element, indicating the relevant block confirmation protocol context (or status) information and security association context (or status) information.

[0312] In some embodiments, the FT acknowledgment frame requests the synchronization of the block acknowledgment protocol context and the security association context. The block acknowledgment protocol context is used to ensure the 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 the switch.

[0313] Step 2571: The current AP MLD420 sends an FT acknowledgment frame to the target AP MLD430.

[0314] In some embodiments, after receiving an FT acknowledgment frame sent by a non-AP MLD410, the current AP MLD420 adds relevant information of the block acknowledgment protocol context and 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 it to the target AP MLD430, thereby copying or migrating the block acknowledgment protocol context and security association context to the target AP MLD430.

[0315] Step 2580: The target AP MLD430 sends an FT response frame to the current AP MLD420.

[0316] In some embodiments, after receiving an FT acknowledgment frame, the target AP MLD430 copies or migrates the block acknowledgment protocol context and the security association context.

[0317] In some embodiments, the target AP MLD430 generates an FT response frame. The block acknowledgment protocol context element and the security association context element in the FT response frame respectively indicate whether the copying or migration result of the block acknowledgment protocol context and the security association context was successful.

[0318] Step 2581: The current AP MLD420 sends an FT response frame to the non-AP MLD410.

[0319] In some embodiments, the FT response frame feedback block confirms that the replication or migration results of the protocol context and the security association context are both successful, and the current AP MLD420 sends an FT response frame to the non-AP MLD410.

[0320] In some embodiments, if the FT response frame feedback block confirms that the replication or migration results of the protocol context and security association context are partially or completely unsuccessful, the target AP MLD430 resends the FT response frame to the current AP MLD420 until the replication or migration results are all successful.

[0321] Step 2590: Non-AP MLD410 sends a link reconfiguration request frame to the current AP MLD420.

[0322] A successful link reconfiguration will only occur if the time between the FT request frame transmission time and the link reconfiguration request frame transmission time does not exceed the link reconfiguration deadline.

[0323] In some embodiments, link reconfiguration is performed between the non-AP MLD410 and the current AP MLD420 and target AP MLD430 attached to the mobile domain MLD in the mobile domain MLD scenario.

[0324] 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 for Current AP MLD (RME for CurrentAPMLD), Reconfiguration Multilink Element for Target AP MLD (RME for TargetAPMLD), Operation Channel Information Element (OCI), and Flow Identifier to Link Mapping Element.

[0325] The link reconfiguration request frame carries an MDE (Mean Decision Entity), instructing a non-AP MLD (Mobile Domain MLD) to request link reconfiguration based on existing multi-links in the current AP MLD and target AP MLD attached to the Mobile Domain MLD. This means either adding a link or deleting a link from existing multi-links. Specifically, for FT-oriented link reconfiguration, the request requests the deletion of all existing links from existing multi-links in the current AP MLD attached to the Mobile Domain MLD, and the creation of one or more new links in the target AP MLD attached to the Mobile Domain MLD.

[0326] The link reconfiguration request frame carries the reconfiguration multilink element (RME for CurrentAPMLD) of the current AP MLD and the reconfiguration multilink element (RME for TargetAPMLD) of the target AP MLD, respectively describing the non-AP MLD request and the reconfiguration multilink information of the current AP MLD and the target AP MLD.

[0327] Optionally, the link reconfiguration request frame carries one or two flow identifier to link mapping elements, providing flow identifier to link mapping information and indicating that a corresponding flow identifier to link mapping request should be made on the link established by the target AP MLD.

[0328] Step 2591: The current AP MLD420 sends a link reconfiguration request frame to the target AP MLD430.

[0329] In some embodiments, after the current AP MLD420 receives a link reconfiguration request frame sent by the non-AP MLD410, it performs link reconfiguration based on the reconfiguration multilink element (RME for CurrentAPMLD) of the current AP MLD in the link reconfiguration request frame, such as deleting all links with the non-AP MLD410.

[0330] In some embodiments, after receiving the link reconfiguration request frame sent by the current AP MLD420, the target AP MLD430 performs link reconfiguration based on the reconfiguration multi-link element (RME for TargetAPMLD) of the target AP MLD in the link reconfiguration request frame, such as creating one or more links.

[0331] Step 25100: The target AP MLD430 sends a link reconfiguration response frame to the current AP MLD420.

[0332] 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 for target AP MLD, Reconfiguration Status List for target AP MLD, Group Key Data, Operational Channel Information (OCI) element, Basic Multilink element, and Flow Identifier to Link Mapping element.

[0333] The link reconfiguration response frame carries an MDE, indicating that the link reconfiguration response frame is a response to a link reconfiguration request frame containing an MDE. That is, it is a response to a link reconfiguration request based on existing multiple links in the current AP MLD and the target AP MLD attached to the mobile domain MLD in the mobile domain MLD scenario.

[0334] The link reconfiguration response frame carries link reconfiguration status code information (i.e., the status code field), indicating the status code for link reconfiguration in the mobile domain MLD scenario.

[0335] If the status code indicates "Reject Mobile Domain Link Reconfiguration", the link reconfiguration response frame does not contain reconfiguration status list information (i.e., the number of reconfiguration status tuples and the reconfiguration status list) for the current AP MLD and the target AP MLD link reconfiguration.

[0336] If the link reconfiguration response frame carries a link reconfiguration status code indicating "SUCCESS", then the link reconfiguration response frame also carries a reconfiguration status list information for the current AP MLD and the target AP MLD link reconfiguration, indicating the number of reconfiguration status tuples and the reconfiguration status list for the current AP MLD and the target AP MLD link reconfiguration. Specifically, in the link reconfiguration response frame, each link ID indicated in the STA-level per-STA Profile field of the corresponding link reconfiguration request frame for the current AP MLD and the target AP MLD contains a reconfiguration status tuple field.

[0337] Specifically, for the reconfiguration status information of the current AP MLD, if the current AP MLD accepts a request to delete a link for a link ID, the corresponding status field in the reconfiguration status tuple field should be set to "SUCCESS". For the reconfiguration status information of the target AP MLD, if the target AP MLD accepts a request to add a link 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 included in the STA-level configuration file field of that link ID in the basic multi-link element should indicate "SUCCESS".

[0338] The link reconfiguration response frame carries a basic multilink element for the target AP MLD, providing STA-granular profile information for one or more affiliated APs of the target AP MLD. If the target AP MLD accepts a link addition request for one or more links, it should include a basic multilink element in the link reconfiguration response frame, which contains STA-granular profile information for each affiliated AP corresponding to the link accepted by the target AP MLD for addition to a non-AP MLD.

[0339] If the link reconfiguration response frame carries a link reconfiguration status code indicating "SUCCESS," meaning the target AP MLD has accepted the request to add one or more links, then both the current AP MLD and the target AP MLD should include a group key data field in the link reconfiguration response frame. For each link added by the target AP MLD, both the current AP MLD and the target AP MLD should include an MLO GTK KDE, an MLO IGTK KDE, and an MLO BIGTKKDE in the group key data field, providing a group key identified by the link ID field for the link added by the target AP MLD.

[0340] Optionally, the link reconfiguration response frame may also include one or two flow identifier-to-link mapping elements, or none at all, to respond to a received link reconfiguration request frame carrying or not carrying flow identifier-to-link mapping elements, indicating the result of the flow identifier-to-link mapping performed between the non-AP MLD and the target AP MLD on the established link. The rules governing the flow identifier-to-link mapping performed between the target AP MLD and the non-AP MLD on the established link, and the manner in which the link reconfiguration response frame responds to a link reconfiguration request frame carrying or not carrying flow identifier-to-link mapping elements and indicates the flow identifier-to-link mapping result, are consistent with the rules and manner in which the association response frame sent by the target AP MLD responds to an association request frame carrying or not carrying flow identifier-to-link mapping elements and indicates the flow identifier-to-link mapping result.

[0341] In some embodiments, the target AP MLD430 generates a link reconfiguration response frame, which includes a list of reconfiguration statuses of the target AP MLD to indicate the link reconfiguration status of the target AP MLD430, such as indicating that the target AP MLD430 has successfully added one or more links.

[0342] Step 25101: The current AP MLD420 sends a link reconfiguration response frame to the non-AP MLD410.

[0343] In some embodiments, after the current AP MLD420 receives the link reconfiguration response frame sent by the target AP MLD430, it 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, it is modified to indicate that all links with non-APMLD410 have been successfully deleted.

[0344] In some embodiments, after the current AP MLD420 receives the link reconfiguration response frame sent by the target AP MLD430, it 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 non-AP MLD410 have been successfully deleted.

[0345] 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 can be omitted or substituted. For example, steps 2510 to 2581 can be omitted, and execution can start from step 2590.

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

[0347] Step 2510 can be implemented as a standalone embodiment, such as by implementing a separate method for sending an authentication request frame; Step 2520 can be implemented as a standalone embodiment, such as as a separate method for sending an authentication response frame; Step 2530 can be implemented as a standalone embodiment, such as by implementing it separately as a method for sending (re)association request frames; Step 2540 can be implemented as a standalone embodiment, such as a method for sending (re)associated response frames; Step 2550 can be implemented as a standalone embodiment, such as a separate method for sending an FT request frame; Step 2551 can be implemented as a standalone embodiment, such as a separate method for sending an FT request frame; Step 2560 can be implemented as a standalone embodiment, such as a separate method for sending an FT response frame; Step 2561 can be implemented as a standalone embodiment, such as a separate method for transmitting an FT response frame; Step 2570 can be implemented as a standalone embodiment, such as a separate method for sending an FT confirmation frame; Step 2571 can be implemented as a standalone embodiment, such as a separate method for sending an FT confirmation frame; Step 2580 can be implemented as a standalone embodiment, such as a method for transmitting an FT response frame implemented separately; Step 2581 can be implemented as a standalone embodiment, such as a separate method for transmitting an FT response frame; Step 2590 can be implemented as a standalone embodiment, such as as a method for sending a link reconfiguration request frame; Step 2591 can be implemented as a standalone embodiment, such as by implementing it separately as a method for sending a link reconfiguration request frame; Step 25100 can be implemented as a standalone embodiment, such as as a method for sending a link reconfiguration response frame; Step 25101 can be implemented as a standalone embodiment, such as a method for sending a link reconfiguration response frame.

[0348] In summary, the method provided in this embodiment sends and / or receives link reconfiguration request frames and link reconfiguration response frames. These frames are used to switch between the current AP MLD and the target AP MLD at different locations based on link reconfiguration. This optimizes the link reconfiguration protocol between the current AP MLD and the target AP MLD at different locations and enables the switching of non-AP MLD between the current AP MLD and the target AP MLD during communication.

[0349] The method provided in this embodiment also eliminates the time when the non-AP MLD loses data connectivity with the current AP MLD and the target AP MLD by sending FT confirmation frames to indicate the copy or migration block confirmation protocol context and security association context, thus maintaining the data continuity between the non-AP MLD and the current AP MLD and the target AP MLD. The block confirmation protocol context is used to ensure the connectivity of data transmission, and the security association context is used to eliminate the need to renegotiate the key after the switch by omitting the key negotiation process.

[0350] The method provided in this embodiment also ensures successful copying or migration of context information by repeatedly sending FT confirmation frames before the copying or migration results indicate success.

[0351] In the above embodiments, Figure 4 Steps 401 to 404 of the embodiment, Figure 5 Step 510 of the embodiment, Figure 23 Steps 2330 to 2341 of the embodiment, Figure 24 Steps 2450 to 2461 of the embodiment and Figure 25 The descriptions in steps 2590 to 25101 of the embodiment can be referenced one-to-one; Figure 5 Step 510 of the embodiment, Figure 23 Steps 2310 to 2321 of the embodiment, Figure 24 Steps 2410 to 2441 of the embodiment and Figure 25 The descriptions in steps 2550 to 2581 of the embodiment can be referenced one-to-one.

[0352] This application proposes a link reconfiguration method for non-AP MLDs under the Mobile Domain MLD architecture to switch from the current AP MLD to the target AP MLD. By optimizing the link reconfiguration protocol for AP MLDs in the same location (i.e., APs attached to the AP MLD are all in the same location) and utilizing the replication, migration or update of relevant communication context and state, data continuity between STA and DS or between non-AP MLD and DS is maintained.

[0353] 1. A link reconfiguration method is proposed based on the mobile domain MLD architecture to convert the non-AP MLD from the current AP MLD to the target AP MLD. That is, under the mobile domain MLD architecture, a method and mechanism are proposed to simultaneously reconfigure the non-AP MLD with the current AP MLD and the target AP MLD located in different positions.

[0354] 2. Based on the Mobile Domain MLD architecture, this paper proposes a link reconfiguration protocol and frame type and format definition and function update for FT-oriented interaction, including: the definition update of reconfiguration request frame and reconfiguration response frame, the FT request and response protocol and the FT resource request and response protocol and the FT ACK frame definition update.

[0355] 3. Propose FT-oriented link reconfiguration rules (i.e., FT-oriented rules for maintaining consistency when reconfiguring links simultaneously in the current AP MLD and the target AP MLD), as well as the related flow identifier to link mapping methods and rules.

[0356] Figure 26 A flowchart of a switching method provided by an exemplary embodiment of this application is shown. The method is performed by the current APMLD and includes: Step 2610: Send and / or receive at least one first frame.

[0357] In this process, at least one first frame is used to enable switching between a non-AP MLD and the current AP MLD and the target AP MLD at different locations based on link reconfiguration.

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

[0359] In some embodiments, the current AP MLD and the target AP MLD belong to the same mobile domain MLD, and the mobile domain MLD is used for at least one of the following: Provides connectivity services between non-AP MLDs or current AP MLDs and target AP MLDs and DS; Maintain data continuity during roaming when a non-AP MLD switches between the current AP MLD and the target AP MLD; Authentication and / or association or re-association of non-AP MLDs; Security associations of non-AP MLDs; Distribution of all or part of the security association information of non-AP MLD; Synchronize all or part of the state and / or buffer information of the higher-level MAC layer of the current AP MLD and the target AP MLD; Manage the distribution of authentication information for non-AP MLD links; Manage the AP MLD-level association or re-association between non-AP MLDs and the current AP MLD and the target AP MLD; For the target AP MLD, select the MAC address corresponding to the target AP MLD for data transmission; The first data is used for synchronization between the current AP MLD and the target AP MLD. The first data is used to maintain data communication between the non-AP MLD and the current AP MLD and the target AP MLD or DS. The exchange or indication of MLD-level information is achieved through the MAC sublayer of the current AP MLD and the target AP MLD.

[0360] In some embodiments, sending and / or receiving at least one first frame includes: Receives a link reconfiguration request frame sent by a non-AP MLD and sends a link reconfiguration request frame to the target 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. Receive the link reconfiguration response frame sent by the target AP MLD, and send a link reconfiguration response frame to the non-AP MLD. The link reconfiguration response frame is used to provide feedback to the non-AP MLD on the link reconfiguration performed with the current AP MLD and the target AP MLD.

[0361] In some embodiments, 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.

[0362] In some embodiments, the first element includes a first reconfiguration multilink element for describing the reconfiguration multilink information between the non-AP MLD and the current AP MLD; The second element includes a second reconfiguration multilink element, which describes the reconfiguration multilink information for the non-AP MLD and the target AP MLD.

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

[0364] In some embodiments, the link reconfiguration response frame includes: The third element corresponding to the current AP MLD is used to indicate the link reconfiguration status corresponding to the current AP MLD; The fourth element corresponding to the target AP MLD is used to indicate the link reconfiguration status corresponding to the target AP MLD.

[0365] In some embodiments, the third element includes at least one of the following: a list of reconfiguration states 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 list of reconfiguration states of the target AP MLD, including at least one reconfiguration state tuple; the number of reconfiguration state tuples of the target AP MLD; The reconfiguration status tuple is used to indicate the reconfiguration status of a link.

[0366] In some embodiments, where the current AP MLD and the target AP MLD belong to the same mobile domain MLD, or where the current AP MLD and the target AP MLD belong to the same mobile domain, the method further includes: Send and / or receive first indication information, which is used to indicate the mobile domain (MLD).

[0367] In some embodiments, 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 Services Set (BSS) switching FT request frames; FT response frame; FT confirmation frame; FT response frame; Associated request frame; Associated response frame; Reassociation request frame; Reassociation response frame; The request frame is used to instruct the non-AP MLD to request the copying or migration of context information between the current AP MLD and the target AP MLD in order to maintain data connectivity during the handover process. The response frame is used to instruct the non-AP MLD on the copying or migration results of context information between the current AP MLD and the target AP MLD.

[0368] In some embodiments, the first indication information includes at least one of the following: Mobile Domain MLD Identifier; Mobile domain MLD MAC address.

[0369] In some embodiments, the switching is based on FT, and the method further includes: Send and / or receive second indication information, which indicates whether FT is supported or permitted between the current AP MLD and the target AP MLD that are attached to the same mobile domain MLD.

[0370] In some embodiments, a Fourier Transmission (FT) is performed between the current AP MLD and the target AP MLD, which are attached to the same mobile domain MLD, to maintain data connectivity during the handover process.

[0371] In some embodiments, 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; Associated request frame; Associated response frame; Reassociation request frame; Reassociation response frame; The request frame is used to instruct the non-AP MLD to request the copying or migration of context information between the current AP MLD and the target AP MLD in order to maintain data connectivity during the handover process. The response frame is used to instruct the non-AP MLD on the copying or migration results of context information between the current AP MLD and the target AP MLD.

[0372] In some embodiments, the link reconfiguration response frame includes a status code indicating the status of link reconfiguration in a mobile domain (MLD) scenario.

[0373] In some embodiments, when the status code takes the first value, it is used to indicate that the mobile domain link reconfiguration is rejected.

[0374] In some embodiments, the link reconfiguration response frame includes: group key data, which indicates the group key that has been successfully added to the link corresponding to the target AP MLD.

[0375] In some embodiments, the link reconfiguration response frame includes: a basic multilink element for providing STA-granular profiles for one or more affiliated APs of the target AP MLD.

[0376] In some embodiments, the link reconfiguration response frame includes a second flow identifier to link mapping element, used to respond to a request from a non-AP MLD to perform flow identifier to link mapping on a link established between the non-AP MLD and the target AP MLD.

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

[0378] In some embodiments, the link reconfiguration 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.

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

[0380] In some embodiments, sending and / or receiving at least one second frame includes: Receive request frames sent by non-AP MLD and send request frames to target AP MLD. The request frames are used to instruct the non-AP MLD to request the synchronization of context information related to the non-AP MLD between the current AP MLD and the target AP MLD. Receive response frames sent by the target AP MLD and send response frames to the non-AP MLD. The response frames are used to provide feedback to the non-AP MLD on the context information related to the non-AP MLD in synchronizing between the current AP MLD and the target AP MLD.

[0381] In some embodiments, the context information includes at least one of the following: First context information, which is information related to the block acknowledgment protocol context; Second context information is information related to the security-associated context.

[0382] In some embodiments, the first context information is carried in the block acknowledgment protocol context element.

[0383] In some embodiments, 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: The device where the block confirmation protocol context element resides; Is the device containing the Block Acknowledgment Protocol (BAP) context element the same as the non-AP MLD that the BAP context targets? If the device where the block confirmation protocol context element resides is the same device as the non-AP MLD to which the block confirmation protocol context is targeted, then the non-AP MLD to which the block confirmation protocol context is targeted. The number of block acknowledgment protocol context parameters included in the block acknowledgment protocol context element.

[0384] In some embodiments, the block confirmation protocol context element includes a block confirmation protocol context parameter set list field, which 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.

[0385] In some embodiments, the block acknowledgment protocol context parameter set subfield is used to indicate at least one of the following: The role of the device in the block acknowledgment protocol context; The non-AP MLD that the Block Acknowledgment Protocol context refers to; Block confirmation parameter set; Block confirmation timeout value.

[0386] In some embodiments, if the Block Acknowledgment Protocol Context Parameter Set subfield is used to indicate that the device residing in the Block Acknowledgment Protocol Context plays the role of an initiator within the Block Acknowledgment Protocol Context; the Block Acknowledgment Protocol Context Parameter Set subfield is also used to indicate at least one of the following: Send window start sequence number; Send window size.

[0387] In some embodiments, if the Block Acknowledgment Protocol Context Parameter Set subfield is used to indicate that the device residing in the Block Acknowledgment Protocol Context plays the role of a receiver within the Block Acknowledgment Protocol Context; the Block Acknowledgment Protocol Context Parameter Set subfield is also used to indicate at least one of the following: Receive buffer start sequence number; Receive window size; Record the starting sequence number of the bitmap; Record the maximum sequence number of the bitmap; Record the size of the bitmap.

[0388] In some embodiments, the block confirmation parameter set includes at least one of the following: Indicator information indicating whether aggregated MAC service data units are supported; Block confirmation strategy; Stream identifier; Buffer size.

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

[0390] In some embodiments, a security association context element includes a security association context parameter control field, which is used to indicate at least one of the following: The device where the security association context element resides; Is the device where the security association context element resides the same device as the non-AP MLD to which the security association context is targeted? If the device where the security association context element resides and the non-AP MLD to which the security association context is targeted are the same device, then the non-AP MLD to which the security association context is targeted. The number of security association context parameter sets included in the security association context element.

[0391] In some embodiments, a security association context element includes a security association context parameter set list field, which 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.

[0392] In some embodiments, the security association context parameter set subfield is used to indicate at least one of the following: The role of the device within the security association context; The non-AP MLD that the security association context refers to; The security association type of the security association context.

[0393] In some embodiments, the security association context parameter set subfield is used to indicate that the device residing in the security association context plays the role of an initiator within the security association context; the security association context parameter set subfield is also used to indicate at least one of the following: Number of replay counters; TID; The count of the replay counter for TID.

[0394] In some embodiments, if the security association context parameter set subfield is used to indicate that the device in the security association context plays the role of a receiver in the security association context; the security association context parameter set subfield is also used to indicate at least one of the following: Package number counter count; TID; The count for the package number counter for TID.

[0395] In some embodiments, the second frame further includes: The third indication information is used to indicate context information, including block acknowledgment protocol context and / or security association context.

[0396] In some embodiments, the request frame is sent from the non-AP MLD to the current AP MLD, and then from 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 from the current AP MLD to the non-AP MLD.

[0397] In some embodiments, the switching is based on FT, the request frame is an FT acknowledgment frame, and the response frame is an FT reply frame.

[0398] In some embodiments, the current AP MLD and the target AP MLD belong to the same mobile domain MLD, and the method further includes: Receive FT request frames sent by non-AP MLD, and send FT request frames to target AP MLD; Receive FT response frames sent by the target AP MLD, and send FT response frames to the non-AP MLD.

[0399] In some embodiments, the method further includes: receiving an association request frame sent by a non-AP MLD, and sending an association request frame to a target AP MLD; Receive associated response frames sent by the target AP MLD, and send associated response frames to non-AP MLDs.

[0400] In some embodiments, the handover is based on FT, and if the first duration is less than or equal to the link reconfiguration deadline, the link reconfiguration is performed by the non-AP MLD; The first duration refers to the duration between the transmission time of the FT request frame and the transmission time of the link reconfiguration request frame, and the first frame includes the link reconfiguration request frame.

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

[0402] In some embodiments, the fourth indication information uses a start time and a timeout interval to indicate, or, The fourth instruction uses a deadline as the indication.

[0403] In some embodiments, the start time is implicitly represented by the time the fourth indication information is sent or received; The timeout interval is explicitly indicated by the fourth indication information.

[0404] In some embodiments, the method further includes: If the target AP MLD agrees to establish at least one link, the current AP MLD agrees to delete all links; If the target AP MLD refuses to establish all links, the current AP MLD refuses to delete at least one link.

[0405] When the target AP MLD rejects all requests to add links (i.e., 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 should retain at least one established link to maintain the association between the non-AP MLD and the current AP MLD.

[0406] In some embodiments, if the target AP MLD agrees to establish at least one link, the current AP MLD agrees to delete all links except those that it requests to be retained.

[0407] For FT-oriented link reconfiguration based on the current AP MLD and the target AP MLD, when the target AP MLD accepts a request to add at least one link (i.e., the target AP MLD agrees to establish at least one link), the current AP MLD should accept all link deletion requests except for the links that are requested to be retained. That is, it should refuse to delete the links that are requested to be retained, such as links that are retained as backup links during roaming.

[0408] For detailed implementation information of step 2610, please refer to [link / reference]. Figure 5 Step 510 of the embodiment will not be described again here.

[0409] In summary, the method provided in this embodiment sends and / or receives at least one first frame, which is used to switch between the current AP MLD and the target AP MLD at different locations based on link reconfiguration. This optimizes the link reconfiguration protocol between the current AP MLD and the target AP MLD at different locations and realizes the switching of non-AP MLD between the current AP MLD and the target AP MLD during communication.

[0410] The method provided in this embodiment also eliminates the time when the non-AP MLD loses data connectivity with the current AP MLD and the target AP MLD by copying or migrating the block confirmation protocol context and the security association context, thus maintaining the data continuity between the non-AP MLD and the current AP MLD and the target AP MLD. The block confirmation protocol context is used to ensure the connectivity of data transmission, and the security association context is used to eliminate the need to renegotiate the key after the switch by omitting the key negotiation process.

[0411] Figure 27 A flowchart of a switching method provided by an exemplary embodiment of this application is shown, the method being performed by a target APMLD, the method comprising: Step 2710: Send and / or receive at least one first frame.

[0412] In this process, at least one first frame is used to enable switching between a non-AP MLD and the current AP MLD and the target AP MLD at different locations based on link reconfiguration.

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

[0414] In some embodiments, the current AP MLD and the target AP MLD belong to the same mobile domain MLD, and the mobile domain MLD is used for at least one of the following: Provides connectivity services between non-AP MLDs or current AP MLDs and target AP MLDs and DS; Maintain data continuity during roaming when a non-AP MLD switches between the current AP MLD and the target AP MLD; Authentication and / or association or re-association of non-AP MLDs; Security associations of non-AP MLDs; Distribution of all or part of the security association information of non-AP MLD; Synchronize all or part of the state and / or buffer information of the higher-level MAC layer of the current AP MLD and the target AP MLD; Manage the distribution of authentication information for non-AP MLD links; Manage the AP MLD-level association or re-association between non-AP MLDs and the current AP MLD and the target AP MLD; For the target AP MLD, select the MAC address corresponding to the target AP MLD for data transmission; The first data is used for synchronization between the current AP MLD and the target AP MLD. The first data is used to maintain data communication between the non-AP MLD and the current AP MLD and the target AP MLD or DS. The exchange or indication of MLD-level information is achieved through the MAC sublayer of the current AP MLD and the target AP MLD.

[0415] In some embodiments, sending and / or receiving at least one first frame includes: Receive the link reconfiguration request frame sent by the current AP MLD. The link reconfiguration request frame is used to instruct the non-APMLD to request link reconfiguration with the current AP MLD and the target AP MLD to achieve handover. Send a link reconfiguration response frame to the current AP MLD. The link reconfiguration response frame is used to report the link reconfiguration with the current AP MLD and the target AP MLD to the non-AP MLD.

[0416] In some embodiments, the link reconfiguration request frame includes: 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; 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.

[0417] In some embodiments, the first element includes a first reconfiguration multilink element for describing the reconfiguration multilink information between the non-AP MLD and the current AP MLD; The second element includes a second reconfiguration multilink element, which describes the reconfiguration multilink information for the non-AP MLD and the target AP MLD.

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

[0419] In some embodiments, the link reconfiguration response frame includes: The third element corresponding to the current AP MLD is used to indicate the link reconfiguration status corresponding to the current AP MLD; The fourth element corresponding to the target AP MLD is used to indicate the link reconfiguration status corresponding to the target AP MLD.

[0420] In some embodiments, the third element includes at least one of the following: a list of reconfiguration states 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 list of reconfiguration states of the target AP MLD, including at least one reconfiguration state tuple; the number of reconfiguration state tuples of the target AP MLD; The reconfiguration status tuple is used to indicate the reconfiguration status of a link.

[0421] In some embodiments, where the current AP MLD and the target AP MLD belong to the same mobile domain MLD, or where the current AP MLD and the target AP MLD belong to the same mobile domain, the method further includes: Send and / or receive first indication information, which is used to indicate the mobile domain (MLD).

[0422] In some embodiments, 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 Services Set (BSS) switching FT request frames; FT response frame; FT confirmation frame; FT response frame; Associated request frame; Associated response frame; Reassociation request frame; Reassociation response frame; The request frame is used to instruct the non-AP MLD to request the copying or migration of context information between the current AP MLD and the target AP MLD in order to maintain data connectivity during the handover process. The response frame is used to instruct the non-AP MLD on the copying or migration results of context information between the current AP MLD and the target AP MLD.

[0423] In some embodiments, the first indication information includes at least one of the following: Mobile Domain MLD Identifier; Mobile domain MLD MAC address.

[0424] In some embodiments, the switching is based on FT, and the method further includes: Send and / or receive second indication information, which indicates whether FT is supported or permitted between the current AP MLD and the target AP MLD that are attached to the same mobile domain MLD.

[0425] In some embodiments, a Fourier Transmission (FT) is performed between the current AP MLD and the target AP MLD, which are attached to the same mobile domain MLD, to maintain data connectivity during the handover process.

[0426] In some embodiments, 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; Associated request frame; Associated response frame; Reassociation request frame; Reassociation response frame; The request frame is used to instruct the non-AP MLD to request the copying or migration of context information between the current AP MLD and the target AP MLD in order to maintain data connectivity during the handover process. The response frame is used to instruct the non-AP MLD on the copying or migration results of context information between the current AP MLD and the target AP MLD.

[0427] In some embodiments, the link reconfiguration response frame includes a status code indicating the status of link reconfiguration in a mobile domain (MLD) scenario.

[0428] In some embodiments, when the status code takes the first value, it is used to indicate that the mobile domain link reconfiguration is rejected.

[0429] In some embodiments, the link reconfiguration response frame includes: group key data, which indicates the group key that has been successfully added to the link corresponding to the target AP MLD.

[0430] In some embodiments, the link reconfiguration response frame includes: a basic multilink element for providing STA-granular profiles for one or more affiliated APs of the target AP MLD.

[0431] In some embodiments, the link reconfiguration response frame includes: The second flow identifier to link mapping element is used to respond to a request from a non-AP MLD to map flow identifiers to links on the link established between the target AP MLD.

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

[0433] In some embodiments, the link reconfiguration 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.

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

[0435] In some embodiments, sending and / or receiving at least one second frame includes: Receive a request frame sent by the current AP MLD. The request frame is used to instruct the non-AP MLD to request the synchronization of context information related to the non-AP MLD between the current AP MLD and the target AP MLD. Send a response frame to the current AP MLD. The response frame is used to feed back context information related to the non-AP MLD to the non-AP MLD for synchronization between the current AP MLD and the target AP MLD.

[0436] In some embodiments, the context information includes at least one of the following: First context information, which is information related to the block acknowledgment protocol context; Second context information is information related to the security-associated context.

[0437] In some embodiments, the first context information is carried in the block acknowledgment protocol context element.

[0438] In some embodiments, 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: The device where the block confirmation protocol context element resides; Is the device containing the Block Acknowledgment Protocol (BAP) context element the same as the non-AP MLD that the BAP context targets? If the device where the block confirmation protocol context element resides is the same device as the non-AP MLD to which the block confirmation protocol context is targeted, then the non-AP MLD to which the block confirmation protocol context is targeted. The number of block acknowledgment protocol context parameters included in the block acknowledgment protocol context element.

[0439] In some embodiments, the block confirmation protocol context element includes a block confirmation protocol context parameter set list field, which 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.

[0440] In some embodiments, the block acknowledgment protocol context parameter set subfield is used to indicate at least one of the following: The role of the device in the block acknowledgment protocol context; The non-AP MLD that the Block Acknowledgment Protocol context refers to; Block confirmation parameter set; Block confirmation timeout value.

[0441] In some embodiments, if the Block Acknowledgment Protocol Context Parameter Set subfield is used to indicate that the device residing in the Block Acknowledgment Protocol Context plays the role of an initiator within the Block Acknowledgment Protocol Context; the Block Acknowledgment Protocol Context Parameter Set subfield is also used to indicate at least one of the following: Send window start sequence number; Send window size.

[0442] In some embodiments, if the Block Acknowledgment Protocol Context Parameter Set subfield is used to indicate that the device residing in the Block Acknowledgment Protocol Context plays the role of a receiver within the Block Acknowledgment Protocol Context; the Block Acknowledgment Protocol Context Parameter Set subfield is also used to indicate at least one of the following: Receive buffer start sequence number; Receive window size; Record the starting sequence number of the bitmap; Record the maximum sequence number of the bitmap; Record the size of the bitmap.

[0443] In some embodiments, the block confirmation parameter set includes at least one of the following: Indicator information indicating whether aggregated MAC service data units are supported; Block confirmation strategy; Stream identifier; Buffer size.

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

[0445] In some embodiments, a security association context element includes a security association context parameter control field, which is used to indicate at least one of the following: The device where the security association context element resides; Is the device where the security association context element resides the same device as the non-AP MLD to which the security association context is targeted? If the device where the security association context element resides and the non-AP MLD to which the security association context is targeted are the same device, then the non-AP MLD to which the security association context is targeted. The number of security association context parameter sets included in the security association context element.

[0446] In some embodiments, a security association context element includes a security association context parameter set list field, which 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.

[0447] In some embodiments, the security association context parameter set subfield is used to indicate at least one of the following: The role of the device within the security association context; The non-AP MLD that the security association context refers to; The security association type of the security association context.

[0448] In some embodiments, the security association context parameter set subfield is used to indicate that the device residing in the security association context plays the role of an initiator within the security association context; the security association context parameter set subfield is also used to indicate at least one of the following: Number of replay counters; TID; The count of the replay counter for TID.

[0449] In some embodiments, if the security association context parameter set subfield is used to indicate that the device in the security association context plays the role of a receiver in the security association context; the security association context parameter set subfield is also used to indicate at least one of the following: Package number counter count; TID; The count for the package number counter for TID.

[0450] In some embodiments, the second frame further includes: The third indication information is used to indicate context information, including block acknowledgment protocol context and / or security association context.

[0451] In some embodiments, the request frame is sent from the non-AP MLD to the current AP MLD, and then from 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 from the current AP MLD to the non-AP MLD.

[0452] In some embodiments, the switching is based on FT, the request frame is an FT acknowledgment frame, and the response frame is an FT reply frame.

[0453] In some embodiments, the current AP MLD and the target AP MLD belong to the same mobile domain MLD, and the method further includes: Receive the FT request frame sent by the current AP MLD; Send an FT response frame to the current AP MLD.

[0454] In some embodiments, the method further includes: Receive the association request frame sent by the current AP MLD; Send an associated response frame to the current AP MLD.

[0455] In some embodiments, switching is based on FT. If the first duration is less than or equal to the link reconfiguration deadline, the link reconfiguration is performed by non-APMLD. The first duration refers to the duration between the transmission time of the FT request frame and the transmission time of the link reconfiguration request frame, and the first frame includes the link reconfiguration request frame.

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

[0457] In some embodiments, the fourth indication information uses a start time and a timeout interval to indicate, or, The fourth instruction uses a deadline as the indication.

[0458] In some embodiments, the start time is implicitly represented by the time the fourth indication information is sent or received; The timeout interval is explicitly indicated by the fourth indication information.

[0459] For detailed implementation information of step 2710, please refer to [link / reference]. Figure 5 Step 510 of the embodiment will not be described again here.

[0460] In summary, the method provided in this embodiment sends and / or receives at least one first frame, which is used to switch between the current AP MLD and the target AP MLD at different locations based on link reconfiguration. This optimizes the link reconfiguration protocol between the current AP MLD and the target AP MLD at different locations and realizes the switching of non-AP MLD between the current AP MLD and the target AP MLD during communication.

[0461] The method provided in this embodiment also eliminates the time when the non-AP MLD loses data connectivity with the current AP MLD and the target AP MLD by copying or migrating the block confirmation protocol context and the security association context, thus maintaining the data continuity between the non-AP MLD and the current AP MLD and the target AP MLD. The block confirmation protocol context is used to ensure the connectivity of data transmission, and the security association context is used to eliminate the need to renegotiate the key after the switch by omitting the key negotiation process.

[0462] In the above embodiments, steps with the same sequence number can be considered as the same step. Wherein, Figure 4 Corresponding embodiments, Figure 5 Corresponding embodiments, Figure 23 Corresponding embodiments, Figure 24 Corresponding embodiments, Figure 25 Corresponding embodiments, Figure 26 Corresponding embodiments and Figure 27 The corresponding embodiments can be implemented individually or in combination, and this application does not limit them.

[0463] Figure 28 A block diagram of a non-access point multilink device provided in an exemplary embodiment of this application is shown. The device can be implemented as a non-access point multilink device or as part of a non-access point multilink device by software or hardware or a combination of both. The device includes a transmission module 2810, wherein the function of the transmission module 2810 is implemented by a receiver or transmitter in the non-access point multilink device.

[0464] The transmission module 2810 is used to send and / or receive at least one first frame, the at least one first frame being used to enable switching between two access point multilink devices at different locations based on link reconfiguration.

[0465] In one possible design of this embodiment, the two access point multilink devices belong to the same mobile domain (MLD), or the two access point multilink devices belong to the same mobile domain.

[0466] A Mobile Domain MLD, also known as a Logical Access Point Multiple Link Device, is a device that treats multiple access point multiple links that are not located in the same location as a single MLD. In this embodiment, the specific name of the Mobile Domain MLD is not limited.

[0467] In one 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: Scenario 1: When a non-access point multi-link device is associated with a mobile domain MLD, and two access point multi-link devices belong to the same mobile domain MLD, the non-access point multi-link device performs a handover of the access point multi-link device-level association to which the mobile domain MLD belongs between the two access point multi-link devices. Scenario 2: When a non-access point multi-link device is associated with only one of two access point multi-link devices, and the two access point multi-link devices are not attached to the same mobile domain (MLD), the non-access point multi-link device switches its association between the two access point multi-link devices.

[0468] The term "transition" in this application embodiment can also be replaced with "conversion".

[0469] For handover scenario one, handover at the level of access point multi-link device association attached to a mobile domain MLD refers to a situation where, before the handover, a non-access point multi-link device is associated with the mobile domain MLD, and the non-access point multi-link device establishes multiple links with one access point multi-link device attached to the mobile domain MLD (i.e., all or part of the links established between the non-access point multi-link device and the mobile domain MLD are links between the non-access point multi-link device and one access point multi-link device attached to the mobile domain MLD). After the handover, the non-access point multi-link device remains associated with the mobile domain MLD, and the non-access point multi-link device establishes multiple links with another access point multi-link device attached to the mobile domain MLD (i.e., all or part of the links established between the non-access point multi-link device and the mobile domain MLD are links between the non-access point multi-link device and another access point multi-link device attached to the mobile domain MLD).

[0470] For the second handover scenario, the non-access point multilink device associates with access point multilink devices attached to different mobile domain MLDs before and after the handover, thereby performing the associated handover.

[0471] For the mobile domain MLD attached to the current access point multilink device in two access point multilink devices, the mobile domain MLD is attached to multiple access point multilink devices including the current access point multilink device.

[0472] For a mobile domain MLD attached to the target access point multilink device in two access point multilink devices, the mobile domain MLD is attached to multiple access point multilink devices including the target access point multilink device.

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

[0474] In one possible design of this embodiment, the two access point multilink devices belong to the same mobile domain MLD, and the mobile domain MLD is used for at least one of the following: • Provides connectivity services between a non-access point multilink device or two access point multilink devices and the DS; • Maintain data continuity during handover between two access point multilink devices for non-access point multilink devices during roaming; • Authentication and / or association or reassociation of non-access point multi-link devices; • Security association of non-access point multi-link devices; • Distribution of all or part of the security association information of non-access point multi-link devices; • Synchronization of all or part of the status and / or buffer information of the higher layer MAC of the two access point multi-link devices; • Manage the distribution of authentication information for non-access point multi-link devices; • Manage the association or re-association at the access point multilink level between non-access point multilink devices and two access point multilink devices; • For the target access point multilink device that establishes a multilink with the non-access point multilink device in the two access point multilink devices, select the MAC address corresponding to the target access point multilink device for data transmission; • The first data is synchronized between the two access point multilink devices. The first data is used to maintain data communication between the non-access point multilink device and the two access point multilink devices or DS. • Exchange or indicate device-level information through the MAC sublayer of a multi-link device with two access points.

[0475] In one possible design of this embodiment, the transmission module 2810 is used to send a link reconfiguration request frame, which is used to instruct the non-access point multi-link device to request link reconfiguration with two access point multi-link devices to achieve handover. Receive link reconfiguration response frames, which are used to feed back the link reconfiguration performed with the two access point multilink devices to the non-access point multilink device.

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

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

[0478] When a non-access point multi-link device needs to switch from communicating with the current access point multi-link device to communicating with the 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. The link reconfiguration request frame is used to request the deletion of at least one link between the non-access point multi-link device and the current access point multi-link device. The current access point multi-link device sends a link reconfiguration request frame to the target access point multi-link device. The link reconfiguration request frame is used to request the establishment of at least one link between the non-access point multi-link device and the target access point multi-link device.

[0479] 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 has been 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 has deleted a link, and whether the target access point multi-link device has established a link with the non-access point multi-link device.

[0480] In one possible design of this embodiment, the two access point multilink devices include a current access point multilink device and a target access point multilink device; The link reconfiguration request frame includes: The first element corresponding to the current access point multi-link device is used to delete at least one link between the current access point multi-link device; The second element corresponding to the target access point multilink device is used to establish at least one link with the target access point multilink device.

[0481] In one possible design of this embodiment, the first element includes a first reconfiguration multilink element, used to describe the reconfiguration multilink information between the non-access point multilink device and the current access point multilink device; The second element includes a second reconfiguration multilink element, which describes the reconfiguration multilink information between the non-access point multilink device and the target access point multilink device.

[0482] In one possible design of this embodiment, the link reconfiguration request frame further includes: The first flow identifier to link mapping element is used to request the mapping of flow identifiers to links on the links established between the target access point and the multi-link device.

[0483] In one possible design of this embodiment, the format of the link reconfiguration request frame is as follows: Figure 4 Table 1 in the embodiments is shown.

[0484] 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, and the link reconfiguration response frame includes: The third element corresponding to the current access point multi-link device is used to indicate the link reconfiguration status corresponding to the current access point multi-link device; The fourth element corresponding to the target access point multi-link device is used to indicate the link reconfiguration status corresponding to the target access point multi-link device.

[0485] 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; the number of reconfiguration state tuples of the current access point multi-link device; 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 tuple; the number of reconfiguration state tuples of the target access point multi-link device; The reconfiguration status tuple is used to indicate the reconfiguration status of a link.

[0486] In one possible design of this embodiment, the link reconfiguration response frame can be a protected EHT or UHR, UHR+ type action frame. The format of the link reconfiguration response frame is as follows: Figure 4 Table 2 in the embodiments is shown.

[0487] In one possible design of this embodiment, the two access point multilink devices belong to the same mobile domain (MLD), or the two access point multilink devices belong to the same mobile domain. The transmission module 2810 is also used to send and / or receive first indication information, which is used to indicate the mobile domain (MLD).

[0488] In one possible design of this embodiment, 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; • FT request frame; •FT response frame; •FT confirmation frame; •FT response frame; • Associated request frame; • Associated response frame; • Reassociation request frame; • Reassociate response frames; The request frame is used to instruct the non-access point multi-link device to request the copying or migration of context information between two access point multi-link devices in order to maintain data connectivity during the handover process. The response frame is used to instruct the non-access point multi-link device on the result of the copying or migration of context information between the two access point multi-link devices.

[0489] In one possible design of this embodiment, the first indication information includes at least one of the following: • Mobile Domain MLD Identifier; • Mobile Domain (MLD) MAC address.

[0490] For example, the first indication information is called a Mobile Domain Element (MDE), which is used to indicate link reconfiguration in a Mobile Domain Multi-Link (MLD) scenario. It carries MLD information (such as the MLD identifier or MAC address) and whether the FT (Flexible Transfer) is within the same MLD. Access Point Multi-Link (APML) devices can use the MDE to announce that they are included in or attached to a MLD, to announce their support for FT functionality, and to provide FT policy information, including whether FT is supported or permitted between two APML devices attached to the same MLD.

[0491] In one possible design of this embodiment, the handover is based on FT, and the transmission module 2810 is also used to send and / or receive second indication information, which indicates whether FT is supported or allowed between two access point multilink devices attached to the same mobile domain MLD.

[0492] FT is performed between two access point multilink devices belonging to the same mobile domain MLD, compared to FT between two access point multilink devices, to maintain data connectivity during handover.

[0493] In one possible design of this embodiment, 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; • Associated request frame; • Associated response frame; • Reassociation request frame; • Reassociate response frames; The request frame is used to instruct the non-access point multi-link device to request the copying or migration of context information between two access point multi-link devices in order to maintain data connectivity during the handover process. The response frame is used to instruct the non-access point multi-link device on the result of the copying or migration of context information between the two access point multi-link devices.

[0494] In one possible design of this embodiment, based on the Mobile Domain MLD architecture, the high-level architecture of the Mobile Domain MLD and its associated access point multi-link devices and non-access point multi-link devices, where a non-access point multi-link device (or STA) switches from the current access point multi-link device (or AP) to the target access point multi-link device (or AP), is as follows: Figure 6 As shown.

[0495] The high-level architecture includes at least one of the following: DS610, Mobile Domain MLD General Sublayer 620, First Handover Module 630, Auxiliary MLD Upper Layer MAC Sublayer 640, Auxiliary MLD Lower Layer MAC Sublayer 650, Second Handover Module 660, Non-Access Point Multilink Device Lower Layer MAC Sublayer 670, and Non-Access Point Multilink Device Upper Layer MAC Sublayer 680.

[0496] The DS610 is an architecture designed to distribute computing and communication functions across multiple nodes or devices. The primary function of DS is to coordinate and manage computing and communication tasks in a distributed environment to achieve efficient data transfer and collaboration.

[0497] The Mobile Domain MLD General Sublayer 620 includes a Mobile Domain Access Point Multiple Link Device 621, whose MLD MAC address is Q, and which communicates with the DS610 via a first MAC-Service Access Point (SAP).

[0498] Access point multi-link device 1 with MLD MAC address M and access point multi-link device 2 with MLD MAC address N have the same function. The following explanation uses access point multi-link device 1 as an example. Mobile domain access point multi-link device 621 communicates with access point multi-link device 1 via a first handover module 630. The first handover module 630 can be a module in mobile domain access point multi-link device 621, a module in access point multi-link device 1, or a module in another access point multi-link device.

[0499] Access point multi-link device 1 communicates with AP1 (MAC address w) and AP2 (MAC address x) via a second MAC-SAP. AP1 and AP2 have the same function; AP1 will be used as an example for explanation. AP1 communicates with the second switching module 660 via link 1. The second switching module 660 can be a module in non-access point multi-link device 681, a module in access point multi-link device 1, or a module in other access point multi-link devices.

[0500] Non-AP STA1 with MAC address y and non-AP STA2 with MAC address z have the same function. 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. The following explanation uses non-AP STA1 as an example. The MLD non-access point multi-link device with MAC address P communicates with non-AP STA1 via the fourth MAC-SAP.

[0501] The functionality of the Mobile Domain MLD General Sublayer 620 includes at least one of the following: (1) Provide a distributed system access function (DSAF) to the auxiliary access point multilink devices (e.g., access point multilink device 1 and access point multilink device 2) of the mobile domain MLD. (2) Authentication, association, and reassociation functions between the non-access point multi-link device 681 and the mobile domain access point multi-link device 621; (3) Security associations, such as Pairwise Master Key Security Association (PMKSA) and Pairwise Transient Key Security Association (PTKSA), and manage the distribution of GTK / IGTK / BIGTK; (4) Manage the partial association and reassociation functions between the non-access point multilink device 681 and the auxiliary access point multilink device of the mobile domain access point multilink device; (5) For the auxiliary access point multilink device associated with the non-access point multilink device 681, select the MAC of the corresponding auxiliary access point multilink device for data transmission. (6) Synchronization (copying or migration) of all or part of the state and buffer information of the upper layer MAC of the subordinate MLD of the mobile domain MLD. (7) Exchange / instructions for device-level management information through the MAC sublayer of the attached MLD.

[0502] This includes the synchronization of all or part of the state and buffer information of the higher-level MAC layer of the mobile domain MLD's upper-layer MLD, including: For a designated non-access point multilink device associated with a mobile domain MLD, the non-access point multilink device switches from the currently associated access point multilink device to the target access point multilink device to be associated. This involves synchronizing all or part of the higher-level state and buffer information of the upper-layer MAC of the affiliated MLD to maintain the continuity of data communication sessions and data transmission during the process of the non-access point multilink device associating with different affiliated access point multilink devices due to roaming.

[0503] All or part of the higher-layer state and buffer information of the upper-layer MAC of the mobile domain MLD, i.e., the session or protocol state and buffer information maintained during data exchange with the designated non-access point multilink device (for the designated non-access point multilink device), includes at least one of the following: (1) The allocation status of sequence number (SN) / packet number (PN) of unicast frames and related buffer data; (2) SN allocation status and related buffer data of the group-addressed MAC Service Data Unit (MSDU); (3) Energy-saving buffer data for individually addressed frames; (4) Block Ack session status and duplicate detection and reordering buffer data of received frames; (5) The PN counter status of the transmitting end and the replay detection status and related buffer data of the receiving end.

[0504] In one possible design of this embodiment, the link reconfiguration response frame includes a status code indicating the status of link reconfiguration in a mobile domain (MLD) scenario. If the status code takes a first value, it indicates that mobile domain link reconfiguration is rejected.

[0505] The format of the link reconfiguration response frame is as follows: Figure 4Table 2 in the embodiments is shown.

[0506] In one possible design of this embodiment, both the reconfiguration state list subfield of the current access point multi-link device and the reconfiguration state list subfield of the target access point multi-link device adopt the reconfiguration state list format. The reconfiguration state list contains one or more reconfiguration state tuples, such as... Figure 7 As shown. Figure 7 This illustration shows a schematic diagram of a reconfiguration status list subdomain format provided in an exemplary embodiment of this application. The reconfiguration status list subdomain format includes at least one of the following: a Link ID Info field and a Status field. In this embodiment, the fields and subdomains have the same meaning.

[0507] The link ID field occupies 1 byte, and the status field occupies 2 bytes. The format of the link ID field is defined according to IEEE 802.11be. The link ID field represents the link identifier corresponding to the access point multi-link device, used in the corresponding link reconfiguration request frame to delete an existing link or add a new link. The status field indicates the status of the link reconfiguration operation corresponding to the link ID field.

[0508] The above-described reconfiguration status list subfield format is an exemplary possibility. In different embodiments or designs, it is possible that at least one of the following designs may change: the position of the reconfiguration status list subfield field in the frame, its arrangement order with other fields, the number of bytes occupied, or the field name. This embodiment does not limit this.

[0509] In one possible design of this embodiment, the link reconfiguration response frame includes: group key data, used to indicate the group key successfully added to the link corresponding to the target access point multi-link device. The group key data subfield may optionally appear and contain the group key (status code value equal to SUCCESS) successfully added to the link corresponding to the target access point multi-link device. Figure 8 A schematic diagram of a group key data subfield format provided in an exemplary embodiment of this application is shown. The group key data subfield format includes at least one of the following: a key data length field and a key data field.

[0510] The key data length field occupies 2 bytes, and the number of bytes occupied by the key data field is variable.

[0511] The group key data subfield contains an MLO GTK KDE, an MLO IGTK KDE, and an MLO BIGTKKDE, providing a group key identified by the link ID subfield for the links added to the target access point multilink device.

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

[0513] The above-described group key data subfield format is an exemplary possibility. In different embodiments or designs, it is possible that at least one of the following designs may change: the position of the group key data subfield field in the frame, its arrangement order with other fields, the number of bytes occupied, or the field name. This embodiment does not limit this.

[0514] In one possible design of this embodiment, the link reconfiguration response frame includes: a basic multilink element for providing STA-granular configuration files for one or more affiliated APs of the target access point multilink device.

[0515] When at least one link is added to the target access point multilink device, the link reconfiguration response frame includes a basic multilink element for providing STA profiles for one or more affiliated APs of the target access point multilink device, each AP corresponding to a link successfully added to the multilink reconfiguration of the non-access point multilink device. When no link is added to the target access point multilink device, the link reconfiguration response frame does not include the basic multilink element.

[0516] In one possible design of this embodiment, the link reconfiguration response frame includes a second flow identifier to link mapping element, used to respond to a request to perform flow identifier to link mapping on the link established with the target access point multilink device.

[0517] In one possible design of this embodiment, the link reconfiguration response frame is used by the access point multilink device (including the current access point multilink device and the target access point multilink device) in the mobile domain MLD scenario to respond to the link reconfiguration request frame sent from the non-access point multilink device, thereby accepting or rejecting the request to delete links and / or add links made by the non-access point multilink device on the established multilinks.

[0518] For FT, the link reconfiguration response frame is used by the access point multilink device (including the current access point multilink device and the target access point multilink device) in the mobile domain MLD scenario to respond to the link reconfiguration request frame sent from the non-access point multilink device, to accept or reject the request from the non-access point multilink device to delete links on the existing multilinks of the current access point multilink device, and to add links on the target access point multilink device.

[0519] In one possible design of this embodiment, switching on at least one of the FT-based link reconfiguration request frame and link reconfiguration response frame further includes: The second indication information is used to indicate whether FT is supported or permitted between two access point multilink devices belonging to the same mobile domain MLD.

[0520] For example, the second indication information is called the "FT in the same mobile domain MLD" field. When the value of this field is 1, it indicates that FT is supported or allowed between two access point multilink devices attached to the same mobile domain MLD. When the value of this field is 0, it indicates that FT is not supported or not allowed between two access point multilink devices attached to the same mobile domain MLD.

[0521] Figure 9 The illustration shows a schematic diagram of a mobile domain element format provided in an exemplary embodiment of this application. The mobile domain element format includes at least one of the following: an element ID (Element ID) field, a length field, a mobility domain ID (MDID) field, an FT Capability and Policy field, a mobile domain MLD identifier field, and a mobile domain MLD MAC address field.

[0522] 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 mobile domain MLD identifier field occupies 0 or 1 byte, and the mobile domain MLD MAC address field occupies 0 or 6 bytes.

[0523] Regarding the aforementioned FT capabilities and strategy fields, Figure 10 The illustration shows a schematic diagram of the FT capability and policy field format provided in an exemplary embodiment of this application. The FT capability and policy field includes at least one of the following: FT field via DS, resource request protocol capability field, whether FT is in the same mobile domain MLD (FTinMobileDomainMLD) field, and reserved field.

[0524] Among them, the FT field through DS occupies 1 bit, the resource request protocol capability field occupies 1 bit, the FT whether it is in the same mobile domain MLD field occupies 1 bit, and the reservation field occupies 5 bits.

[0525] The "FT in the same Mobile Domain MLD" field indicates whether FT is supported or permitted between two access point multilink devices belonging to the same Mobile Domain MLD. For example, a value of 1 indicates support or permission for FT between two access point multilink devices belonging to the same Mobile Domain MLD, while a value of 0 indicates no support or permission for FT between two access point multilink devices belonging to the same Mobile Domain MLD. Alternatively, a value of 0 may indicate support or permission for FT between two access point multilink devices belonging to the same Mobile Domain MLD, while a value of 1 may indicate no support or permission for FT between two access point multilink devices belonging to the same Mobile Domain MLD. This embodiment does not limit this approach.

[0526] The "Whether FT is in the same Mobile Domain MLD" field controls the behavior of the STA or non-access point multilink device when performing FT. The non-access point multilink device can use information from the MDE to determine the recommended handover method for the access point multilink device and the protocols supported by the access point multilink device.

[0527] The above-described format of mobile domain elements, FT capabilities, and policy fields is an exemplary possibility. In different embodiments or designs, it is possible that at least one of the following designs may change: the position of mobile domain elements, FT capabilities, and policy fields in the frame, their arrangement order with other fields, the number of bytes occupied, the number of bits occupied, the element name, and the field name. This embodiment does not limit this.

[0528] In one possible design of this embodiment, the transmission module 2810 is further configured to send and / or receive at least one second frame, the second frame being used to synchronize context information related to the non-access point multilink device between two access point multilink devices, the context information including at least one of status information and buffer information.

[0529] In one possible design of this embodiment, the transmission module 2810 is used to send a request frame, which is used to indicate that the non-access point multilink device requests to synchronize context information related to the non-access point multilink device between two access point multilink devices. Receive response frames, which are used to feed back context information related to the synchronization of the non-access point multilink device between the two access point multilink devices.

[0530] In one possible design of this embodiment, the context information includes at least one of the following: First context information, which is information related to the block acknowledgment protocol context; Second context information is information related to the security-associated context.

[0531] In one possible design of this embodiment, the first context information is carried in the block acknowledgment protocol context element.

[0532] In one possible design of this embodiment, the second context information is carried in the security association context element.

[0533] Block confirmation protocol context element: In one possible design of this embodiment, the block acknowledgment protocol context can also be described as a block acknowledgment protocol scenario, which is information about the maintained block acknowledgment process.

[0534] In one possible design of this embodiment, the block acknowledgment protocol context element includes block acknowledgment protocol context or state information specifying that the MLD has established and maintained block acknowledgment protocol contexts or state information with one or more peer MLDs (i.e., non-access point multilink devices). The block acknowledgment protocol context element includes a block acknowledgment protocol context parameter control field, which indicates at least one of the following: • The device where the block confirmation protocol context element resides; • Whether the device containing the Block Acknowledgment Protocol (BAP) context element is the same as the non-access point multilink device to which the BAP context is targeted; • When the device containing the block acknowledgment protocol context element is the same device as the non-access point multilink device to which the block acknowledgment protocol context is targeted, the non-access point multilink device to which the block acknowledgment protocol context is targeted. • The number of block acknowledgment protocol context parameters included in the block acknowledgment protocol context element.

[0535] In one possible design of this embodiment, the device containing the block acknowledgment protocol context element is the current access point multilink device.

[0536] Figure 11This illustration shows a schematic diagram of a block acknowledgment protocol context element format provided in an exemplary embodiment of this 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 embodiments of this application, the domain and field have the same meaning, and the subdomain and field have the same meaning.

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

[0538] Regarding the block acknowledgment protocol context parameter control fields mentioned above, Figure 12 The illustration shows a schematic diagram of the format of a block acknowledgment protocol context parameter control field provided in an exemplary embodiment of this application. The block acknowledgment protocol 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, number of single block acknowledgment protocol context parameter sets field, and reserved field.

[0539] The MLD MAC address field occupies 48 bits, the field indicating whether the peer MLD is the same MLD occupies 1 bit, the peer MLD MAC address field occupies 0 or 48 bits, the field indicating the number of single block acknowledgment protocol context parameters occupies 16 bits, and the reserved field occupies 7 bits.

[0540] The MLD MAC address field indicates the MAC address of the MLD containing the Block Acknowledgment Protocol Context described by the Block Acknowledgment Protocol Context element. The MLD MAC address can be the MLD address of a roaming MLD.

[0541] The "Whether the peer MLD is the same MLD" field indicates whether the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element are the same MLD. A value of 0 indicates that the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation context element are the same MLD; a value of 1 indicates that the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element are multiple MLDs. Alternatively, a value of 1 indicates that the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation context element are the same MLD; a value of 0 indicates that the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element are multiple MLDs. This application embodiment does not limit this.

[0542] The peer MLD MAC address field indicates the MAC address of the peer MLD to which the block acknowledgment protocol context of the MLD described by the block acknowledgment protocol context element is located. When the value of the "Whether the peer MLD is the same MLD" field is 0, the peer MLD MAC address field exists in the block acknowledgment protocol context parameter control field; when the value of the "Whether the peer MLD is the same MLD" field is 1, the peer MLD MAC address field does not exist in the block acknowledgment protocol context parameter control field. Alternatively, when the value of the "Whether the peer MLD is the same MLD" field is 1, the peer MLD MAC address field exists in the block acknowledgment protocol context parameter control field; when the value of the "Whether the peer MLD is the same MLD" field is 0, the peer MLD MAC address field does not exist in the block acknowledgment protocol context parameter control field. This application embodiment does not limit this specific case.

[0543] The Single Block Acknowledgment Protocol Context Parameter Set Count field is a 16-bit unsigned integer indicating the number of single block acknowledgment protocol context parameter set fields in the Block Acknowledgment Protocol Context Parameter Set List field.

[0544] In one possible design of this embodiment, the block confirmation protocol context element includes a block confirmation protocol context parameter set list field, which 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.

[0545] 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: • The role of the device within the block acknowledgment protocol context; • The non-access point multilink device to which the block acknowledgment protocol context applies; • Block confirmation parameter set; • Block confirmation timeout value.

[0546] Regarding the block acknowledgment protocol context parameter set list fields mentioned above, Figure 13 The illustration shows a format diagram of a block confirmation protocol context parameter set list field provided in an exemplary embodiment of this application. The block confirmation protocol context parameter set list field includes at least one of the following: one or more individual block confirmation protocol context parameter set fields, and padding fields.

[0547] The number of bits occupied by the single block confirmation protocol context parameter set field is variable, and the number of bits occupied by the padding field is also variable.

[0548] In one possible design of this embodiment, if the block acknowledgment protocol context parameter set subfield is used to indicate that the device containing the corresponding block acknowledgment protocol context is the initiator in the block acknowledgment protocol context, the block acknowledgment protocol context parameter set subfield is also used to indicate at least one of the following: • Send window start sequence number; • Send window size.

[0549] In one possible design of this embodiment, if the Block Acknowledgment Protocol Context Parameter Set subfield is used to indicate that the device containing the Block Acknowledgment Protocol Context plays the role of a receiver in the Block Acknowledgment Protocol Context; the Block Acknowledgment Protocol Context Parameter Set subfield is also used to indicate at least one of the following: • Start sequence number of the receive buffer; • Receive window size; • Record the starting sequence number of the bitmap; • Record the maximum sequence number of the bitmap; Record bitmap size.

[0550] Regarding the single block acknowledgment protocol context parameter set fields mentioned above, if the MLD containing the block acknowledgment protocol context is the initiator MLD role, Figure 14 The illustration shows a format diagram of a single block acknowledgment protocol context parameter set field provided in an exemplary embodiment of this application. The single block acknowledgment protocol context parameter set field includes at least one of the following: MLD role field (initiator MLD), peer MLD field, block acknowledgment parameter set field, block acknowledgment timeout field, send window start sequence number field (WinStart0), and send window size field (WinSize0).

[0551] The MLD role field (initiator MLD) occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the block acknowledgment parameter set field occupies 16 bits, the block acknowledgment timeout value field occupies 8 bits, the send window start sequence number field occupies 12 bits, and the send window size field occupies 10 bits.

[0552] When the MLD in the block confirmation protocol context is the receiver MLD role. Figure 15 The illustration shows a format diagram of a single block acknowledgment protocol context parameter set field provided in an exemplary embodiment of this application. The single block acknowledgment protocol context parameter set field includes at least one of the following: MLD role field (receiver MLD), peer MLD field, block acknowledgment parameter set field, block acknowledgment 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.

[0553] The MLD role field (receiver MLD) occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the block acknowledgment parameter set field occupies 48 bits, the block acknowledgment timeout value field occupies 16 bits, the receive buffer start sequence number field occupies 12 bits, the receive window size field occupies 10 bits, the record bitmap start 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.

[0554] The MLD Role field indicates the role of the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set in the block acknowledgment protocol. For example, a value of 0 indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set acts as the initiator MLD in the block acknowledgment protocol; a value of 1 indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set acts as the receiver MLD in the block acknowledgment protocol. Alternatively, a value of 1 indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set acts as the initiator MLD in the block acknowledgment protocol; a value of 0 indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set acts as the receiver MLD in the block acknowledgment protocol.

[0555] When the MLD containing the block acknowledgment protocol context is the initiator role, the format of a single block acknowledgment protocol context parameter set is as follows: Figure 14 As shown, when the MLD containing the block acknowledgment protocol context is in the receiver role, the format of a single block acknowledgment protocol context parameter set is as follows: Figure 15 As shown.

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

[0557] The Block Acknowledgment Parameter Set field indicates the set of parameters associated with the established block acknowledgment protocol corresponding to the block acknowledgment protocol context described by the Block Acknowledgment Protocol Context Parameter Set field.

[0558] The Block Acknowledgment Timeout field contains the duration in TU (1024 microseconds). If no frame exchange sequence occurs within this duration using the Block Acknowledgment protocol, the Block Acknowledgment protocol will terminate after this duration. Setting this field to 0 indicates a disabled timeout.

[0559] The Send Window Start Sequence Number field is a send buffer control parameter used to indicate the start sequence number of the send window.

[0560] In one possible design of this embodiment, the block confirmation parameter set includes at least one of the following: • Indicator information indicating whether aggregated MSDUs are supported; • Block confirmation strategy; • Flow identifier; • Buffer size.

[0561] Regarding the aforementioned block confirmation parameter set fields, Figure 16 The diagram illustrates the format of a block acknowledgment parameter set field provided in an exemplary embodiment of this application. The block acknowledgment parameter set field includes at least one of the following: an A-MSDU support field, a block acknowledgment policy field, a flow identifier (TID) field, and a buffer size field.

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

[0563] The transmit window size field is a transmit buffer control parameter that indicates the buffer size of the transmit window negotiated in the block acknowledgment protocol. Specifically, the transmit window size field indicates the number of buffers available for a given TID. When the A-MSDU support field is equal to 0, the number of bytes each buffer can hold is equal to the maximum size of the MSDU. When the STA-supported A-MSDU field is equal to 1, the number of bytes each buffer can hold is equal to the maximum size of the A-MSDU supported by the STA.

[0564] The Receive Buffer Start Sequence Number field is a control parameter for the Receive Reordering Buffer, representing the value of the sequence number field of the first MSDU or A-MSDU (arranged in ascending order of sequence number) that has not yet been received.

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

[0566] The Record Bitmap Start Sequence Number field is a Scoreboard Context Control parameter. It is a 12-bit unsigned integer start sequence number that represents the lowest sequence number position in the block confirmation record bitmap (indexed by sequence number).

[0567] The record bitmap maximum sequence number field indicates the highest sequence number in the current transmission window.

[0568] The record bitmap size field is a scoreboard context control parameter used to indicate the maximum transmission window size, set to the smaller of the bitmap length and the buffer size field of the relevant response frame of the build block return protocol.

[0569] The above-described block acknowledgment protocol context element format, block acknowledgment protocol context parameter control field format, block acknowledgment protocol context parameter set list field format, single block acknowledgment protocol context parameter set field format, and block acknowledgment parameter set field format are exemplary possibilities. In different embodiments or different designs, it is not excluded that at least one of the following designs may change: the position of the above fields in the frame, the order of arrangement with other fields, the number of bytes occupied, the number of bits occupied, the element name, and the field name. This embodiment does not limit this.

[0570] Security-related context elements: In one possible design of this embodiment, the security association context can also be described as a security association scenario, which is information about the security association process being maintained.

[0571] In one possible design of this embodiment, the security association context element includes a sender PN configuration and PN counter status information that the specified MLD has established and maintained with one or more peer MLDs for security association-related data encryption / decryption and / or integrity protection and verification, and / or receiver replay detection context and replay counter status information. Figure 17 The illustration shows a schematic diagram of a security association context element format provided in an exemplary embodiment of this 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 parameter control field, and a security association context parameter set list field.

[0572] 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.

[0573] In one possible design of this embodiment, the security association context element includes a security association context parameter control field, which is used to indicate at least one of the following: • The device where the security association context element resides; • Whether the device containing the security association context element and the non-access point multilink device to which the security association context is targeted are the same device; • When the device containing the security association context element and the non-access point multilink device to which the security association context is targeted are the same device, the non-access point multilink device to which the security association context is targeted. • The number of security association context parameter sets included in the security association context element.

[0574] In one possible design of this embodiment, the device containing the security association context element is the current access point multilink device.

[0575] Regarding the aforementioned security association context parameter control fields, Figure 18The illustration shows a schematic diagram of the format of a security association context parameter control field provided in an exemplary embodiment of this 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, number of security association scenario parameter sets field, and reserved field.

[0576] The MLD MAC address field occupies 48 bits, the field indicating whether the peer MLD is the same MLD occupies 1 bit, the peer MLD MAC address field occupies 0 or 48 bits, the field indicating the number of security association scenario parameter sets occupies 16 bits, and the reserved field occupies 7 bits.

[0577] In one possible design of this embodiment, the security association context element includes a security association context parameter set list field, which 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.

[0578] In one possible design of this embodiment, the security association context parameter set subfield is used to indicate at least one of the following: • The role of the device within the security association context; • The non-access point multilink device to which the security association context applies; • Security association type of security association context.

[0579] Regarding the fields in the aforementioned security association context parameter set list, Figure 19 The illustration shows a format diagram of a security association context parameter set list field provided in an exemplary embodiment of this 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.

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

[0581] In one possible design of this embodiment, if the security association context parameter set subfield is used to indicate that the device containing the security association context plays the role of an initiator in the security association context; the security association context parameter set subfield is also used to indicate at least one of the following: • Number of replay counters; ·TID; • Counting of the replay counter for TID.

[0582] In one possible design of this embodiment, if the security association context parameter set subfield is used to indicate that the device containing the security association context plays the role of a receiver in the security association context; the security association context parameter set subfield is also used to indicate at least one of the following: • Package number counter count; ·TID; • Counting for the package number counter for TID.

[0583] Regarding the aforementioned security association context parameter set fields, if the MLD containing the security association context described by the security association context parameter set fields is the receiver MLD role, Figure 20 The illustration shows a schematic diagram of the format of a security association context parameter set field provided in an exemplary embodiment of this application. The security association context parameter set field includes at least one of the following: MLD role field, peer MLD field, PTKSA / GTKSA / TPKSA field, number of replay counters field, one or more TID fields, and one or more replay counter count fields.

[0584] 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 replay counter count field occupies 5 bits, the TID field occupies 8 bits, and the replay counter count field occupies 48 bits.

[0585] When the MLD containing the security association context described in the security association context parameter set field is the sender's MLD role. Figure 21 The illustration shows a schematic diagram of the format of a security association context parameter set field provided in an exemplary embodiment of this application. The security association context parameter set field includes at least one of the following: MLD role field, PeerMLD field, PTKSA / GTKSA / TPKSA field, PN counter number field, one or more TID fields, and one or more PN counter count fields.

[0586] 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 count field occupies 5 bits, the TID field occupies 8 bits, the intermediate PN counter count field occupies 0 or 48 bits, and the final PN counter count field occupies 48 bits.

[0587] The MLD Role field indicates the role of the MLD containing the security association context described by the Security Association Context Parameter Set field within that security association context. For example, a value of 0 in the MLD Role field indicates that the MLD containing the security association context described by the Security Association Context Parameter Set field acts as a receiver MLD, meaning it describes the receiver's replay context parameter set; a value of 1 in the MLD Role field indicates that the MLD containing the security association context described by the Security Association Context Parameter Set field acts as a sender MLD, meaning it describes the sender's PN counter context parameter set. Alternatively, a value of 1 in the MLD Role field indicates that the MLD containing the security association context described by the Security Association Context Parameter Set field acts as a receiver MLD; a value of 0 in the MLD Role field indicates that the MLD containing the security association context described by the Security Association Context Parameter Set field acts as a sender MLD.

[0588] The PTKSA / GTKSA / TPKSA fields indicate the security association type corresponding to the replay context described by the replay context parameter set fields, as shown in Table 4.

[0589] The above-mentioned security association 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 cases. In different embodiments or different designs, it is not excluded that at least one of the following designs may change: the position of the above fields in the frame, the order of arrangement with other fields, the number of bytes occupied, the number of bits occupied, the element name, and the field name. This embodiment does not limit this.

[0590] In one possible design of this embodiment, the second frame further includes: third indication information, which is used to indicate that the context information includes information on the block acknowledgment protocol context and / or security association context.

[0591] In one possible design of this embodiment, the two access point multilink devices belong to the same mobile domain (MLD), and at least one of the request frame and response frame further includes: The first indication information is used to indicate the mobile domain (MLD).

[0592] In one possible design of this embodiment, switching based on FT, at least one of the request frame and the response frame, further includes: The second indication information is used to indicate whether FT (Flexible Transmission) is supported or permitted between two access point multilink devices attached to the same mobile domain (MLD). For example, the second indication information is called the "FT in the same mobile domain (MLD)" field. When the value of this field is 1, it indicates that FT is supported or permitted between two access point multilink devices attached to the same mobile domain (MLD). When the value of this field is 0, it indicates that FT is not supported or permitted between two access point multilink devices attached to the same mobile domain (MLD).

[0593] 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: 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. 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.

[0594] In one possible design of this embodiment, the handover is based on FT, the request frame is an FT acknowledgment frame, and the response frame is an FT response frame.

[0595] A non-access point multilink device sends an FT acknowledgment frame to a target access point multilink device via the current access point multilink device. Then, the target access point multilink device sends an FT response frame to the non-access point multilink device via the current access point multilink device. The FT acknowledgment frame includes at least one of the following: non-access point multilink device information, target access point multilink device information, MDE, block acknowledgment protocol context element, security association context element, and basic multilink element. The FT response frame includes at least one of the following: non-access point multilink device information, target access point multilink device information, MDE, timeout interval element, block acknowledgment protocol context element, security association context element, and basic multilink element.

[0596] The FT acknowledgment frame and the FT response frame carry block acknowledgment protocol context elements and security association context elements, indicating the relevant block acknowledgment protocol context (or status) information and security association context (or status) information.

[0597] In one possible design of this embodiment, the two access point multilink devices belong to the same mobile domain (MLD), and the transmission module 2810 is also used to send FT request frames. Receive FT response frames.

[0598] When a non-access point multilink device determines that it needs to switch from the current access point multilink device to the target access point multilink device in a mobile domain MLD scenario, the non-access point multilink device sends an FT request frame to the target access point multilink device through the current access point multilink device. Then, the target access point multilink device sends an FT response frame to the non-access point multilink device through the current access point multilink device. The FT request frame includes at least one of the following: non-access point multilink device information, target access point multilink device information, MDE, and basic multilink elements. The FT response frame includes at least one of the following: non-access point multilink device information, target access point multilink device information, MDE, and basic multilink elements.

[0599] The FT request frame and FT response frame carry the MDE (FTinMobileDomainMLD field, Mobile Domain MLD information field), indicating that FT is supported or permitted between two access point multilink devices belonging to the same Mobile Domain MLD.

[0600] In one possible design of this embodiment, the transmission module 2810 is also used to send an association request frame; Receive associated response frames.

[0601] 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 sends an association response frame or a reassociation response frame back to the non-access point multi-link device.

[0602] The non-access point multilink device sends an association request frame or reassociation request frame to the current access point multilink device, including: mobile domain element (MDE) and basic multilink element; The current access point multilink device sends an association response frame or reassociation response frame to the non-access point multilink device, including: mobile domain element (MDE) and basic multilink element.

[0603] The association request frame or reassociation request frame carries the MDE (FTinMobileDomainMLD field, Mobile Domain MLD information field), which instructs the non-access point multilink device to associate with the access point multilink device in the Mobile Domain MLD scenario (or the non-access point multilink device to associate with the access point multilink device attached to the Mobile Domain MLD), and indicates that FT is supported or allowed between two access point multilink devices attached to the same Mobile Domain MLD.

[0604] In one possible design of this embodiment, the handover is based on FT, and link reconfiguration is performed if the first duration is less than or equal to the link reconfiguration deadline. The first duration refers to the duration between the transmission time of the FT request frame and the transmission time of the link reconfiguration request frame, and the first frame includes the link reconfiguration request frame.

[0605] In one possible design of this embodiment, the transmission module 2810 is further configured to send fourth indication information, which is used to indicate the deadline or timeout for link reconfiguration.

[0606] For example, the fourth indication information is called the Timeout Interval Element (TIE), which is used to specify the time interval and the timeout period.

[0607] In one possible design of this embodiment, the fourth indication information is indicated by a start time and a timeout interval, or... The fourth instruction uses a deadline as the indication.

[0608] In one possible design of this embodiment, the start time is implicitly represented by the sending or receiving time of the fourth indication information; The timeout interval is explicitly indicated by the fourth indication information.

[0609] In this embodiment of the 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, which is used to indicate that the timeout interval value field represents the link reconfiguration deadline time interval. Figure 22 The illustration shows a schematic diagram of a timeout interval element format provided in an exemplary embodiment of this 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.

[0610] 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.

[0611] The above-described timeout interval element format is an exemplary possibility. In different embodiments or designs, it is possible that at least one of the following designs may change: the position of the timeout interval element in the frame, its arrangement order with other fields, the number of bytes occupied, or the element name. This embodiment does not limit this.

[0612] 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 definitions of the timeout interval type field are shown in Table 5.

[0613] 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 function of different transmission modules.

[0614] This embodiment uses one transmission module 2810 as an example, and the number of transmission modules 2810 is not limited.

[0615] For a functional description of the transmission module 2810, please refer to [link / reference]. Figure 5 The content of step 510 in the embodiment.

[0616] Figure 29 A block diagram of a current access point multilink device provided in an exemplary embodiment of this application is shown. The device can be implemented as a current access point multilink device or as part of a current access point multilink device by 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 multilink device, and the function of the processing module 2920 is implemented by a processor in the current access point multilink device.

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

[0618] In one possible design of this embodiment, the current access point multi-link device and the target access point multi-link device belong to the same mobile domain (MLD), or the current access point multi-link device and the target access point multi-link device belong to the same mobile domain.

[0619] A Mobile Domain MLD, also known as a Logical Access Point Multiple Link Device, is a device that treats multiple access point multiple links that are not located in the same location as a single MLD. In this embodiment, the specific name of the Mobile Domain MLD is not limited.

[0620] In one 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: Scenario 1: When a non-access point multi-link device is associated with a mobile domain MLD, and the current access point multi-link device and the target access point multi-link device belong to the same mobile domain MLD, the non-access point multi-link device performs a handover of the access point multi-link device-level association of the mobile domain MLD between the current access point multi-link device and the target access point multi-link device. Scenario 2: When a 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 attached to the same mobile 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.

[0621] The term "transition" in this application embodiment can also be replaced with "conversion".

[0622] For handover scenario one, handover at the level of access point multi-link device association attached to a mobile domain MLD refers to a situation where, before the handover, a non-access point multi-link device is associated with the mobile domain MLD, and the non-access point multi-link device establishes multiple links with one access point multi-link device attached to the mobile domain MLD (i.e., all or part of the links established between the non-access point multi-link device and the mobile domain MLD are links between the non-access point multi-link device and one access point multi-link device attached to the mobile domain MLD). After the handover, the non-access point multi-link device remains associated with the mobile domain MLD, and the non-access point multi-link device establishes multiple links with another access point multi-link device attached to the mobile domain MLD (i.e., all or part of the links established between the non-access point multi-link device and the mobile domain MLD are links between the non-access point multi-link device and another access point multi-link device attached to the mobile domain MLD).

[0623] For the second handover scenario, the non-access point multilink device associates with access point multilink devices attached to different mobile domain MLDs before and after the handover, thereby performing the associated handover.

[0624] For the current access point multilink device and the target access point multilink device, the mobile domain MLD attached to the current access point multilink device includes multiple access point multilink devices, including the current access point multilink device.

[0625] For the current access point multilink device and the target access point multilink device, the mobile domain MLD attached to the target access point multilink device includes multiple access point multilink devices, including the target access point multilink device.

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

[0627] In one possible design of this embodiment, the current access point multi-link device and the target access point multi-link device belong to the same mobile domain MLD, and the mobile domain MLD is used for at least one of the following: • Provides connection services between non-access point multilink devices or the current access point multilink device and the target access point multilink device and the DS; • Maintain data continuity for non-access point multi-link devices during roaming when switching between the current access point multi-link device and the target access point multi-link device; • Authentication and / or association or reassociation of non-access point multi-link devices; • Security association of non-access point multi-link devices; • Distribution of all or part of the security association information of non-access point multi-link devices; • Synchronize all or part of the status and / or buffer information of the upper layer MAC of the current access point multilink device and the target access point multilink device; • Manage the distribution of authentication information for non-access point multi-link devices; • Manage the association or re-association at the access point multilink device level between non-access point multilink devices and the current access point multilink device and the target access point multilink device; • For the current access point multilink device and the target access point multilink device that establishes multilinks with non-access point multilink devices, select the MAC address corresponding to the target access point multilink device for data transmission. • The first data is synchronized between the current access point multilink device and the target access point multilink device. The first data is used to maintain data communication between the non-access point multilink device and the current access point multilink device and the target access point multilink device or DS. • Exchange or indicate MLD-level information through the MAC sublayer of the current access point multilink device and the target access point multilink device.

[0628] In one possible design of this embodiment, the transmission module 2910 is used to send a link reconfiguration request frame. The link reconfiguration request frame is used to instruct the non-access point multi-link device to request link reconfiguration with the current access point multi-link device and the target access point multi-link device to achieve handover. Receive link reconfiguration response frames. These frames are used to provide feedback to non-access point multi-link devices on the link reconfiguration performed with the current access point multi-link device and the target access point multi-link device.

[0629] In one 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 then sent by the current access point multi-link device to the target access point multi-link device.

[0630] In one 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 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.

[0631] When a non-access point multi-link device needs to switch from communicating with the current access point multi-link device to communicating with the 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. The link reconfiguration request frame is used to request the deletion of at least one link between the non-access point multi-link device and the current access point multi-link device. The current access point multi-link device sends a link reconfiguration request frame to the target access point multi-link device. The link reconfiguration request frame is used to request the establishment of at least one link between the non-access point multi-link device and the target access point multi-link device.

[0632] 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 has been 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 has deleted a link, and whether the target access point multi-link device has established a link with the non-access point multi-link device.

[0633] In one 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 includes: The first element corresponding to the current access point multi-link device is used to delete at least one link between the current access point multi-link device; The second element corresponding to the target access point multilink device is used to establish at least one link with the target access point multilink device.

[0634] In one possible design of this embodiment, the first element includes a first reconfiguration multilink element, used to describe the reconfiguration multilink information between the non-access point multilink device and the current access point multilink device; The second element includes a second reconfiguration multilink element, which describes the reconfiguration multilink information between the non-access point multilink device and the target access point multilink device.

[0635] In one possible design of this embodiment, the link reconfiguration request frame further includes: The first flow identifier to link mapping element is used to request the mapping of flow identifiers to links on the links established between the target access point and the multi-link device.

[0636] In one possible design of this embodiment, the format of the link reconfiguration request frame is as follows: Figure 4 Table 1 in the embodiments is shown.

[0637] 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, and the link reconfiguration response frame includes: The third element corresponding to the current access point multi-link device is used to indicate the link reconfiguration status corresponding to the current access point multi-link device; The fourth element corresponding to the target access point multi-link device is used to indicate the link reconfiguration status corresponding to the target access point multi-link device.

[0638] 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; the number of reconfiguration state tuples of the current access point multi-link device; 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 tuple; the number of reconfiguration state tuples of the target access point multi-link device; The reconfiguration status tuple is used to indicate the reconfiguration status of a link.

[0639] In one possible design of this embodiment, the link reconfiguration response frame can be a protected EHT or UHR, UHR+ type action frame. The format of the link reconfiguration response frame is as follows: Figure 4 Table 2 in the embodiments is shown.

[0640] In one possible design of this embodiment, the current access point multi-link device and the target access point multi-link device belong to the same mobile domain (MLD), or the current access point multi-link device and the target access point multi-link device belong to the same mobile domain. The transmission module 2910 is used to send and / or receive first indication information, which is used to indicate the mobile domain (MLD).

[0641] In one possible design of this embodiment, 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; • FT request frame; •FT response frame; •FT confirmation frame; •FT response frame; • Associated request frame; • Associated response frame; • Reassociation request frame; • Reassociate response frames; The request frame is used to instruct the non-access point multi-link device to request the copying or migration of context information between the current access point multi-link device and the target access point multi-link device in order to maintain data connectivity during the handover process. The response frame is used to instruct the non-access point multi-link device on the result of the copying or migration of context information between the current access point multi-link device and the target access point multi-link device.

[0642] In one possible design of this embodiment, the first indication information includes at least one of the following: • Mobile Domain MLD Identifier; • Mobile Domain (MLD) MAC address.

[0643] For example, the first indication information is called a Mobile Domain Element (MDE), which is used to indicate link reconfiguration in a Mobile Domain Multi-Link (MLD) scenario. It carries MLD information (such as the MLD identifier or MAC address) and whether the FT (Flexible Transfer) is within the same MLD. Access Point Multi-Link (APML) devices can use the MDE to announce that they are included in or attached to a MLD, to announce their support for FT functionality, and to provide FT policy information, including whether FT is supported or permitted between the current APML and the target APML attached to the same MLD.

[0644] In one possible design of this embodiment, the handover is based on FT. The transmission module 2910 is used to send and / or receive second indication information, which indicates whether FT is supported or allowed between the current access point multilink device and the target access point multilink device attached to the same mobile domain MLD.

[0645] FT is performed between the current access point multilink device and the target access point multilink device that belong to the same mobile domain MLD, compared with FT between the current access point multilink device and the target access point multilink device, to maintain data connectivity during the handover process.

[0646] In one possible design of this embodiment, 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; • Associated request frame; • Associated response frame; • Reassociation request frame; • Reassociate response frames; The request frame is used to instruct the non-access point multi-link device to request the copying or migration of context information between the current access point multi-link device and the target access point multi-link device in order to maintain data connectivity during the handover process. The response frame is used to instruct the non-access point multi-link device on the result of the copying or migration of context information between the current access point multi-link device and the target access point multi-link device.

[0647] In one possible design of this embodiment, based on the Mobile Domain MLD architecture, the high-level architecture of the Mobile Domain MLD and its associated access point multi-link devices and non-access point multi-link devices, where a non-access point multi-link device (or STA) switches from the current access point multi-link device (or AP) to the target access point multi-link device (or AP), is as follows: Figure 6 As shown.

[0648] The high-level architecture includes at least one of the following: DS610, Mobile Domain MLD General Sublayer 620, First Handover Module 630, Auxiliary MLD Upper Layer MAC Sublayer 640, Auxiliary MLD Lower Layer MAC Sublayer 650, Second Handover Module 660, Non-Access Point Multilink Device Lower Layer MAC Sublayer 670, and Non-Access Point Multilink Device Upper Layer MAC Sublayer 680.

[0649] The DS610 is an architecture designed to distribute computing and communication functions across multiple nodes or devices. The primary function of DS is to coordinate and manage computing and communication tasks in a distributed environment to achieve efficient data transfer and collaboration.

[0650] The Mobile Domain MLD General Sublayer 620 includes a Mobile Domain Access Point Multiple Link Device 621, whose MLD MAC address is Q, and which communicates with the DS610 via a first MAC-Service Access Point (SAP).

[0651] Access point multi-link device 1 with MLD MAC address M and access point multi-link device 2 with MLD MAC address N have the same function. The following explanation uses access point multi-link device 1 as an example. Mobile domain access point multi-link device 621 communicates with access point multi-link device 1 via a first handover module 630. The first handover module 630 can be a module in mobile domain access point multi-link device 621, a module in access point multi-link device 1, or a module in another access point multi-link device.

[0652] Access point multi-link device 1 communicates with AP1 (MAC address w) and AP2 (MAC address x) via a second MAC-SAP. AP1 and AP2 have the same function; AP1 will be used as an example for explanation. AP1 communicates with the second switching module 660 via link 1. The second switching module 660 can be a module in non-access point multi-link device 681, a module in access point multi-link device 1, or a module in other access point multi-link devices.

[0653] Non-AP STA1 with MAC address y and non-AP STA2 with MAC address z have the same function. 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. The following explanation uses non-AP STA1 as an example. The MLD non-access point multi-link device with MAC address P communicates with non-AP STA1 via the fourth MAC-SAP.

[0654] The functionality of the Mobile Domain MLD General Sublayer 620 includes at least one of the following: (1) Provide a distributed system access function (DSAF) to the auxiliary access point multilink devices (e.g., access point multilink device 1 and access point multilink device 2) of the mobile domain MLD. (2) Authentication, association, and reassociation functions between the non-access point multi-link device 681 and the mobile domain access point multi-link device 621; (3) Security associations, such as Pairwise Master Key Security Association (PMKSA) and Pairwise Transient Key Security Association (PTKSA), and manage the distribution of GTK / IGTK / BIGTK; (4) Manage the partial association and reassociation functions between the non-access point multilink device 681 and the auxiliary access point multilink device of the mobile domain access point multilink device; (5) For the auxiliary access point multilink device associated with the non-access point multilink device 681, select the MAC of the corresponding auxiliary access point multilink device for data transmission. (6) Synchronization (copying or migration) of all or part of the state and buffer information of the upper layer MAC of the subordinate MLD of the mobile domain MLD. (7) Exchange / instructions for MLD-level management information through the MAC sub-layer of the attached MLD.

[0655] This includes the synchronization of all or part of the state and buffer information of the higher-level MAC layer of the mobile domain MLD's upper-layer MLD, including: For a designated non-access point multilink device associated with a mobile domain MLD, the non-access point multilink device switches from the currently associated access point multilink device to the target access point multilink device to be associated. This involves synchronizing all or part of the higher-level state and buffer information of the upper-layer MAC of the affiliated MLD to maintain the continuity of data communication sessions and data transmission during the process of the non-access point multilink device associating with different affiliated access point multilink devices due to roaming.

[0656] All or part of the higher-layer state and buffer information of the upper-layer MAC of the mobile domain MLD, i.e., the session or protocol state and buffer information maintained during data exchange with the designated non-access point multilink device (for the designated non-access point multilink device), includes at least one of the following: (1) The allocation status of sequence number (SN) / packet number (PN) of unicast frames and related buffer data; (2) SN allocation status and related buffer data of the group-addressed MAC Service Data Unit (MSDU); (3) Energy-saving buffer data for individually addressed frames; (4) Block Ack session status and duplicate detection and reordering buffer data of received frames; (5) The PN counter status of the transmitting end and the replay detection status and related buffer data of the receiving end.

[0657] In one possible design of this embodiment, the link reconfiguration response frame includes a status code indicating the status of link reconfiguration in a mobile domain (MLD) scenario. If the status code takes a first value, it indicates that mobile domain link reconfiguration is rejected.

[0658] The format of the link reconfiguration response frame is as follows: Figure 4 Table 2 in the embodiments is shown.

[0659] In one possible design of this embodiment, both the reconfiguration state list subfield of the current access point multi-link device and the reconfiguration state list subfield of the target access point multi-link device adopt the reconfiguration state list format. The reconfiguration state list contains one or more reconfiguration state tuples, such as... Figure 7 As shown. Figure 7 This illustration shows a schematic diagram of a reconfiguration status list subdomain format provided in an exemplary embodiment of this application. The reconfiguration status list subdomain format includes at least one of the following: a Link ID Info field and a Status field. In this embodiment, the fields and subdomains have the same meaning.

[0660] The link ID field occupies 1 byte, and the status field occupies 2 bytes. The format of the link ID field is defined according to IEEE 802.11be. The link ID field represents the link identifier corresponding to the access point multi-link device, used in the corresponding link reconfiguration request frame to delete an existing link or add a new link. The status field indicates the status of the link reconfiguration operation corresponding to the link ID field.

[0661] The above-described reconfiguration status list subfield format is an exemplary possibility. In different embodiments or designs, it is possible that at least one of the following designs may change: the position of the reconfiguration status list subfield field in the frame, its arrangement order with other fields, the number of bytes occupied, or the field name. This embodiment does not limit this.

[0662] In one possible design of this embodiment, the link reconfiguration response frame includes: group key data, used to indicate the group key successfully added to the link corresponding to the target access point multi-link device. The group key data subfield may optionally appear and contain the group key (status code value equal to SUCCESS) successfully added to the link corresponding to the target access point multi-link device. Figure 8 A schematic diagram of a group key data subfield format provided in an exemplary embodiment of this application is shown. The group key data subfield format includes at least one of the following: a key data length field and a key data field.

[0663] The key data length field occupies 2 bytes, and the number of bytes occupied by the key data field is variable.

[0664] The group key data subfield contains an MLO GTK KDE, an MLO IGTK KDE, and an MLO BIGTKKDE, providing a group key identified by the link ID subfield for the links added to the target access point multilink device.

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

[0666] The above-described group key data subfield format is an exemplary possibility. In different embodiments or designs, it is possible that at least one of the following designs may change: the position of the group key data subfield field in the frame, its arrangement order with other fields, the number of bytes occupied, or the field name. This embodiment does not limit this.

[0667] In one possible design of this embodiment, the link reconfiguration response frame includes: a basic multilink element for providing STA-granular configuration files for one or more affiliated APs of the target access point multilink device.

[0668] When at least one link is added to the target access point multilink device, the link reconfiguration response frame includes a basic multilink element for providing STA profiles for one or more affiliated APs of the target access point multilink device, each AP corresponding to a link successfully added to the multilink reconfiguration of the non-access point multilink device. When no link is added to the target access point multilink device, the link reconfiguration response frame does not include the basic multilink element.

[0669] In one possible design of this embodiment, the link reconfiguration response frame includes a second flow identifier to link mapping element, used to respond to a request to perform flow identifier to link mapping on the link established with the target access point multilink device.

[0670] In one possible design of this embodiment, the link reconfiguration response frame is used by the access point multilink device (including the current access point multilink device and the target access point multilink device) in the mobile domain MLD scenario to respond to the link reconfiguration request frame sent from the non-access point multilink device, thereby accepting or rejecting the request to delete links and / or add links made by the non-access point multilink device on the established multilinks.

[0671] For FT, the link reconfiguration response frame is used by the access point multilink device (including the current access point multilink device and the target access point multilink device) in the mobile domain MLD scenario to respond to the link reconfiguration request frame sent from the non-access point multilink device, to accept or reject the request from the non-access point multilink device to delete links on the existing multilinks of the current access point multilink device, and to add links on the target access point multilink device.

[0672] In one possible design of this embodiment, switching on at least one of the FT-based link reconfiguration request frame and link reconfiguration response frame further includes: The second indication information is used to indicate whether FT is supported or permitted between the current access point multilink device and the target access point multilink device that are attached to the same mobile domain MLD.

[0673] For example, the second indication information is called the "FT in the same mobile domain MLD" field. When the value of this field is 1, it indicates that FT is supported or allowed between the current access point multilink device and the target access point multilink device that are attached to the same mobile domain MLD. When the value of this field is 0, it indicates that FT is not supported or allowed between the current access point multilink device and the target access point multilink device that are attached to the same mobile domain MLD.

[0674] Figure 9 The illustration shows a schematic diagram of a mobile domain element format provided in an exemplary embodiment of this application. The mobile domain element format includes at least one of the following: an element ID (Element ID) field, a length field, a mobility domain ID (MDID) field, an FT Capability and Policy field, a mobile domain MLD identifier field, and a mobile domain MLD MAC address field.

[0675] 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 mobile domain MLD identifier field occupies 0 or 1 byte, and the mobile domain MLD MAC address field occupies 0 or 6 bytes.

[0676] Regarding the aforementioned FT capabilities and strategy fields, Figure 10 The illustration shows a schematic diagram of the FT capability and policy field format provided in an exemplary embodiment of this application. The FT capability and policy field includes at least one of the following: FT field via DS, resource request protocol capability field, whether FT is in the same mobile domain MLD (FTinMobileDomainMLD) field, and reserved field.

[0677] Among them, the FT field through DS occupies 1 bit, the resource request protocol capability field occupies 1 bit, the FT whether it is in the same mobile domain MLD field occupies 1 bit, and the reservation field occupies 5 bits.

[0678] The "FT in the same Mobile Domain MLD" field indicates whether FT is supported or permitted between a current access point multi-link device (MAP) and a target MAP attached to the same MAP. For example, a value of 1 indicates support or permission for FT between MAP and target MAP attached to the same MAP, while a value of 0 indicates no support or permission for FT between MAP and target MAP attached to the same MAP. Alternatively, a value of 0 may indicate support or permission for FT between MAP and target MAP attached to the same MAP, while a value of 1 may indicate no support or permission for FT between MAP and target MAP attached to the same MAP. This embodiment does not limit this approach.

[0679] The "Whether FT is in the same Mobile Domain MLD" field controls the behavior of the STA or non-access point multilink device when performing FT. The non-access point multilink device can use information from the MDE to determine the recommended handover method for the access point multilink device and the protocols supported by the access point multilink device.

[0680] The above-described format of mobile domain elements, FT capabilities, and policy fields is an exemplary possibility. In different embodiments or designs, it is possible that at least one of the following designs may change: the position of mobile domain elements, FT capabilities, and policy fields in the frame, their arrangement order with other fields, the number of bytes occupied, the number of bits occupied, the element name, and the field name. This embodiment does not limit this.

[0681] In one possible design of this embodiment, the transmission module 2910 is used to send and / or receive at least one second frame, the second frame being used to synchronize context information related to the non-access point multilink device between the current access point multilink device and the target access point multilink device, the context information including at least one of status information and buffer information.

[0682] In one possible design of this embodiment, the transmission module 2910 is used to send a request frame, which is used to indicate that the non-access point multi-link device requests 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. Receive response frames, which are used to feed back context information related to the non-access point multilink device to the non-access point multilink device for synchronization between the current access point multilink device and the target access point multilink device.

[0683] In one possible design of this embodiment, the context information includes at least one of the following: First context information, which is information related to the block acknowledgment protocol context; Second context information is information related to the security-associated context.

[0684] In one possible design of this embodiment, the first context information is carried in the block acknowledgment protocol context element.

[0685] In one possible design of this embodiment, the second context information is carried in the security association context element.

[0686] Block confirmation protocol context element: In one possible design of this embodiment, the block acknowledgment protocol context can also be described as a block acknowledgment protocol scenario, which is information about the maintained block acknowledgment process.

[0687] In one possible design of this embodiment, the block acknowledgment protocol context element includes block acknowledgment protocol context or state information specifying that the MLD has established and maintained block acknowledgment protocol contexts or state information with one or more peer MLDs (i.e., non-access point multilink devices). The block acknowledgment protocol context element includes a block acknowledgment protocol context parameter control field, which indicates at least one of the following: • The device where the block confirmation protocol context element resides; • Whether the device containing the Block Acknowledgment Protocol (BAP) context element is the same as the non-access point multilink device to which the BAP context is targeted; • When the device containing the block acknowledgment protocol context element is the same device as the non-access point multilink device to which the block acknowledgment protocol context is targeted, the non-access point multilink device to which the block acknowledgment protocol context is targeted. • The number of block acknowledgment protocol context parameters included in the block acknowledgment protocol context element.

[0688] In one possible design of this embodiment, the device containing the block acknowledgment protocol context element is the current access point multilink device.

[0689] Figure 11 This illustration shows a schematic diagram of a block acknowledgment protocol context element format provided in an exemplary embodiment of this 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 embodiments of this application, the domain and field have the same meaning, and the subdomain and field have the same meaning.

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

[0691] Regarding the block acknowledgment protocol context parameter control fields mentioned above, Figure 12 The illustration shows a schematic diagram of the format of a block acknowledgment protocol context parameter control field provided in an exemplary embodiment of this application. The block acknowledgment protocol 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, number of single block acknowledgment protocol context parameter sets field, and reserved field.

[0692] The MLD MAC address field occupies 48 bits, the field indicating whether the peer MLD is the same MLD occupies 1 bit, the peer MLD MAC address field occupies 0 or 48 bits, the field indicating the number of single block acknowledgment protocol context parameters occupies 16 bits, and the reserved field occupies 7 bits.

[0693] The MLD MAC address field indicates the MAC address of the MLD containing the Block Acknowledgment Protocol Context described by the Block Acknowledgment Protocol Context element. The MLD MAC address can be the MLD address of a roaming MLD.

[0694] The "Whether the peer MLD is the same MLD" field indicates whether the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element are the same MLD. A value of 0 indicates that the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation context element are the same MLD; a value of 1 indicates that the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element are multiple MLDs. Alternatively, a value of 1 indicates that the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation context element are the same MLD; a value of 0 indicates that the peer MLDs targeted by the block confirmation protocol context of the MLD described by the block confirmation protocol context element are multiple MLDs. This application embodiment does not limit this.

[0695] The peer MLD MAC address field indicates the MAC address of the peer MLD to which the block acknowledgment protocol context of the MLD described by the block acknowledgment protocol context element is located. When the value of the "Whether the peer MLD is the same MLD" field is 0, the peer MLD MAC address field exists in the block acknowledgment protocol context parameter control field; when the value of the "Whether the peer MLD is the same MLD" field is 1, the peer MLD MAC address field does not exist in the block acknowledgment protocol context parameter control field. Alternatively, when the value of the "Whether the peer MLD is the same MLD" field is 1, the peer MLD MAC address field exists in the block acknowledgment protocol context parameter control field; when the value of the "Whether the peer MLD is the same MLD" field is 0, the peer MLD MAC address field does not exist in the block acknowledgment protocol context parameter control field. This application embodiment does not limit this specific case.

[0696] The Single Block Acknowledgment Protocol Context Parameter Set Count field is a 16-bit unsigned integer indicating the number of single block acknowledgment protocol context parameter set fields in the Block Acknowledgment Protocol Context Parameter Set List field.

[0697] In one possible design of this embodiment, the block confirmation protocol context element includes a block confirmation protocol context parameter set list field, which 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.

[0698] 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: • The role of the device within the block acknowledgment protocol context; • The non-access point multilink device to which the block acknowledgment protocol context applies; • Block confirmation parameter set; • Block confirmation timeout value.

[0699] Regarding the block acknowledgment protocol context parameter set list fields mentioned above, Figure 13 The illustration shows a format diagram of a block confirmation protocol context parameter set list field provided in an exemplary embodiment of this application. The block confirmation protocol context parameter set list field includes at least one of the following: one or more individual block confirmation protocol context parameter set fields, and padding fields.

[0700] The number of bits occupied by the single block confirmation protocol context parameter set field is variable, and the number of bits occupied by the padding field is also variable.

[0701] In one possible design of this embodiment, if the block acknowledgment protocol context parameter set subfield is used to indicate that the device containing the corresponding block acknowledgment protocol context is the initiator in the block acknowledgment protocol context, the block acknowledgment protocol context parameter set subfield is also used to indicate at least one of the following: • Send window start sequence number; • Send window size.

[0702] In one possible design of this embodiment, if the Block Acknowledgment Protocol Context Parameter Set subfield is used to indicate that the device containing the Block Acknowledgment Protocol Context plays the role of a receiver in the Block Acknowledgment Protocol Context; the Block Acknowledgment Protocol Context Parameter Set subfield is also used to indicate at least one of the following: • Start sequence number of the receive buffer; • Receive window size; • Record the starting sequence number of the bitmap; • Record the maximum sequence number of the bitmap; Record bitmap size.

[0703] Regarding the single block acknowledgment protocol context parameter set fields mentioned above, if the MLD containing the block acknowledgment protocol context is the initiator MLD role, Figure 14The illustration shows a format diagram of a single block acknowledgment protocol context parameter set field provided in an exemplary embodiment of this application. The single block acknowledgment protocol context parameter set field includes at least one of the following: MLD role field (initiator MLD), peer MLD field, block acknowledgment parameter set field, block acknowledgment timeout field, send window start sequence number field (WinStart0), and send window size field (WinSize0).

[0704] The MLD role field (initiator MLD) occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the block acknowledgment parameter set field occupies 16 bits, the block acknowledgment timeout value field occupies 8 bits, the send window start sequence number field occupies 12 bits, and the send window size field occupies 10 bits.

[0705] When the MLD in the block confirmation protocol context is the receiver MLD role. Figure 15 The illustration shows a format diagram of a single block acknowledgment protocol context parameter set field provided in an exemplary embodiment of this application. The single block acknowledgment protocol context parameter set field includes at least one of the following: MLD role field (receiver MLD), peer MLD field, block acknowledgment parameter set field, block acknowledgment 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.

[0706] The MLD role field (receiver MLD) occupies 1 bit, the peer MLD field occupies 0 or 48 bits, the block acknowledgment parameter set field occupies 48 bits, the block acknowledgment timeout value field occupies 16 bits, the receive buffer start sequence number field occupies 12 bits, the receive window size field occupies 10 bits, the record bitmap start 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.

[0707] The MLD Role field indicates the role of the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set in the block acknowledgment protocol. For example, a value of 0 indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set acts as the initiator MLD in the block acknowledgment protocol; a value of 1 indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set acts as the receiver MLD in the block acknowledgment protocol. Alternatively, a value of 1 indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set acts as the initiator MLD in the block acknowledgment protocol; a value of 0 indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set acts as the receiver MLD in the block acknowledgment protocol.

[0708] When the MLD containing the block acknowledgment protocol context is the initiator role, the format of a single block acknowledgment protocol context parameter set is as follows: Figure 14 As shown, when the MLD containing the block acknowledgment protocol context is in the receiver role, the format of a single block acknowledgment protocol context parameter set is as follows: Figure 15 As shown.

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

[0710] The Block Acknowledgment Parameter Set field indicates the set of parameters associated with the established block acknowledgment protocol corresponding to the block acknowledgment protocol context described by the Block Acknowledgment Protocol Context Parameter Set field.

[0711] The Block Acknowledgment Timeout field contains the duration in TU (1024 microseconds). If no frame exchange sequence occurs within this duration using the Block Acknowledgment protocol, the Block Acknowledgment protocol will terminate after this duration. Setting this field to 0 indicates a disabled timeout.

[0712] The Send Window Start Sequence Number field is a send buffer control parameter used to indicate the start sequence number of the send window.

[0713] In one possible design of this embodiment, the block confirmation parameter set includes at least one of the following: • Indicator information indicating whether aggregated MSDUs are supported; • Block confirmation strategy; • Flow identifier; • Buffer size.

[0714] Regarding the aforementioned block confirmation parameter set fields, Figure 16The diagram illustrates the format of a block acknowledgment parameter set field provided in an exemplary embodiment of this application. The block acknowledgment parameter set field includes at least one of the following: an A-MSDU support field, a block acknowledgment policy field, a flow identifier (TID) field, and a buffer size field.

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

[0716] The transmit window size field is a transmit buffer control parameter that indicates the buffer size of the transmit window negotiated in the block acknowledgment protocol. Specifically, the transmit window size field indicates the number of buffers available for a given TID. When the A-MSDU support field is equal to 0, the number of bytes each buffer can hold is equal to the maximum size of the MSDU. When the STA-supported A-MSDU field is equal to 1, the number of bytes each buffer can hold is equal to the maximum size of the A-MSDU supported by the STA.

[0717] The Receive Buffer Start Sequence Number field is a control parameter for the Receive Reordering Buffer, representing the value of the sequence number field of the first MSDU or A-MSDU (arranged in ascending order of sequence number) that has not yet been received.

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

[0719] The Record Bitmap Start Sequence Number field is a Scoreboard Context Control parameter. It is a 12-bit unsigned integer start sequence number that represents the lowest sequence number position in the block confirmation record bitmap (indexed by sequence number).

[0720] The record bitmap maximum sequence number field indicates the highest sequence number in the current transmission window.

[0721] The record bitmap size field is a scoreboard context control parameter used to indicate the maximum transmission window size, set to the smaller of the bitmap length and the buffer size field of the relevant response frame of the build block return protocol.

[0722] The above-described block acknowledgment protocol context element format, block acknowledgment protocol context parameter control field format, block acknowledgment protocol context parameter set list field format, single block acknowledgment protocol context parameter set field format, and block acknowledgment parameter set field format are exemplary possibilities. In different embodiments or different designs, it is not excluded that at least one of the following designs may change: the position of the above fields in the frame, the order of arrangement with other fields, the number of bytes occupied, the number of bits occupied, the element name, and the field name. This embodiment does not limit this.

[0723] Security-related context elements: In one possible design of this embodiment, the security association context can also be described as a security association scenario, which is information about the security association process being maintained.

[0724] In one possible design of this embodiment, the security association context element includes a sender PN configuration and PN counter status information that the specified MLD has established and maintained with one or more peer MLDs for security association-related data encryption / decryption and / or integrity protection and verification, and / or receiver replay detection context and replay counter status information. Figure 17 The illustration shows a schematic diagram of a security association context element format provided in an exemplary embodiment of this 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 parameter control field, and a security association context parameter set list field.

[0725] 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.

[0726] In one possible design of this embodiment, the security association context element includes a security association context parameter control field, which is used to indicate at least one of the following: • The device where the security association context element resides; • Whether the device containing the security association context element and the non-access point multilink device to which the security association context is targeted are the same device; • When the device containing the security association context element and the non-access point multilink device to which the security association context is targeted are the same device, the non-access point multilink device to which the security association context is targeted. • The number of security association context parameter sets included in the security association context element.

[0727] In one possible design of this embodiment, the device containing the security association context element is the current access point multilink device.

[0728] Regarding the aforementioned security association context parameter control fields, Figure 18 The illustration shows a schematic diagram of the format of a security association context parameter control field provided in an exemplary embodiment of this 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, number of security association scenario parameter sets field, and reserved field.

[0729] The MLD MAC address field occupies 48 bits, the field indicating whether the peer MLD is the same MLD occupies 1 bit, the peer MLD MAC address field occupies 0 or 48 bits, the field indicating the number of security association scenario parameter sets occupies 16 bits, and the reserved field occupies 7 bits.

[0730] In one possible design of this embodiment, the security association context element includes a security association context parameter set list field, which 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.

[0731] In one possible design of this embodiment, the security association context parameter set subfield is used to indicate at least one of the following: • The role of the device within the security association context; • The non-access point multilink device to which the security association context applies; • Security association type of security association context.

[0732] Regarding the fields in the aforementioned security association context parameter set list, Figure 19 The illustration shows a format diagram of a security association context parameter set list field provided in an exemplary embodiment of this 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.

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

[0734] In one possible design of this embodiment, if the security association context parameter set subfield is used to indicate that the device containing the security association context plays the role of an initiator in the security association context; the security association context parameter set subfield is also used to indicate at least one of the following: • Number of replay counters; ·TID; • Counting of the replay counter for TID.

[0735] In one possible design of this embodiment, if the security association context parameter set subfield is used to indicate that the device containing the security association context plays the role of a receiver in the security association context; the security association context parameter set subfield is also used to indicate at least one of the following: • Package number counter count; ·TID; • Counting for the package number counter for TID.

[0736] Regarding the aforementioned security association context parameter set fields, if the MLD containing the security association context described by the security association context parameter set fields is the receiver MLD role, Figure 20 The illustration shows a schematic diagram of the format of a security association context parameter set field provided in an exemplary embodiment of this application. The security association context parameter set field includes at least one of the following: MLD role field, peer MLD field, PTKSA / GTKSA / TPKSA field, number of replay counters field, one or more TID fields, and one or more replay counter count fields.

[0737] 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 replay counter count field occupies 5 bits, the TID field occupies 8 bits, and the replay counter count ...

Claims

1. A switching method, characterized in that, The method is performed by a non-access point multilink device (non-AP MLD), and the method includes: Send and / or receive at least one first frame, the at least one first frame being used to enable handover between two access point multi-link devices (AP MLDs) based on link reconfiguration; The sending and / or receiving of at least one first frame includes: Send a link reconfiguration request frame, the link reconfiguration request frame being used to instruct the non-AP MLD to request link reconfiguration with the two AP MLDs to achieve switching; Receive a link reconfiguration response frame, which is used to report the link reconfiguration performed with the two AP MLDs to the non-AP MLD.

2. The method according to claim 1, characterized in that, The two AP MLDs belong to the same mobile domain MLD, or the two AP MLDs belong to the same mobile domain; the two AP MLDs belong to the same mobile domain MLD, and the mobile domain MLD is used for at least one of the following: Provide connection services between the non-AP MLD or the two AP MLDs and the distributed system DS; Maintain the data continuity of the non-AP MLD during the switching between the two AP MLDs during roaming; The 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 higher-layer status and / or buffer information of the two AP MLD upper-layer media access control MAC; Manage the distribution of authentication information for the non-AP MLD links; Manage the 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 multi-link with the non-access point multi-link device among the two AP MLDs, the MAC corresponding to the target AP MLD is selected for data transmission. The first data is synchronized between the two AP MLDs, and the first data is used to maintain data communication between the non-AP MLD and the two AP MLDs or DS; The two AP MLDs exchange or indicate MLD-level information through their respective MAC sublayers.

3. The method according to claim 1 or 2, characterized in that, The two AP MLDs include the current AP MLD and the target AP MLD; The link reconfiguration request frame includes: The first element corresponding to the current AP MLD is used to delete at least one link between 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.

4. The method according to claim 3, characterized in that, The first element includes a first reconfiguration multilink element, used to describe the reconfiguration multilink information of the non-AP MLD and the current APMLD; The second element includes a second reconfiguration multilink element, used to describe the reconfiguration multilink information of the non-AP MLD and the target APMLD.

5. The method according to claim 1 or 2, characterized in that, The two AP MLDs include the current AP MLD and the target AP MLD; The link reconfiguration response frame includes: The third element corresponding to the current AP MLD is used to indicate the link reconfiguration status corresponding to the current AP MLD; The fourth element corresponding to the target AP MLD is used to indicate the link reconfiguration status corresponding to the target AP MLD.

6. The method according to claim 5, characterized in that, The third element includes at least one of the following: the 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 state list of the target AP MLD, including at least one reconfiguration state tuple; the number of reconfiguration state tuples of the target AP MLD; The reconfiguration status tuple is used to indicate the reconfiguration status of a link.

7. The method according to any one of claims 3 to 6, characterized in that, The method further includes: (1) The two AP MLDs belong to the same mobile domain MLD, or the two AP MLDs belong to the same mobile domain. Send and / or receive first indication information, which is used to indicate the mobile domain (MLD).

8. The method according to claim 7, 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 Services Set (BSS) switching FT request frames; FT response frame; FT confirmation frame; FT response frame; Associated request frame; Associated response frame; Reassociation request frame; Reassociate response frames; The request frame is used to instruct the non-AP MLD to request the copying or migration of context information between the two AP MLDs to maintain data connectivity during the handover process, and the response frame is used to instruct the non-AP MLD on the copying or migration results of context information between the two AP MLDs.

9. The method according to claim 7 or 8, characterized in that, The first indication information includes at least one of the following: Mobile Domain MLD Identifier; Mobile domain MLD MAC address.

10. The method according to claim 5, characterized in that, 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.

11. The method according to claim 5, characterized in that, The link reconfiguration response frame includes: Basic multilink elements are used to provide site STA-level configuration files for one or more affiliated APs of the target AP MLD.

12. The method according to any one of claims 1 to 11, characterized in that, The two AP MLDs include the current AP MLD and the target AP MLD. The link reconfiguration request frame is sent to the current AP MLD and then sent from the current AP MLD to the target AP MLD.

13. The method according to any one of claims 1 to 11, characterized in that, The two AP MLDs include the current AP MLD and the target AP MLD. The link reconfiguration response frame is sent from the target AP MLD to the current AP MLD and then fed back by the current AP MLD.

14. The method according to any one of claims 1 to 13, characterized in that, The method further includes: Send and / or receive at least one second frame, the second frame being used to synchronize context information related to the non-AP MLD between the two AP MLDs, the context information including at least one of status information and buffer information.

15. The method according to claim 14, characterized in that, The sending and / or receiving of at least one second frame includes: Send a request frame, the request frame being used to instruct the non-AP MLD to request the synchronization of context information related to the non-AP MLD between the two AP MLDs; A response frame is received, which is used to feed back context information related to the non-AP MLD to the non-AP MLD for synchronization between the two AP MLDs.

16. The method according to claim 15, characterized in that, The context information includes at least one of the following: First context information, which is information related to the block acknowledgment protocol context; The second context information is information related to the security association context.

17. A non-access point multi-link device, characterized in that, The non-access point multi-link device includes: processor; A transceiver connected to the processor; Memory for storing the executable instructions of the processor; 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 16.

Images