Communication method and communication device

Abstract

A communication method and a communication device. The method comprises: a first device sends first information to a second device, the first information being associated with context of a communication protocol of downlink data, the communication protocol of the downlink data being used for a non-access point (AP) device, and the non-AP device being a non-AP device roaming from a first AP device to a second AP device, wherein if the first device is the non-AP device, the second device is the first AP device or the second AP device, or if the first device is the first AP device or the second AP device, the second device is the non-AP device, or if the first device is the first AP device, the second device is the second AP device. The first information associated with the context of the communication protocol of the downlink data can be transmitted between the first device and the second device, thereby helping to improve the continuity of downlink data transmission performed by a non-access device in a roaming scenario.

Description

Communication methods and communication equipment

[0001] This application claims priority to Chinese Patent Application No. PCT / CN2024 / 132496, filed on November 15, 2024, entitled "Migration Method, Apparatus, Device and Storage Medium", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and more specifically, to a communication method and communication device. Background Technology

[0003] For several reasons, when a non-access point device roams from a first access point (AP) device to a second AP device, the reception and transmission of downlink data may be affected, resulting in low continuity of downlink data transmission. Summary of the Invention

[0004] This application provides a communication method and a communication device. The various aspects covered by this application are described below.

[0005] In a first aspect, a communication method is provided, comprising: a first device sending first information to a second device, the first information being associated with a communication protocol context for downlink data, the communication protocol for the downlink data being for a non-access point device, the non-access point device being a non-access point device roaming from a first access point device to the second access point device; wherein, if the first device is the non-access point device, then the second device is either the first access point device or the second access point device, or if the first device is either the first access point device or the second access point device, then the second device is the non-access point device; or if the first device is the first access point device, then the second device is the second access point device.

[0006] In a second aspect, a communication method is provided, comprising: a second device receiving first information sent by a first device, the first information being associated with a communication protocol context for downlink data, the communication protocol for the downlink data being for a non-access point device, the non-access point device being a non-access point device roaming from a first access point device to a second access point device; wherein, if the first device is the non-access point device, then the second device is either the first access point device or the second access point device, or if the first device is either the first access point device or the second access point device, then the second device is the non-access point device; or if the first device is the first access point device, then the second device is the second access point device.

[0007] Thirdly, a communication device is provided, the communication device being a first device, comprising: a transmitting unit for transmitting first information to a second device, the first information being associated with a communication protocol context for downlink data, the communication protocol for the downlink data being for a non-access point device, the non-access point device being a non-access point device roaming from a first access point device to the second access point device; wherein, if the first device is the non-access point device, then the second device is either the first access point device or the second access point device, or if the first device is either the first access point device or the second access point device, then the second device is the non-access point device; or if the first device is the first access point device, then the second device is the second access point device.

[0008] Fourthly, a communication method is provided, comprising: a second device receiving first information sent by a first device, the first information being associated with a communication protocol context of downlink data, the communication protocol of the downlink data being for a non-access point device, the non-access point device being a non-access point device roaming from a first access point device to a second access point device; wherein, if the first device is the non-access point device, then the second device is either the first access point device or the second access point device, or if the first device is either the first access point device or the second access point device, then the second device is the non-access point device; or if the first device is the first access point device, then the second device is the second access point device.

[0009] Fifthly, a communication device is provided, including a processor, a memory, and a communication interface, wherein the memory is used to store one or more computer programs, and the processor is used to invoke the computer programs in the memory to cause the terminal device to perform some or all of the steps in the methods of the above aspects.

[0010] Sixthly, embodiments of this application provide a communication system including the aforementioned terminal device and / or network device. In another possible design, the system may further include other devices that interact with the terminal device or network device as described in the embodiments of this application.

[0011] In a seventh aspect, embodiments of this application provide a computer-readable storage medium storing a computer program that causes a communication device to perform some or all of the steps in the methods described above.

[0012] Eighthly, embodiments of this application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program operable to cause a communication device to perform some or all of the steps of the methods described in the foregoing aspects. In some implementations, the computer program product may be a software installation package.

[0013] Ninthly, embodiments of this application provide a chip including a memory and a processor, the processor being able to call and run a computer program from the memory to implement some or all of the steps described in the methods of the foregoing aspects.

[0014] In this embodiment of the application, the first device and the second device can transmit first information associated with the communication protocol context of downlink data, which helps to improve the continuity of downlink data transmission by non-access devices in roaming scenarios. Attached Figure Description

[0015] Figure 1 shows the wireless communication system 100 used in an embodiment of this application.

[0016] Figure 2 is a schematic diagram of a scheme for establishing a multi-link between an AP multi-link device (MLD) and a non-AP MLD, applicable to embodiments of this application.

[0017] Figure 3 is a schematic diagram of the logical AP MLD applicable to the embodiments of this application.

[0018] Figure 4 is a schematic flowchart of a communication method according to an embodiment of this application.

[0019] Figures 5A, 5B, 5C, 5D, 5E, and 5F are schematic diagrams of the context elements and related domain definitions of the bearer block confirmation protocol in the embodiments of this application.

[0020] Figures 6A, 6B, 6C, 6D, and 6E are schematic diagrams of elements carrying security association context and related domain definitions in embodiments of this application.

[0021] Figures 7A and 7B are schematic diagrams of the wireless roaming process according to an embodiment of this application.

[0022] Figure 8 is a schematic diagram of synchronization based on the communication protocol context in an embodiment of this application.

[0023] Figure 9 is a schematic diagram of the fast basic service set transition (FT) protocol optimization scheme based on data continuity provided in the embodiments of this application.

[0024] Figure 10 is a schematic diagram of a link reconfiguration scheme for data continuity provided in an embodiment of this application.

[0025] Figure 11 is a schematic structural diagram of the communication device provided in an embodiment of this application.

[0026] Figure 12 is a schematic structural diagram of a communication device provided in another embodiment of this application.

[0027] Figure 13 is a schematic structural diagram of a communication device according to an embodiment of this application. Detailed Implementation

[0028] The technical solutions in this application will now be described with reference to the accompanying drawings.

[0029] Communication system

[0030] The technical solutions of this application can be applied to various communication systems, such as wireless local area networks (WLAN), wireless fidelity (WiFi), high-performance radio local area networks (HIPELAN), wide area networks (WAN), cellular networks, or other communication systems. For example, the technical solutions provided in this application can be applied to communication systems using the 802.11 standard. Exemplarily, the 802.11 standard includes, but is not limited to, the 802.11ax standard, the 802.11be standard, the 802.11bn standard, and the next-generation 802.11 standard (post802.11bn).

[0031] Figure 1 shows a schematic diagram of a communication system applicable to an embodiment of this application. Referring to Figure 1, the communication devices in the communication system 100 may include access points (APs) 111 and 112, as well as stations (STAs) 121 and 122. STA 121 can access the network through AP 111, and STA 122 can access the network through AP 112.

[0032] In some implementations, a STA can establish an association with one or more APs, after which the associated STAs and APs can communicate with each other. As shown in Figure 1, AP 111 and STA 121 can communicate after establishing an association, and AP 112 and STA 122 can communicate after establishing an association.

[0033] In some implementations, the communication in the communication system 100 can be communication between an AP and a non-AP STA, communication between two non-AP STAs, or communication between a STA and a peer STA. Here, a peer STA can refer to a device that communicates with the STA's counterpart. For example, a peer STA may be an AP or a non-AP STA.

[0034] It should be understood that Figure 1 exemplarily shows two AP STAs and two non-AP STAs. The communication system 100 may also include more AP STAs, or the communication system 100 may include other numbers of non-AP STAs. This application embodiment does not limit this.

[0035] In addition, the above-mentioned communication system can be applied to scenarios involving multi-device collaboration, such as multi-AP (multi-access points) collaboration or multi-site collaboration.

[0036] In the embodiments of this application, the names of AP and / or STA are not limited. In some scenarios, AP can also be called AP STA, that is, in a sense, AP is also a type of STA. In other scenarios, STA can be called non-AP STA.

[0037] In some scenarios, the aforementioned communication equipment can also be a "multi-link device (MLD)," meaning a device that can communicate through multiple communication links. These multiple communication links can include communication links in different frequency bands, such as millimeter-wave bands and / or low-frequency bands. Typically, if the multi-link device is an access point (AP), it can also be called an "AP MLD." If the multi-link device is a non-AP STA, it can also be called a "non-AP MLD."

[0038] In this application embodiment, the AP can be a device in a wireless network. The AP can be a communication server, router, switch, bridge, or other communication entity. Alternatively, the AP can include various forms of macro base stations, micro base stations, relay stations, etc. Of course, the AP can also be a chip, circuit, or processing system within these various forms of devices, thereby implementing the methods and functions of this application embodiment. APs can be applied in various scenarios, such as sensor nodes in smart cities (e.g., smart water meters, smart electricity meters, smart air quality monitoring nodes), smart devices in smart homes (e.g., smart cameras, projectors, displays, televisions, audio equipment, refrigerators, washing machines, etc.), nodes in the Internet of Things (IoT), entertainment terminals (e.g., AR, VR, and other wearable devices), smart devices in smart offices (e.g., printers, projectors, etc.), vehicle-to-everything (V2X) devices, and some infrastructure in daily life scenarios (e.g., vending machines, supermarket self-service navigation kiosks, self-service checkout machines, self-service ordering machines, etc.).

[0039] In some implementations, the role of the STA in the communication system is not absolute; in some scenarios, the STA can act as an AP. For example, in a scenario where a mobile phone connects to a router, the mobile phone can be a non-AP STA, while when the mobile phone acts as a hotspot for other mobile phones, it takes on the role of an AP.

[0040] In the embodiments of this application, the STA can be a device with wireless transceiver capabilities, such as one that supports the 802.11 series of protocols and can communicate with the AP or other STAs. For example, an STA is any user communication device that allows users to communicate with the AP and thus with the WLAN. STAs include, for example, user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device, etc.

[0041] In this application embodiment, the STA can also be a device that provides voice / data / image connectivity to the user, such as a handheld device, vehicle device, home device, home appliance, gaming device, etc., with wireless connection function or equipped with a wireless communication module. Examples include: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving vehicles, drones or aerial photography equipment, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, wearable devices, terminal devices in 5G networks, or future evolution of public land mobile communication networks. Terminal devices in a network (PLMN) can also be televisions, refrigerators, washing machines, kitchen appliances, door locks, fish tanks, robot vacuum cleaners, game consoles, cameras / camcorders, etc. with wireless connectivity, but this application embodiment is not limited to these.

[0042] By way of example and not limitation, in this embodiment, the STA can also be a wearable device. Wearable devices, also known as wearable smart devices, are a general term for devices that utilize wearable technology to intelligently design and develop everyday wearables, such as glasses, gloves, watches, clothing, and shoes. Examples include smartwatches or smart glasses, as well as devices that focus on a specific type of application function and require cooperation with other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

[0043] Furthermore, in this embodiment, the STA can also be a terminal device in an Internet of Things (IoT) system. IoT is an important component of future information technology development, and its main technical feature is connecting objects to networks through communication technologies, thereby realizing an intelligent network for human-machine interconnection and object-to-object interconnection. In this embodiment, IoT technology can achieve massive connectivity, deep coverage, and low terminal power consumption through technologies such as narrowband (NB).

[0044] Furthermore, in this embodiment, the STA can be a device in a vehicle-to-everything (V2X) system. The communication methods in a V2X system are collectively referred to as V2X (where X represents anything). For example, V2X communication includes: vehicle-to-vehicle (V2V) communication, vehicle-to-infrastructure (V2I) communication, vehicle-to-pedestrian (V2P) communication, or vehicle-to-network (V2N) communication, etc.

[0045] In addition, in the embodiments of this application, the STA may also include sensors such as smart printers, train detectors, and gas stations. Its main functions include collecting data (some terminal devices), receiving control information and downlink data from the AP, and sending electromagnetic waves to transmit data to the AP.

[0046] In addition, the AP in this application embodiment can be a device for communicating with the STA. The AP can be a network device in a wireless local area network, and the AP can be used to communicate with the STA through the wireless local area network.

[0047] From the perspective of the communication standards supported by the AP, in some implementations, 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.

[0048] From the perspective of the communication standards supported by the STA, in some implementations, non-AP STAs can support the 802.11be standard. Non-AP STAs can also support various current and future 802.11 family of wireless local area networks (WLAN) standards, such as 802.11ax, 802.11ac, 802.11n, 802.11g, 802.11b, and 802.11a.

[0049] In this application embodiment, the frequency bands supported by WLAN technology are not limited. In some implementations, the frequency bands supported by WLAN technology may include, but are not limited to: low frequency bands (e.g., 2.4GHz, 5GHz, 6GHz) and high frequency bands (e.g., 45GHz, 60GHz).

[0050] It should be understood that the specific forms of STA and AP are not specifically limited in the embodiments of this application, and are merely illustrative examples.

[0051] Multi-link operation

[0052] Some communication protocols (e.g., the IEEE 802.11be standard) define multi-link operation (MLO) and AP MLD and non-AP MLD devices with multi-link operation capabilities. AP MLD and non-AP MLD can establish multiple links on multiple different frequency bands / channels.

[0053] Figure 2 illustrates the scheme for establishing multiple links between AP MLDs and non-AP MLDs applicable to embodiments of this application. Referring to Figure 2, three links are established between the AP MLD and the non-AP MLD on 2.4 GHz, 5 GHz, and 6 GHz, respectively, referred to as Link 1, Link 2, and Link 3. These three links can operate simultaneously. AP 1 operating on Link 1 (2.4 GHz), AP 2 operating on Link 2 (5 GHz), and AP 3 operating on Link 3 (6 GHz) are referred to as affiliated APs of the AP MLD. Correspondingly, non-AP STA 1 operating on Link 1 (2.4 GHz), non-AP STA 2 operating on Link 2 (5 GHz), and non-AP STA 3 operating on Link 3 (6 GHz) are referred to as affiliated non-AP STAs of the non-AP MLD.

[0054] Logical AP MLD (or Roaming MLD)

[0055] Some communication protocol proposals suggest treating multiple non-collocated APs as a single logical AP MLD entity. When a STA connects to this AP MLD, the multiple non-collocated APs can be considered as different affiliated APs of the AP MLD. This allows the use of the multi-link operation architecture described earlier to enable the AP MLD to provide services to the STA via different affiliated APs and different links, thus better achieving uninterrupted roaming for the STA. Figure 3 is a schematic diagram of the logical AP MLD applicable to the embodiments of this application. Referring to Figure 3, STAx uses multiple links to connect to AP1 and AP2 respectively. When STAx moves out of the coverage area of ​​AP1, the link connection with AP1 can be disconnected without affecting the link connection between STAx and AP2. Therefore, better support for STA mobility can be achieved.

[0056] Currently, several standard proposals have outlined various approaches to seamless roaming. For example, some proposals suggest mobility domain-based seamless roaming, where a non-AP MLD establishes an association with a seamless mobility domain (SMD) through an AP MLD. The initial association with the SMD establishes a security context (pairwise master key security association (PMKSA) and pairwise transient key security association (PTKSA)) applicable to all AP MLDs within the SMD. Furthermore, the SMD conceptually defines a mobility domain for seamless roaming, i.e., a set of AP MLDs within the same ESS, supporting seamless roaming between them, and identified by the SMD MAC address. An extended service set (ESS) can configure one or more SMDs, each SMD covering the AP MLDs belonging to that SMD.

[0057] For example, some proposals suggest a seamless roaming mechanism based on the roaming AP MLD architecture. This mechanism allows for the reuse / extension of the 11be multi-link reconfiguration framework based on the roaming AP MLD architecture. Furthermore, it specifies the use of the same set of management signaling frameworks and employs detailed signaling procedures to demonstrate how seamless roaming can operate between APs without data forwarding.

[0058] For example, some proposals put forward seamless roaming schemes based on FT optimization. These schemes extend the existing FT architecture and propose high-level requirements for ultra-high reliability (UHR) seamless roaming. These high-level requirements may include descriptions of new features for achieving seamless roaming, security framework requirements, baseline roaming performance, and enhancement priorities.

[0059] Fast BSS transition (FT)

[0060] The goal of fast BSS transition is to reduce the duration of connection loss between the STA and the distribution system (DS) or non-AP MLD and the DS during BSS transition. The FT protocol is part of the reassociation service and is typically used for transitions between STAs or non-AP MLDs within the same ESS and the same mobile domain, between APs or AP MLDs.

[0061] In some implementations, the AP can publish functions and policies that support FT protocols and methods. FT functions are published via beacon frames and probe response frames that include Mobile Domain Elements (MDEs). The MDEs, published in the beacon frames and probe response frames, can be used to indicate MDIDs, FT capabilities, and FT policies.

[0062] In some implementations, the FT protocol requires the exchange of information between the STA (also known as the fast BSS transition originator, FTO) and the AP (also known as the fast BSS transition responder, FTR). For example, the FT protocol requires the exchange of information during the initial association between a non-AP MLD (also known as FTO) and an AP MLD (also known as FTR). As another example, the FT protocol requires the exchange of information during the reassociation between a non-AP MLD (also known as FTO) and an AP MLD (also known as FTR). The information exchange during the initial association is called the FT initial mobile domain association, and subsequent reassociation with FTRs within the same mobile domain can use the FT protocol.

[0063] In some implementations, FT defines two FT protocols: the FT protocol and the FT resource request protocol. The FT protocol is executed during the transformation from the FTO to the target FTR, and no resource request is required before the transformation. The FT resource request protocol is executed when the FTO requires a resource request before its transformation.

[0064] In some implementations, for an FTO moving to a target FTR using the FT protocol, message exchange employs two methods: a radio-based message exchange method and a DS (Over-the-DS) message exchange method. The radio-based method refers to the FTO communicating directly with the target FTR, for example, using IEEE 802.11 authentication and / or FT authentication algorithms. The DS-based method refers to the FTO communicating with the target FTR through the current FTR. Communication between the current FTO and the target FTR occurs within FT action frames between the FTO and the current FTR. Communication between the current FTR and the target FTR is performed using the encapsulation method described in the "Remote Request / Response Frame Definition." Accordingly, the AP converts between the two encapsulation formats.

[0065] Robust Security Network Association (RSNA) Confidentiality and Integrity Protocol

[0066] Currently, the RSNA data confidentiality and integrity protocols defined by the Wi-Fi standard include Counter Mode (CTR) with Cipher Block Chaining Message Authentication Code (CBC-MAC) protocol (CTR with CBC-MAC protocol, CCMP) and Galois / Counter Mode protocol (Galois / Counter Mode protocol, GCMP).

[0067] CCMP provides data confidentiality, authentication, integrity, and replay protection. CCMP is a CCM based on the AES encryption algorithm. CCM combines CTR for data confidentiality and CBC-MAC for authentication and integrity. CCM protects the integrity of MPDU data fields and selected portions of the IEEE 802.11 MPDU header. CCM is a general-purpose mode that can be used with any block-oriented encryption algorithm. CCM requires a new temporary key for each session. CCM also requires each frame protected by the given temporary key to have a unique nonce value. Reusing a nonce value with the same temporary key will invalidate all security guarantees.

[0068] For secure PV0 medium protocol data units (MPDUs), CCMP specifies that the frame body field of the plaintext MPDU is encrypted and encapsulated into the generated ciphertext. A new non-zero PN is obtained for each MPDU by adding a packet number (PN), so that the PN will not be repeated for the same temporary key.

[0069] In some implementations, the PN value is sequentially assigned to each MPDU number. For each transmitting STA not attached to the MLD, a single PN should be maintained for each PTKSA and group temporal key security association (GTKSA) (e.g., maintained based on a 48-bit counter). For each transmitting STA attached to the MLD, either the PN maintained by the MLD for the PTKSA (e.g., maintained based on a 48-bit counter) or the PN maintained by the STA for the GTKSA should be used. The PN can be a strictly incrementing 48-bit integer, initialized to 0 when the corresponding temporary key is initialized or refreshed (via key update).

[0070] In some implementations, the PN value for each MPDU increments by a positive number. For MPDUs containing Fragmented MAC Service Data Units (MSDUs), Aggregate MAC Service Data Units (A-MSDUs), and Media Access Control Management Protocol Data Units (MMPDUs), the PN should increment by 1. For PV0 MPDUs, the PN of a series of encrypted MPDUs using the same temporary key will not be repeated. For PV1 MPDUs, the PN of a series of encrypted MPDUs using the same temporary key and PTID (for data frames) will never be repeated.

[0071] In some implementations, when the PN space is exhausted (i.e., the PN exceeds the minimum and maximum PN exhaustion thresholds), the corresponding key can be replaced or communication can be terminated. If a separately addressed MPDU is sent from the MLD to the receiving MLD via an affiliated STA, a single PN space should be reserved for the PTKSA so that the MPDU can be transmitted through all affiliated STAs.

[0072] In some implementations, the receiver should discard any received data frames whose PN is less than or equal to the value of a replay counter, where the replay counter is associated with the sender address or transmitting station address (TA), receiver address or receiving station address (RA), and priority value of the received MPDU. If the MPDU is a separately addressed data frame transmitted between an AP MLD and a non-AP MLD associated with the AP MLD via an attached STA, the receiver should discard any received data frames whose PN is less than or equal to the value of a replay counter, which is associated with the sender MLD MAC address, the receiver MLD MAC address (personal or group address), and the priority value of the received MPDU.

[0073] In some implementations, for each individual addressed MPDU received by an affiliated STA from the transmitting MLD, the receiving MLD should maintain a set of replay counters for the PTKSA for all affiliated STAs.

[0074] Block ack mechanism

[0075] The block acknowledgment mechanism aims to improve channel efficiency by aggregating multiple acknowledgments into a single frame. Typically, the STA that sends data using the block acknowledgment mechanism is called the originator, and the intended receiving station is called the recipient.

[0076] Currently, besides GLK-GCR block acknowledgments or the use of an unsolicited block acknowledgment extension mechanism, the block acknowledgment mechanism can be initialized by exchanging ADDBA request / response frames. After initialization, the initiator can transmit a series of blocks of quality of service (QoS) data frames to the receiver. A block can be started in a polled TXOP, in a SP, or by winning a TXOP via EDCA. Typically, the number of data frames in a block is limited, and the amount of state retained by the receiver is also limited. MPDUs within a block's frames can be acknowledged by block acknowledgment frames, which can be requested by a block acknowledgment frame request (denoted as BlockAckReq).

[0077] In some implementations, the initiator includes a transmit buffer control that uses WinStartO and WinSizeO to submit the MPDU and releases the transmit buffer upon receiving a BlockAck frame from the receiver. WinStartO is the starting sequence number of the transmit window, and WinSizeO is the number of buffers negotiated in the block acknowledgment protocol. The initiator can transmit QoS data frames with TIDs matching the block return protocol in any order, as long as their sequence numbers are within the current transmission window.

[0078] In some implementations, the receiver includes receive reordering buffer control for each TA / transmission identifier (TID), containing the associated control states. The receive reordering buffer is responsible for reordering MSDUs or A-MSDUs so that they are ultimately delivered to the next MAC process in the order of their received sequence numbers. Additionally, it is responsible for identifying and discarding duplicate frames (i.e., frames with the same sequence number).

[0079] Currently, for multi-link devices, MLDs follow the mechanism defined by the block acknowledgment operation, and also comply with the additional rules defined by the block acknowledgment process in multi-link operations. The MLD that uses the block acknowledgment mechanism to send data is called the sender MLD, and the MLD that is the intended recipient of that data is called the receiver MLD.

[0080] To establish a block acknowledgment agreement (BACK) between two MLDs, the initiating MLD sends an ADDBA request frame to the receiving MLD via any affiliated STAs operating on the enabled link, depending on the power state of the non-AP STAs operating on that link. The ADDBA request frame indicates the TID for which the BACK is being established. Upon receiving the ADDBA request frame, the receiving MLD should respond via any affiliated STAs operating on the enabled link, with the ADDBA response frame depending on the power state of the non-AP STAs operating on that link. The receiving MLD can then choose to accept or reject the request. If the receiving MLD accepts the request, a BACK is established between the sending and receiving MLDs for the TID specified in the ADDBA frame.

[0081] In some implementations, when a block acknowledgment protocol is established between two MLDs for a certain TID, QoS data frames belonging to that TID can be exchanged between the two MLDs on any link mapped to the TID according to the Flow Identifier to Link Mapping (TTLM) rules and multi-link power management rules.

[0082] In some implementations, the initiating MLD maintains a single common transport buffer control, using WinStartO and WinSizeO to handle the block return protocol negotiated with the receiving MLD for submitting MPDUs for transmission on TTLM-bound links. Accordingly, the sending MLD should release the transmit buffer associated with the successfully received MPDU upon receiving a BlockAck frame indicating that the MPDU has been received.

[0083] In some implementations, the receiver MLD is configured to perform a block acknowledgment protocol for each...<peer MLD,TID> The tuple maintains a separate common receive reordering buffer, independent of the number of established links. This buffer is responsible for reordering MSDUs or A-MSDUs so that they are ultimately passed up to the next MAC process in the order of their received sequence numbers. Additionally, the common receive reordering buffer is responsible for identifying and discarding duplicate frames (i.e., frames with the same sequence number as the currently buffered frame) that are part of the block acknowledgment protocol.

[0084] As mentioned earlier, for some reasons, when a non-AP STA roams from the source AP to the target AP, the reception and transmission of downlink data may be affected, resulting in low continuity of downlink data transmission. In severe cases, this may lead to problems such as downlink data packet loss or delayed transmission.

[0085] Therefore, to address the aforementioned problems, this application provides a communication method in which a first device and a second device can transmit first information associated with the communication protocol context of downlink data, which helps improve the continuity of downlink data transmission by non-access devices in roaming scenarios. The communication method of this application embodiment is described below with reference to FIG4. The method shown in FIG4 includes step S410.

[0086] In step S410, the first device sends first information to the second device, the first information being associated with the communication protocol context of the downlink data.

[0087] In some implementations, for the communication protocol of downlink data, the non-access point device is the receiver of the data frame carrying the downlink data and / or the receiver of the block acknowledgment protocol. Correspondingly, the first access point device or the second access point device is the sender of the data frame and / or the originator of the block acknowledgment protocol.

[0088] In some implementations, the communication protocol is used to support downlink data communication; therefore, the communication protocol context is also called the "data communication context".

[0089] In some implementations, the communication protocol for downlink data includes a block acknowledgment protocol (DL BA) for downlink data frame transmission. Specifically, downlink data refers to QoS data frames sent by a first or second AP device to a non-access point device. For example, downlink data can refer to separately addressed QoS data frames or QoS null frames sent to a non-AP MLD.

[0090] In some implementations, downlink data can be encapsulated as "data packets," which can be understood as QoS data frames, and / or MAC protocol data units (MPDUs) and / or management MAC protocol data units (MMPDUs). Alternatively, data packets can also be understood as MAC service data units (MSDUs) and / or A-MSDUs.

[0091] In some implementations, a non-access point device is a non-access point device that roams from a first AP device to a second AP device, where the first AP can be called the source AP and the second AP can be called the target AP.

[0092] In the embodiments of this application, the first device and the second device are not limited. For example, the first device is a non-access point device, and the second device is a first AP device or a second AP device. As another example, the first device is a first AP device or a second AP device, and correspondingly, the second device is a non-access point device. Yet another example, the first device is a first AP device, and the second device is a second AP device. The following will describe these three cases in conjunction with implementation methods 1 to 3.

[0093] In this embodiment, the aforementioned devices are not limited; the non-access point device can be a non-AP STA or the non-AP MLD described above. Furthermore, the first device can be an AP or an AP MLD. Correspondingly, the second device can be an AP or an AP MLD.

[0094] Implementation method 1: The first device is either the first AP device or the second AP device.

[0095] In some implementations, the second device is either a second access point (AP) device or a non-access point device. For example, if the first device is a first AP device, then the second device is a second AP device. Alternatively, if the first device is a first AP device, then the second device is a non-access point device. Or, if the first device is a second AP device, then the second device is a non-access point device.

[0096] In some implementations, the first information carries some or all of the communication protocol context information of the downlink data, or in other words, the first information carries some or all of the parameters of the communication protocol context of the downlink data. The communication protocol context can be understood as the context associated with the communication protocol used for downlink data transmission. This communication protocol may include the BA protocol and / or the RSNA confidentiality and integrity protocol described above. Accordingly, the communication protocol context may include the BA protocol context (block ack agreement context) and / or the RSNA confidentiality and integrity protocol context. The BA protocol context is also called the BA protocol scenario parameter, and the RSNA confidentiality and integrity protocol context is also called the "RSNA confidentiality and integrity protocol scenario parameter."

[0097] As mentioned above, communication protocols are used to transmit downlink data; therefore, the communication protocol context can also be called the data communication context. In other scenarios, the communication protocol context can be understood as being used to synchronize the transmission status, downlink data, or downlink data transmission parameters between a first device and a second device to improve the continuity of downlink data transmission. Therefore, the communication protocol context can also be called the synchronization information for downlink data transmission.

[0098] In some implementations, if the first device is a first AP device, then the communication protocol context can be understood as the communication protocol context of the first AP device. In other implementations, if the first device is a second AP device, then the communication protocol context can be understood as the communication protocol context of the second AP device.

[0099] In some implementations, the communication protocol context is used to indicate one or more of the following: the SN corresponding to the downlink data to be allocated for the first TID; the sequence number (SN) corresponding to the last downlink data to arrive in the buffer queue in the downlink data corresponding to the first TID; the SN corresponding to the last downlink data sent by the first AP device in the downlink data corresponding to the first TID; the control status information of the transmit buffer corresponding to the first TID; the PN corresponding to the last downlink data to arrive in the buffer queue in the downlink data corresponding to the first TID; the minimum and / or maximum PN exhaustion threshold associated with the key corresponding to the first TID; whether the first AP device and / or the second AP device support downlink data migration via DS; the migration status of the downlink data; and whether the transmission key of the downlink data corresponding to the first AP device is the same as the transmission key of the downlink data corresponding to the second AP device.

[0100] It should be noted that the first TID mentioned above can be one of multiple TIDs, or a specific TID. Of course, in the embodiments of this application, the first TID can be any one of multiple TIDs. In this case, it can be understood that the communication protocol context is used to describe each of the multiple TIDs.

[0101] Taking the communication protocol context as an example to indicate the SN corresponding to the downlink data to be allocated to the first stream identifier (TID), the SN corresponding to the downlink data to be allocated to the first stream identifier (TID) can be understood as the SN of the next downlink data packet to be allocated to the first TID.

[0102] Taking the communication protocol context as an example to indicate the SN of the last downlink data that arrives in the buffer queue in the downlink data corresponding to the first TID, the SN of the downlink data can be, for example, the SN of the last downlink data packet in the buffer queue when the DS mapping update is completed.

[0103] Taking the communication protocol context as an example to indicate the SN corresponding to the latest downlink data sent by the first AP device in the downlink data corresponding to the first TID, this SN can be understood as the highest SN among the SNs of the downlink data packets corresponding to the first TID sent by the first AP device.

[0104] Taking the control status information of the transmission buffer corresponding to the first TID in the communication protocol context as an example, the control status information is used to indicate one or more of the following: the starting sequence number corresponding to the transmission buffer (represented as WinStartO); the size of the buffer corresponding to the transmission buffer (represented as WinSizeO); and whether the downlink data buffered in the transmission buffer has been successfully transmitted.

[0105] In some implementations, the aforementioned control status information can be used to indicate whether the downlink data buffered in the transmit buffer has been successfully transmitted via a record bitmap corresponding to the downlink data. For example, if the position corresponding to SN in the record bitmap is 1, it indicates that the downlink data corresponding to that SN is downlink data that the receiver has not yet received. Conversely, if the position corresponding to SN in the record bitmap is 0, it indicates that the downlink data corresponding to that SN is downlink data that the receiver has already received.

[0106] Taking the communication protocol context as an example, which indicates the PN corresponding to the last downlink data that arrives in the buffer queue in the downlink data corresponding to the first TID, the PN may be, for example, the PN number assigned to the last data packet in the buffer queue when the DS mapping update is completed.

[0107] Taking the communication protocol context as an example, which indicates the minimum and / or maximum PN depletion threshold associated with the key corresponding to the first TID, the minimum and / or maximum PN depletion thresholds are also referred to as the maximum and / or minimum values ​​of the PN depletion thresholds.

[0108] Taking the communication protocol context used to indicate whether the first AP device and / or the second AP device support the migration of downlink data via DS as an example, the communication protocol context is used to indicate whether it supports the migration of downlink data from the first AP device to the second AP device via DS.

[0109] Taking the communication protocol context as an example to indicate the migration status of downlink data, the migration status of downlink data is used to indicate whether downlink data has been successfully migrated from the first AP device to the second AP device.

[0110] In some scenarios, where both the first and second AP devices support downlink data migration via DS, the communication protocol context can indicate the downlink data migration status. Conversely, if the first and / or second AP devices do not support downlink data migration via DS, the communication protocol context may not indicate the downlink data migration status to reduce the overhead of transmitting the communication protocol context.

[0111] The communication protocol context in the embodiments of this application has been introduced above. The transmission scheme of the communication protocol context in the embodiments of this application is described below.

[0112] In some implementations, the communication protocol context is carried in roaming response frames and / or communication protocol context status notification frames.

[0113] In some implementations, the transmission of the communication protocol context satisfies one or more of the following: it occurs before the transmission of the roaming request frame; it occurs after the transmission of the roaming request frame; it occurs before the transmission of the roaming response frame; or it occurs simultaneously with the transmission of the roaming response frame.

[0114] In some implementations, the aforementioned roaming request frame may also be at least one of an association request frame, a reassociation request frame, a fast conversion request frame, a link configuration request frame, and a link reconfiguration request frame.

[0115] In some implementations, the aforementioned roaming response frame may also be at least one of the following: association response frame, reassociation response frame, fast conversion response frame, link setting response frame, and link reconfiguration response frame.

[0116] In some implementations, one or more of the following are carried in a first field: the SN corresponding to the downlink data to be assigned to the first stream identifier (TID); the SN corresponding to the last downlink data to arrive at the buffer queue in the downlink data corresponding to the first TID; and the SN corresponding to the latest downlink data sent by the first AP device in the downlink data corresponding to the first TID. The first field is used to carry block confirmation protocol related parameters.

[0117] Implementation method 2: The first device is either the first AP device or the second AP device, and the second device is a non-access point device.

[0118] In some implementations, the first information is used to indicate the migration status of the communication protocol context of the downlink data.

[0119] In some implementations, the migration status of the communication protocol context is used to indicate whether the communication protocol context has been successfully migrated from the first AP device to the second AP device.

[0120] As mentioned above, the communication protocol context can also be referred to as the synchronization information for downlink data transmission. Correspondingly, the aforementioned migration state can also be called the "synchronization state," used to indicate whether the synchronization information migration was successful or failed.

[0121] In some implementations, the first information is carried in the roaming response frame.

[0122] Implementation method 3: The first device is a non-access point device.

[0123] In some implementations, the second device is either the first access point (AP) device or the second AP device. For example, if the first device is a non-access point device, then the second device is the second AP device. Or, for another example, if the first device is a non-access point device, then the second device is the first AP device.

[0124] In some implementations, the first information carries some or all of the communication protocol context information of the downlink data, or in other words, the first information carries some or all of the parameters of the communication protocol context of the downlink data. Here, the communication protocol context can be understood as the context associated with the communication protocol used for downlink data transmission, which may include the BA protocol and / or RSNA confidentiality and integrity protocol described above. Accordingly, the communication protocol context may include the BA protocol context and / or the RSNA confidentiality and integrity protocol context.

[0125] As mentioned above, communication protocols are used to transmit downlink data; therefore, the communication protocol context can also be called the data communication context. In other scenarios, the communication protocol context can be understood as being used to synchronize the transmission status, downlink data, or downlink data transmission parameters between a first device and a second device to improve the continuity of downlink data transmission. Therefore, the communication protocol context can also be called the synchronization information for downlink data transmission.

[0126] In some implementations, if the first device is a non-access point device, the communication protocol context can be understood as the communication protocol context of the non-access point device.

[0127] In some implementations, the communication protocol context is used to indicate one or more of the following: processing status information of downlink data corresponding to the first TID; SN corresponding to the last downlink data in the downlink data corresponding to the first TID that has been submitted to the higher layer; PN corresponding to the last downlink data in the downlink data corresponding to the first TID that has been submitted to the higher layer; control status information of the receive reordering buffer; and scoreboard context control status information corresponding to the downlink data.

[0128] Taking the communication protocol context used to indicate the processing status information of downlink data corresponding to the first TID as an example, in some implementations, the processing status information of downlink data corresponding to the first TID is used to indicate one or more of the following: whether the downlink data corresponding to the first TID has been successfully received; whether the downlink data corresponding to the first TID has been transmitted to a higher layer; whether the receive buffer contains downlink data sent by the first AP device; and whether downlink data from the first AP device is no longer being processed.

[0129] In some implementations, the receive buffer may contain downlink data sent by the first AP device, or in other words, may contain downlink data from the first AP device that has not yet been received.

[0130] In some implementations, whether downlink data from the first AP device is no longer being processed can be understood as whether the downlink data sent by the first AP device has been cleared from the receive buffer. Alternatively, the processing status information of the downlink data corresponding to the first TID is indicated by a second indication message, which states whether downlink data from the first AP device is no longer being processed. This second indication message indicates that the downlink data corresponding to the first TID has been cleared from the receive buffer.

[0131] Taking the communication protocol context as an example to indicate the SN of the last downlink data that has been delivered to the higher layer in the downlink data corresponding to the first TID, the SN can be understood as the SN of the last downlink data packet that has been delivered to the higher layer in the downlink data corresponding to the first TID, or the SN of the latest downlink data packet that has been delivered to the higher layer in the downlink data corresponding to the first TID.

[0132] In some implementations, the above SN can be represented as SN(TID, DL.latest), and correspondingly, for each established downlink block acknowledgment (DL BA) protocol TID, there can be a corresponding SN(TID, DL.latest).

[0133] Taking the communication protocol context as an example to indicate the PN corresponding to the last downlink data in the downlink data corresponding to the first TID that has been delivered to the higher layer, the PN can be understood as the PN of the last downlink data packet in the downlink data corresponding to the first TID that has been delivered to the higher layer, or the PN of the latest downlink data packet in the downlink data corresponding to the first TID that has been delivered to the higher layer.

[0134] In some implementations, the above PN can be represented as PN(TID, DL.latest), and correspondingly, for each TID of an established downlink block acknowledgment (DL BA) protocol, there can be a corresponding PN(TID, DL.latest).

[0135] Taking the control status information of the receive buffer corresponding to the reordered downlink data in the communication protocol context as an example, the control status information of the receive buffer corresponding to the reordered downlink data is also called the "control status information of the receive reordering buffer". The receive reordering buffer can be understood as the receive buffer corresponding to the SN (or the SN of the downlink data packet) of the downlink data to be sent by the second AP device after reordering it.

[0136] In some implementations, the cache control state information includes one or more of the following: a first parameter corresponding to the first TID or the first TA, a second parameter corresponding to the first TID or the first TA, and information about the cache record bitmap corresponding to the reordered downlink data.

[0137] In some implementations, the first parameter (e.g., WinStartB as described above) is used to indicate the SN corresponding to the first downlink data that the non-access point device expects to receive after the downlink data to be transmitted is reordered by the second AP device. For example, the first parameter represents the value of the SN subfield of the first MSDU or A-MSDU (arranged in ascending order of sequence number) that has not yet been received.

[0138] In this embodiment, the first TA can be one or more of the following: the address of the first AP device; the address of the second AP device; the address of the roaming AP MLD, wherein the roaming AP MLD can be the roaming AP MLD associated with the first AP device and the second AP device; the address of the SMD, wherein the SMD can be the address of the SMD associated with the first AP device and the second AP device. Additionally, the addresses mentioned above in this embodiment can be, for example, MAC addresses.

[0139] In some implementations, the second parameter (e.g., WinEndB as described above) is used to indicate the highest SN corresponding to the downlink data expected to be received in the receive window, which is used to receive the downlink data to be transmitted after being reordered by the second AP device.

[0140] In this embodiment, the first TA can be one or more of the following: the address of the first AP device; the address of the second AP device; the address of the roaming AP MLD, wherein the roaming AP MLD can be the roaming AP MLD associated with the first AP device and the second AP device; the address of the SMD, wherein the SMD can be the address of the SMD associated with the first AP device and the second AP device. Additionally, the addresses mentioned above in this embodiment can be, for example, MAC addresses.

[0141] In some implementations, information from a cached record bitmap corresponding to the reordered downlink data is used. For example, the record bitmap is used to record the SN, PN, and reception status of the downlink data packets.

[0142] Taking the communication protocol context as an example to indicate the scoreboard context control status information corresponding to downlink data, in some implementations, the scoreboard context control status information is used to indicate one or more of the following: the third parameter, the fourth parameter, and the bitmap corresponding to each SN in the BA record bitmap of the non-access point device.

[0143] In some implementations, the third parameter is used to indicate the lowest SN recorded in the BA record bitmap of the non-access point device, or in other words, the third parameter represents the lowest sequence number position in the current record bitmap. For example, the third parameter can be the WinStartR parameter described above.

[0144] In some implementations, the fourth parameter is used to indicate the highest SN recorded in the BA record bitmap of the non-access point device, or in other words, the fourth parameter represents the position of the highest sequence number in the current record bitmap. For example, the fourth parameter can be the WinEndR parameter described above.

[0145] In some implementations, the bitmap corresponding to each SN in the BA record bitmap of the aforementioned non-access point device (also called the "BA record bitmap") can refer to a block acknowledgment bitmap maintained by the receiver. This record includes a bitmap indexed by sequence number. The starting sequence number in the bitmap is a 12-bit unsigned integer. For example, this BA record bitmap could be the BA record bitmap corresponding to the generic scoreboard context control maintained by the receiver MLD.

[0146] The communication protocol context of the embodiments of this application has been introduced above. The transmission scheme of the communication protocol context in the embodiments of this application is described below.

[0147] In some implementations, the communication protocol context is carried in one or more of the following: roaming notification frame, roaming request frame, and communication protocol context status notification frame.

[0148] In some implementations, the transmission of the communication protocol context satisfies one or more of the following: it occurs before the transmission of the roaming request frame; it occurs after the transmission of the roaming request frame; it occurs before the transmission of the roaming response frame; or it occurs simultaneously with the transmission of the roaming response frame.

[0149] The first information in the embodiments of this application has been introduced above. The following describes the frame format in which the first information is located in the embodiments of this application. The following section will first introduce the bearer block acknowledgment protocol context element and related field definitions in the embodiments of this application with reference to Figures 5A to 5F. In some implementations, the block acknowledgment protocol context element contains block acknowledgment protocol context or status information that a specific MLD has established and maintained with one or more peer MLDs (Peer MLDs). The block acknowledgment protocol context element mainly includes the block acknowledgment protocol context parameter control subfield and the block acknowledgment protocol context parameter set list subfield, as shown in Figure 5A. The element identifier field, length field, and element identifier extension field in the block acknowledgment protocol context element can adopt the general definitions of elements in the IEEE 802.11 standard, which will not be elaborated here for the sake of brevity.

[0150] In some implementations, the block acknowledgment protocol context parameter control field format is shown in Figure 5B. In some implementations, the MLD MAC address subfield 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.

[0151] In some implementations, the "Whether the peer MLD is the same MLD" subfield indicates whether the peer MLDs targeted by the block confirmation protocol contexts of the MLDs described by the block confirmation protocol context element are the same MLDs. For example, when this field takes the first value, it indicates that the peer MLDs targeted by the block confirmation protocol contexts of the MLDs described by the block confirmation protocol context element are the same MLDs. Conversely, when this field takes the second value, it indicates that the peer MLDs targeted by the block confirmation protocol contexts of the MLDs described by the block confirmation protocol context element are multiple MLDs. The first and second values ​​can be different; for example, the first value can be 0 and the second value can be 1. Or, the second value can be 0 and the first value can be 1.

[0152] In some implementations, the peer MLD MAC address indicates the MAC address of the peer MLD targeted by the block acknowledgment protocol context of the MLD described by the block acknowledgment protocol context element. For example, when the value of the "Whether the peer MLD is the same MLD" subfield indicates that the peer MLD targeted by the block acknowledgment protocol context of the MLD described by the block acknowledgment protocol context element is the same MLD, the peer MLD MAC address subfield exists in the block acknowledgment protocol context parameter control field. Conversely, when the value of the "Whether the peer MLD is the same MLD" subfield indicates that the peer MLD targeted by the block acknowledgment protocol context of the MLD described by the block acknowledgment protocol context element is not the same MLD, the peer MLD MAC address subfield does not exist in the block acknowledgment protocol context parameter control field.

[0153] In some implementations, the number of single block acknowledgment protocol context parameter sets subfields can be 16-bit unsigned integers, indicating the number of single block acknowledgment protocol context parameter set subfields in the block acknowledgment protocol context parameter set list field.

[0154] In some implementations, the Block Acknowledgment Protocol Context Parameter Set List field is shown in Figure 5C. This field consists of one or more individual Block Acknowledgment Protocol Context Parameter Sets and padding subfields.

[0155] In some implementations, the format of a single block acknowledgment protocol context parameter set is shown in Figures 5D and 5E. The MLD role subfield indicates the role played by the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set in the block acknowledgment protocol. When the value of the MLD role subfield is the first value, it indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set plays the role of the initiator MLD in the block acknowledgment protocol. When the value of the MLD role subfield is the second value, it indicates that the MLD containing the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set plays the role of the receiver MLD in the block acknowledgment protocol. The first and second values ​​can be different; for example, the first value can be 0 and the second value can be 1, or the second value can be 0 and the first value can be 1.

[0156] In some implementations, when the MLD containing the block acknowledgment protocol context is initiator mode, the parameter set format for a single block acknowledgment protocol context is shown in Figure 5D. When the MLD containing the block acknowledgment protocol context is receiver mode, the parameter set format for a single block acknowledgment protocol context is shown in Figure 5E.

[0157] In some implementations, the Peer MLD MAC address indicates the MAC address of the peer MLD to which the block acknowledgment protocol context described by a subfield of a single block acknowledgment protocol context parameter set is targeted.

[0158] In some implementations, the block acknowledgment parameter set subfield indicates the set of parameters associated with the established block acknowledgment protocol corresponding to the block acknowledgment protocol context described by the single block acknowledgment protocol context parameter set subfield.

[0159] In some implementations, the block acknowledgment timeout subfield contains a duration in units (TUs). 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.

[0160] In some implementations, the Send Window Start Sequence Number (WinStartO) subfield is a send buffer control parameter that indicates the start sequence number of the send window.

[0161] In some implementations, the transmit window size (WinSizeO) subfield is a transmit buffer control parameter that represents the buffer size of the transmit window negotiated in the block acknowledgment protocol. Specifically, the transmit window size (WinSizeO) subfield indicates the number of buffers available for a given TID. When the A-MSDU supported field is equal to 0 (as shown in the Block Ack Parameter Set field sent by the STA), the number of bytes that each buffer can hold is equal to the maximum MSDU size. When the STA supported A-MSDU field is equal to 1, the number of bytes that each buffer can hold is equal to the maximum A-MSDU size supported by the STA.

[0162] In some implementations, the SN subfield (or subdomain) assigned to the next DL packet indicates the SN to be assigned to the next DL packet for a particular TID (or per TID).

[0163] In some implementations, the SN subfield of the last downlink packet to arrive in the buffer queue indicates the SN of the last downlink packet to arrive in the buffer queue for a particular TID (or per TID) (e.g., the SN of the last packet in the buffer queue when the DS mapping update is complete).

[0164] In some implementations, the highest SN subfield of the currently sent DL packet indicates the latest DL packet SN sent in the source AP MLD (or the highest SN of the DL packet sent in the source AP MLD) for a particular TID (or per TID), or indicates the SN of the last packet sent in a particular TID (or per TID) when it was sent from the source AP MLD to the destination AP MLD (or the highest SN of the DL packet sent).

[0165] In some implementations, the last data unit SN subfield (or subfield) passed to the upper layer indicates the last (or latest) SN of the MPDU and MMPDU that the receiver of the corresponding BA protocol has passed from the receiver's buffer to the upper layer (or DS). This SN can be represented as SN(TID, UL.latest).

[0166] In some implementations, the receive buffer start sequence number (WinStartB) is a receive reordering buffer control parameter that represents the value of the sequence number subfield of the first MSDU or A-MSDU (arranged in ascending order of sequence number) that has not yet been received.

[0167] In some implementations, the receive window size (WinSizeB) is a receive reordering buffer control parameter that indicates the size of the receive window.

[0168] In some implementations, the record bitmap start sequence number (WinStartR) is a Scoreboard Context Control parameter, 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).

[0169] In some implementations, the maximum sequence number of the bitmap (WinEndR) is recorded, representing the highest sequence number of the current transmission window.

[0170] In some implementations, the record bitmap size (WinSizeR) is a Scoreboard Context Control parameter, the maximum transfer window size is set to the smaller of the values ​​of BitmapLength (11ax) and the buffer size field for the relevant ADDBA response frame of the block return protocol.

[0171] In some implementations, the record bitmap subfield indicates the value of a block acknowledgment bitmap currently maintained by the receiver of the corresponding BA protocol that is requesting or completing the migration. This record includes a bitmap indexed by sequence number. Typically, the starting sequence number is a 12-bit unsigned integer.

[0172] In some implementations, one or more of the following are carried in one or more fields in the second field: the PN corresponding to the last downlink data arriving in the buffer queue in the downlink data corresponding to the first TID; the minimum threshold for PN exhaustion associated with the key corresponding to the first TID; and the maximum threshold for PN exhaustion associated with the key corresponding to the first TID. The second field is used to carry parameters for security association.

[0173] The following section, in conjunction with Figures 6A to 6E, describes the Security Association context elements and related domain definitions in the embodiments of this application.

[0174] In some implementations, the security association context element contains the sender PN configuration and PN counter status information, and / or receiver replay detection context and replay counter status information, which are established and maintained with one or more peer MLDs for security association-related data encryption / decryption and / or integrity protection and verification. The security association context element mainly includes a security association context parameter control field and a security association context parameter set list field, as shown in Figure 6A. The element identifier field, length field, and element identifier extension field in the security association context element adopt the general definitions of elements in the IEEE 802.11 standard, which will not be elaborated here for simplicity.

[0175] In some implementations, the format of the security association context parameter control field is shown in Figure 6B. In some implementations, the MLD MAC address subfield 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.

[0176] In some implementations, the "Whether the peer MLD is the same MLD" subfield indicates whether the peer MLDs targeted by the block confirmation protocol contexts of the MLDs described by the block confirmation protocol context element are the same MLDs. For example, when this field takes the first value, it indicates that the peer MLDs targeted by the block confirmation protocol contexts of the MLDs described by the block confirmation protocol context element are the same MLDs. Conversely, when this field takes the second value, it indicates that the peer MLDs targeted by the block confirmation protocol contexts of the MLDs described by the block confirmation protocol context element are multiple MLDs. The first and second values ​​can be different; for example, the first value can be 0 and the second value can be 1. Or, the second value can be 0 and the first value can be 1.

[0177] In some implementations, the peer MLD MAC address indicates the MAC address of the peer MLD to which the security association context of the MLD described by the security association context element targets. For example, when the value of the "Whether the peer MLD is the same MLD" subfield indicates that the peer MLD to which the security association context of the MLD described by the security association context element targets is the same MLD, the peer MLD MAC address subfield exists in the security association context parameter control field. Conversely, when the value of the "Whether the peer MLD is the same MLD" subfield indicates that the peer MLD to which the security association context of the MLD described by the security association context element targets is not the same MLD, the peer MLD MAC address subfield does not exist in the security association context parameter control field.

[0178] In some implementations, the security association context parameter set list field is shown in Figure 6C. This field includes one or more security association context parameter sets and padding subfields.

[0179] In some implementations, the security association context parameter set list field is shown in Figure 6C. This field consists of one or more single block acknowledgment protocol context parameter sets and padding subfields.

[0180] In some implementations, the format of the security association context parameter set is shown in Figures 6D and 6E. The MLD role subfield indicates the role played by the MLD containing the security association context described by the security association context parameter set in the security association protocol. When the value of the MLD role subfield is the first value, it indicates that the MLD containing the security association context described by the security association context parameter set plays the role of the initiator MLD in the security association protocol. When the value of the MLD role subfield is the second value, it indicates that the MLD containing the security association context described by the security association context parameter set plays the role of the receiver MLD in the security association protocol. The first and second values ​​can be different; for example, the first value can be 0 and the second value can be 1, or the second value can be 0 and the first value can be 1.

[0181] In some implementations, when the MLD containing the security association protocol context is the receiver role, the security association context parameter set format is shown in Figure 6D. When the MLD containing the security association protocol context is the sender role, the security association context parameter set format is shown in Figure 6E. The meaning of each field shown in Figures 6D and 6E is explained below.

[0182] In some implementations, the MLD role subfield indicates the role played by the MLD in the security association context described by the security association context parameter set subfield within that security association context. Specifically, when the value of the MLD role subfield is 0, it indicates that the MLD in the security association context described by the security association context parameter set subfield plays the role of a receiver MLD, which describes the receiver's replay scenario parameter set. When the value of the MLD role subfield is 1, it indicates that the MLD in the security association context described by the security association context parameter set subfield plays the role of a sender MLD, which describes the sender's PN counter scenario parameter set.

[0183] In some implementations, the PTKSA / GTKSA / TPKSA subfields indicate the security association type corresponding to the replay scenario described by the replay scenario parameter set subfield, as shown in Table 1. For example, when the PTKSA / GTKSA / TPKSA subfield indicates PTKSA, the replay count value subfield in the replay scenario parameter set subfield corresponds to the PTKSA replay count value.

[0184] Table 1: PTKSA / GTKSA / TPKSA Threshold Values ​​and Their Meanings

[0185] In some implementations, the PN subfield of the last downlink packet arriving in the buffer queue indicates the last assigned PN of the downlink packet arriving in the buffer queue for a specific TID (e.g., the PN assigned to the last packet in the buffer queue when the DS mapping update is completed), where the specific TID is indicated by the corresponding TID subfield.

[0186] In some implementations, the PN threshold maximum value subfield indicates the maximum value of the PN exhaustion threshold in the PN space associated with the relevant key of a specific TID, where the specific TID is indicated by the corresponding TID subfield.

[0187] In some implementations, the minimum PN threshold subfield indicates the minimum PN depletion threshold in the PN space associated with the relevant key of a specific TID, where the specific TID is indicated by the corresponding TID subfield.

[0188] The following describes the format of the communication protocol context notification frame (also known as the data communication context notification frame) in embodiments of this application. In some implementations, the data communication context notification frame is used by the source AP MLD or target AP MLD to notify the roaming non-AP MLD of the migration status of the data communication context. This frame may include one or more of the following: the migration status of the block acknowledgment protocol context of the non-AP MLD that has been migrated, and the migration status of the security association context. Additionally, the data communication context status notification frame can also be used by the roaming non-AP MLD to feed back the current block acknowledgment protocol context information and / or security association context information to the current AP MLD or target AP MLD.

[0189] In some implementations, the data communication context status notification frame can adopt an action frame format, and its action field contains the information shown in Table 2. The category field is defined according to the relevant definitions in the IEEE 802.11 standard. The protected UHR action field contains one byte, immediately following the category field, and is used to distinguish the UHR action frame format. The session token field is set to a non-zero value by the AP MLD of the data communication context information migration status notification frame. The block acknowledgment protocol context element is defined as described above; it carries the block acknowledgment protocol context information or migration status information that has been migrated. The security association context element is defined as described in the separate document; it carries the security association context information or migration status information that has been migrated.

[0190] Table 2: Format of Action Field in Protected Data Communication Context Status Notification Frame

[0191] The communication protocol context in the embodiments of this application has been described above with reference to Embodiments 1 to 3. The following describes the relevant operations performed by the first AP device in the roaming scenario based on the communication protocol context in the embodiments of this application.

[0192] In some implementations, the above method further includes: the first device sending first indication information to the non-access point device, the first indication information being used to indicate whether the first AP device has cached downlink data to be sent to the non-access point device.

[0193] In some implementations, the first indication information is carried in the "more data" subfield of the frame control field. For example, the first access point (AP) device may indicate in the "more data" subfield of the frame control field of a data packet sent to a non-access point device whether the first AP device has cached more buffer units (or downlink data packets) for the roaming non-access point device.

[0194] In this embodiment, the "More Data" subfield is set to a first value, indicating that the first AP device has cached at least one additional cache unit (or downlink data packet) for the non-access point device, meaning the first AP device still has data packets to be transmitted to the access point device. Conversely, the "More Data" subfield is set to a second value, indicating that the first AP device has not cached any additional cache unit (or downlink data packet) for the non-access point device, meaning the first AP device has no data packets to be transmitted to the access point device. The first and second values ​​can be different; for example, the first value can be 0 and the second value can be 1. Alternatively, the first value can be 1 and the second value can be 0.

[0195] In some implementations, the above method further includes: if a first condition is met and the first AP device has downlink data to be sent to the non-access point device in its cache, then the first AP device clears the downlink data, wherein the first condition includes one or more of the following: roaming timeout timer expires (or roaming time expires); link between the first AP device and the non-access point device is deleted; the first AP device sends a roaming response message to the non-access point device.

[0196] In some implementations, if downlink data migration is supported between the first AP device and the second AP device, the method further includes: if the first AP device has buffered downlink data to be sent to a non-access point device, then the first AP device sends the downlink data to the second AP device. This allows the second AP device to subsequently send downlink data to the non-access point device, thereby improving the continuity of downlink data transmission.

[0197] In some implementations, if the first AP device does not receive the buffer control status information after reordering the downlink data to be transmitted, the downlink data includes the downlink data buffered by the first AP device.

[0198] For example, if the first AP device does not receive the control status information of the receive reordering buffer sent by the non-access point device, and there is still a data unit in the receive buffer of the first TID (or per TID) corresponding to the DL BA protocol in the first AP device's transmit buffer, then the first AP device will migrate the data unit to the second AP device.

[0199] In some other implementations, if the first AP device receives the buffer control status information after reordering the downlink data to be transmitted (i.e., the control status information for receiving the reordered buffer described above), the downlink data includes downlink data that the non-access point devices have not received from the downlink data buffered by the first AP device.

[0200] In some implementations, if the first AP device receives the cache control status information, the first AP device deletes the downlink data that the cache control status information indicates has been successfully received by the non-access point device from the transmission cache, and does not migrate the downlink data that the non-access point device has received from the cache of the first AP device to the second AP device, which helps to avoid resource waste caused by repeated transmission of downlink data.

[0201] For example, when the first AP device receives the receive reordering buffer control status information sent by the non-access point device, it can use the following processing method:

[0202] For data units whose corresponding SN position in the bitmap within the range of (WinStartB, WinEndB) sent for a specific TID is 0 (i.e., data units that have not yet been received by the non-access point device), the corresponding data units are migrated to the second AP device.

[0203] For a data unit whose corresponding SN position is 1 in the record bitmap within the range of (WinStartB, WinEndB) sent for a specific TID (i.e., a data unit that has been received by a non-access point device), if the first AP device's transmission buffer still contains the data unit, the first AP device will clear the corresponding data unit and will no longer perform migration.

[0204] In some implementations, if the first AP device receives buffer control status information after reordering the downlink data to be transmitted, the first AP device does not send buffer control status information to the non-access point device to indicate that the non-access point device has successfully received the downlink data, which helps to avoid duplicate transmission of downlink data.

[0205] In some implementations, downlink data successfully received by a non-access point device includes data packets that the non-access point device has successfully received but has not sent a confirmation of receipt to the first access point device.

[0206] The above describes the relevant operations performed by the first AP in the embodiments of this application. The following describes the relevant operations performed by non-access point devices in the roaming scenario based on the communication protocol context in the embodiments of this application.

[0207] In some implementations, the method further includes: before the non-access point device receives the roaming response frame, the non-access point device receives downlink data sent by the first access point device. The roaming response frame can be sent by either the first access point device or the second access point device; this embodiment does not limit the specific type of frame.

[0208] In some implementations, the above method further includes: the non-access point device determining, based on the type of the roaming response frame, whether to not receive downlink data sent by the first AP device or to continue receiving downlink data sent by the first AP device before the roaming timer expires.

[0209] In some implementations, if the roaming response frame is a reassociation response frame, the non-access point device does not receive downlink data sent by the first access point device, wherein the reassociation response frame is used to indicate that the non-access point device has successfully reassociated with the second access point; and / or if the roaming response frame is a link reconfiguration frame, the non-access point device continues to receive downlink data sent by the first access point device before the roaming timer expires, wherein the link reconfiguration frame is used to indicate that the link between the non-access point device and the second access point has been successfully established.

[0210] In some implementations, the above method further includes: the non-access point device determining whether to delete the link between the non-access point device and the first AP device based on the downlink data reception status.

[0211] In some implementations, if the downlink data reception status indicates that the last downlink data sent by the first AP device and the downlink data transmitted before the last downlink data have been successfully received, then the non-access point device deletes the link between the non-access point device and the first AP device.

[0212] In some implementations, if the downlink data reception status indicates that the last downlink data sent by the first AP device and the downlink data transmitted before the roaming timeout timer expires (or the roaming time expires), the non-access point device deletes the link between the non-access point device and the first AP device.

[0213] In some implementations, the transmission key for the downlink data corresponding to the link between the non-access point device and the first AP device is the same as the transmission key for the downlink data corresponding to the link between the non-access point device and the second AP device. The method further includes: after the non-access point device receives the roaming response frame and before the link between the non-access point device and the first AP device is deleted, the non-access point device receives downlink data sent by the first AP device and / or the second AP device based on the transmission key.

[0214] In some implementations, the transmission key for the downlink data corresponding to the link between the non-access point device and the first AP device is different from the transmission key for the downlink data corresponding to the link between the non-access point device and the second AP device. The above method also includes: after the non-access point device receives the roaming response frame, the non-access point device receives the downlink data sent by the second AP device based on the transmission key for the downlink data corresponding to the link between the non-access point device and the second AP device.

[0215] In some implementations, if the migration of downlink data between the first AP device and the second AP device is not supported, the above method further includes: if the SN corresponding to the downlink data corresponding to the first TID cached in the receive buffer of the non-access point device is less than the target SN, then the non-access point device clears all downlink data corresponding to the first TID in the receive buffer, wherein the target SN is the highest SN corresponding to the downlink data corresponding to the first TID sent by the first AP device.

[0216] For ease of understanding, the implementation method of transmitting the first information in the embodiments of this application is described below with reference to Figures 7A to 10. Figures 7A and 7B are schematic diagrams of the wireless roaming process in the embodiments of this application. Figures 7A and 7B use a non-AP STA, a source AP, and a target AP as examples. It should be understood that the non-AP STA can be the non-AP MLD described above, and the source AP and target AP can be the AP MLD described above. The method shown in Figure 7A includes steps S710 to S726.

[0217] In step S710, the non-AP STA sends roaming notification frame 1 to the source AP.

[0218] In some implementations, when a non-AP STA decides to initiate roaming, it can first send a roaming notification frame 1 to the source AP to notify the non-AP STA to request roaming.

[0219] In some implementations, the roaming notification frame 1 may carry candidate target AP information so that the source AP can select a target AP from the candidate target APs after successfully receiving the roaming notification frame. It should be understood that in this embodiment, the roaming notification frame 1 may also be sent to the target AP; in this case, the roaming notification frame 1 may not carry the candidate target AP information. For ease of description, the following description uses the example of the roaming notification frame 1 being sent to the source AP.

[0220] In step S712, the source AP sends roaming notification frame 2 to the non-AP STA.

[0221] In some implementations, the roaming notification frame 2 carries one or more of the following: the data communication context of the downlink data of the non-AP STA, information about the target AP, and parameters such as the timeout period for initiating the roaming request.

[0222] In step S714, the source AP sends the data communication context for downlink data to the target AP for the non-AP STA. For a related introduction to the communication context, please refer to the introduction to the communication protocol context above.

[0223] In step S716, the non-AP STA sends a roaming request frame to the source AP to request roaming from the source AP to the target AP.

[0224] In some implementations, the aforementioned roaming request frame can be sent from a non-AP STA to the current AP. The current AP refers to the AP associated with the non-AP STA when initiating the roaming request, and the current AP refers to the AP MLD with which the non-AP STA has established a multi-link when initiating the roaming request. The current AP can be a source AP (see step S716) or a target AP. The target AP refers to the AP or AP MLD that the non-AP STA requests to associate with or establish a multi-link during roaming. For ease of description, the following section uses sending a roaming request frame to the source AP as an example.

[0225] In step S718, the source AP migrates the downlink data of the non-AP STA to the target AP.

[0226] In step S720, the source AP sends a data communication context notification frame 1 to the non-AP STA to indicate the data communication context of the downlink data. The frame format of the data communication context notification frame 1 can be found in the preceding description.

[0227] In some implementations, the data communication context notification frame 1 is used to indicate the status of the sender of downlink data.

[0228] It should be noted that, in the embodiments of this application, the aforementioned data communication context notification frame 1 can be sent from the source AP to the target AP, and then sent by the target AP to the non-AP STA through the source AP.

[0229] In step S722, the non-AP STA sends a data communication context notification frame 2 from the source AP to the target AP to indicate the data communication context of the downlink data. The frame format of the data communication context notification frame 2 can be found in the preceding description.

[0230] In some implementations, the data communication context notification frame 2 is used to indicate the receiver status of downlink data.

[0231] It should be noted that in some implementations, after sending a roaming notification frame or a roaming request frame, a non-AP STA can also receive downlink data sent by the source AP to reduce the latency of downlink data transmission.

[0232] In step S724, the source AP sends a roaming response frame to the non-AP STA.

[0233] In some implementations, the roaming response frame may carry migration status information indicating whether the data communication context of the downlink data has been successfully migrated from the source AP to the target AP.

[0234] In some implementations, the source AP can send a roaming response frame to the non-AP STA based on the status of the non-AP STA's roaming process.

[0235] In some implementations, the roaming response frame indicates that the target AP is ready to send a Class 3 frame to the non-AP STA. When the non-AP STA receives the roaming response frame, it can receive the Class 3 frame sent from the target AP STA.

[0236] In some implementations, when a non-AP STA receives a roaming response frame, it can determine, based on the type of the roaming response frame, whether to stop receiving downlink data sent by the source AP, or to continue receiving downlink data sent by the source AP for a specific period of time (e.g., before the roaming timeout expires).

[0237] For example, if the roaming response frame is a reassociation response frame, and the reassociation response frame indicates that the non-AP STA has successfully reassociated with the target AP, then the non-AP STA disassociates with the source AP and no longer receives downlink data sent by AP MLD1. As another example, if the roaming response frame is a link reconfiguration frame, and this link reconfiguration frame indicates that the non-AP STA has successfully established a link with the target AP, then the non-AP STA can still receive downlink data sent by the source AP for a specific period (e.g., before the roaming timeout expires), until the link with the source AP is deleted (or disabled) or the roaming timeout expires. Of course, in this embodiment, if the roaming response frame is a link reconfiguration frame, the non-AP STA can also directly delete or disable the established link with AP MLD1.

[0238] In addition, a non-AP STA cannot receive downlink data sent by the target AP until it receives a roaming response frame. Conversely, if a non-AP STA successfully receives a roaming response frame indicating that it has successfully roamed to the target AP, then the non-AP STA can receive downlink data sent by the target AP.

[0239] In step S726, the non-AP STA deletes or deactivates the downlink with the source AP.

[0240] The following describes the actions performed by the source AP or target AP before step S724 shown in Figure 7A, i.e., during the roaming preparation period when the non-AP STA determines whether to roam from the source AP to the target AP, or after the non-AP STA initiates roaming from the source AP to the target AP (e.g., when the source AP / target AP receives a roaming notification frame or a roaming request frame). It should be understood that this application embodiment does not limit the specific step in which the related operations described below are performed.

[0241] In Operation 1, the source AP or the target AP can initiate and execute the DS mapping update process to determine the SN of the last downlink data packet that arrives in the buffer queue in the downlink data packets corresponding to the first TID (or each TID). The last downlink data packet that arrives in the buffer queue can be, for example, the last downlink data packet in the buffer queue when the DS mapping update is completed.

[0242] In operation 2, the source AP or the target AP reports back to the non-AP STA whether packet migration via DS is supported.

[0243] In operation 3, the source AP or the target AP can provide feedback to the non-AP STA on whether the PTK has been updated after the non-AP STA roams to the target AP. In other words, the source AP or the target AP can provide feedback to the non-AP STA on whether the PTK after the non-AP STA roams to the target AP is the same as the PTK used by the non-AP STA when communicating with the source AP.

[0244] In operation 4, within a specific time period (e.g., the transmission duration of downlink data packets or the time period corresponding to the roaming timeout timer), the source AP transmits the data units to be transmitted in the transmission buffer based on a first rule. This first rule indicates that downlink data that has not been transmitted or has not been successfully transmitted (e.g., no ACK confirmation has been received) has a higher priority than successfully transmitted downlink data. Furthermore, the downlink data that has not been transmitted or has not been successfully transmitted is transmitted in ascending order of its sequence number. In other words, downlink data with earlier sequence numbers that has not been transmitted or has not been successfully transmitted (e.g., no ACK confirmation has been received) is transmitted first.

[0245] In operation 5, the source AP sends downlink data packets to the non-AP STA, and in the frame control field of the downlink data packet, the "More data" subfield indicates that the source AP has buffered more downlink data (also known as buffer units) for the non-AP STA. For example, setting the More data subfield to 1 indicates that the source AP has buffered at least one downlink data to be transmitted to the non-AP STA, that is, the source AP still has downlink data to be transmitted to the non-AP STA.

[0246] In Operation 6, during roaming (i.e., within the roaming timeout period), if downlink data reception or processing from the first TID (or per TID) in the source AP is completed, then before the roaming timeout, the source AP or target AP initiates or starts disabling (or deletes) the link between the non-AP STA and the source AP, or the source AP or target AP disconnects the association between the non-AP STA and the source AP. Compared to the traditional scheme where the link between the non-AP STA and the source AP is disabled (or deleted) only after the roaming timeout, this helps to release the radio resources between the non-AP STA and the source AP in a timely manner and improve the utilization rate of radio resources between the non-AP STA and the source AP.

[0247] In operation 7, the source AP or the target AP can initiate the migration process of the data communication context from the source AP to the target AP. During or after the data communication context migration, the source AP or the target AP will report the data communication context that has been migrated and / or the migration status of the data communication context to the non-AP STA. The migration status is used to indicate whether the data communication context has been successfully migrated from the source AP to the target AP.

[0248] In some implementations, for the Block Ack protocol of downlink packet transmission, the data communication context is used to indicate one or more of the following:

[0249] The SN to be assigned to the next downlink packet of the first TID (or per TID);

[0250] The SN of the last downlink packet that arrives in the buffer queue in the downlink packets corresponding to the first TID (or per TID) (e.g., the last packet in the buffer queue when the DS mapping update is completed);

[0251] The SN of the latest downlink data packet sent by the source AP in the downlink data packet corresponding to the first TID (or per TID), or the highest SN among the downlink data packets sent by the source AP;

[0252] The data communication context is the serial number (SN) of the last downlink data packet sent in the downlink data corresponding to the first TID (or per TID) when the source AP sends the data to the target AP.

[0253] The control status information of the transmit buffer for the first TID (or per TID), wherein the control status information indicates one or more of the following: the starting sequence number of the transmit window (or transmit buffer) (denoted as "WinStart0"), the buffer size or number negotiated in the block acknowledgment protocol (denoted as "WinSize0"), and status information on whether each data packet in the transmit window has been successfully transmitted.

[0254] The last allocated PN in the PN corresponding to the downlink data packet in the arrival buffer queue for the first TID (or per TID), for example, the PN allocated to the last data packet in the buffer queue when the DS mapping update is completed;

[0255] The maximum and minimum values ​​of the PN threshold that is about to be exhausted for the PN associated with the corresponding key of the first TID (or per TID);

[0256] The migration status of downlink packets migrating from the source AP to the target AP, which indicates whether the downlink packets have been successfully migrated from the source AP to the target AP.

[0257] In operation 8, when both the source AP and the target AP support downlink packet migration via DS, the source AP copies or migrates downlink data whose SN is between SN(TID, DL, AP1, TX-latest)+1 and SN(TID, DL, AP1, DS-latest). Here, SN(TID, DL, AP1, DS-latest) represents the SN of the last downlink packet arriving in the buffer queue for the first TID, for example, the SN of the last downlink packet in the buffer queue when the DS mapping update is complete. SN(TID, DL, AP1, TX-latest)+1 represents the SN of the latest downlink packet sent by the source AP in the buffer corresponding to the first TID, or in other words, the highest SN among the SNs corresponding to the downlink packets for the first TID sent by the source AP.

[0258] The previous section described the operations performed by the source AP or target AP during the roaming preparation period when a non-AP STA determines whether to roam from the source AP to the target AP, or after the non-AP STA initiates roaming from the source AP to the target AP. The following section describes the operations performed by the source AP or target AP after the source AP stops sending downlink data to the non-AP STA. It should be understood that the source AP stopping sending downlink data to the non-AP STA can be triggered by one or more of the following: the source AP or target AP successfully sends a roaming response frame to the non-AP STA, deletes or disables the link between the non-AP STA and the source AP, or the roaming timeout timer expires.

[0259] In some implementations, if the source AP and the target AP do not support data packets being migrated via DS, and the source AP's transmit buffer also contains downlink data packets in the receive buffer corresponding to the first TID (or per TID) of the DL BA protocol, then the downlink data packets are cleared.

[0260] In other implementations, when both the source AP and the destination AP support packet migration via DS, the source AP and the destination AP can perform one of the following operations:

[0261] If the source AP's transmit buffer contains downlink data packets from the first TID (or per TID) of the DL BA protocol, then clear those downlink data packets.

[0262] If the source AP's transmit buffer contains downlink data from the first TID (or per TID) of the DL BA protocol, then that downlink data is migrated to the target AP.

[0263] In some implementations, if the source AP does not receive the receive reordering buffer control status information sent by the non-AP STA, and the source AP's transmit buffer still contains downlink data in the receive buffer of the first TID (or per TID) corresponding to the DL BA protocol, then the source AP migrates the downlink data to the target AP.

[0264] For example, if the source AP does not receive the control status information of the receive reordering buffer sent by the non-AP STA, and the source AP's transmit buffer still contains downlink data in the receive buffer of the first TID (or per TID) corresponding to the DL BA protocol, then the source AP will migrate the downlink data to the target AP.

[0265] For example, when the source AP receives the receive reordering buffer control status information sent by the non-AP STA, the source AP can perform one or more of the following operations: For downlink data where the SN corresponding position is 0 in the record bitmap within the range of (WinStartB, WinEndB) fed back for the first TID (i.e., downlink data that the receiver has not yet received), the source AP can migrate this downlink data to the target AP. And / or, for downlink data where the SN corresponding position is 1 in the record bitmap within the range of (WinStartB, WinEndB) fed back for the first TID (i.e., downlink data that the receiver has already received), if this downlink data exists in the buffer, the source AP can clear the corresponding downlink data and no longer migrate the downlink data.

[0266] The above describes the operations performed by the source AP and / or target AP in the scheme shown in Figure 7A. The following describes the related operations performed by the non AP STA in the scheme shown in Figure 7A.

[0267] In some implementations, after successfully sending a roaming request frame and before receiving a roaming response frame (i.e., between steps S716 and S724), the non-AP STA may perform one or more of the following operations.

[0268] In some implementations, the non-AP STA can determine whether to delete (or disable) the link between the non-AP STA and the source AP before the roaming timeout, or in other words, stop receiving downlink data from the source AP, based on the SN corresponding to the latest downlink data sent by the source AP for the first TID (or per TID), and the reception status of downlink data sent before that SN.

[0269] For example, when the SN corresponding to the latest downlink data sent by the source AP in the first TID and all downlink data before that SN have been received or processed, the non-AP STA can delete (or disable) the link between the non-AP STA and the source AP before the roaming time expires, or the non-AP STA can initiate a process to delete (or disable) the link between the non-AP STA and the source AP before the roaming time expires.

[0270] In some implementations, after deleting (or disabling) the link between the non-AP STA and the source AP, and establishing the link between the non-AP STA and the target AP, the non-AP STA determines the control parameters (e.g., WinStartB, WinSizeB) of the receive reordering buffer for the first TID (or per TID) corresponding to the DL BA protocol as the receiver, and / or the control parameters (e.g., WinStartR, WinSizeR) of the scoreboard context.

[0271] In some implementations, the non-AP STA can update the frame based on the control status parameters of the receive reordering buffer fed back by the target AP, and update the WinStartB and WinStartR parameters corresponding to the DL BA protocol of the non-AP STA as the receiver.

[0272] In some implementations, the communication protocol context of downlink data sent by a non-AP STA to the AP MLD is used to indicate one or more of the following:

[0273] The processing status information of downlink data from the first TID (or each TID) of the source AP, which indicates whether all data packets from the source AP have been received; whether all data packets from the source AP have been transmitted to the upper layer; whether there are still data packets from the source AP in the receive buffer (or whether there are still unreceived data packets from the source AP in the receive buffer); whether the receive buffer has been cleared of data packets from the source AP, i.e., no longer receiving (or processing) data packets from the source AP;

[0274] The SN corresponding to the last (or latest) downlink data that has been transmitted to the upper layer (or higher layer) in the first TID (or each TID) is denoted as SN(TID, DL.latest). For each TID with established downlink block acknowledgment (DL BA) protocol, there is a corresponding SN(TID, DL.latest).

[0275] The PN of the last (or latest) downlink data that has been transmitted to the upper layer in the first TID (or each TID) is denoted as PN(TID, UL.latest). For each TID with an established UL BA protocol, there is a corresponding PN(TID, UL.latest).

[0276] The control status information of the receive reordering buffer is used to indicate the current WinStartB parameter value of each TID, representing the value of the SN subfield of the first MSDU or A-MSDU (arranged in ascending order of sequence number) that has not yet been received. For example, the control status information is used to indicate the current WinEndB parameter value of each TID, representing the highest sequence number expected to be received in the current receive window. For example, the control status information is used to indicate the current receive reordering buffer record bitmap value.

[0277] The scoreboard context control status information includes common scoreboard context control information maintained by MLD. This common scoreboard context control information indicates one or more of the following: BA record bitmap parameter WinStartR, BA record bitmap parameter WinEndR, and BA record bitmap value. WinStartR represents the lowest sequence number position in the current record bitmap, and WinEndR represents the highest sequence number position in the current record bitmap.

[0278] In some implementations, the BA record bitmap is a block acknowledgment record maintained by the receiver. This record includes a bitmap indexed by sequence number, starting with a 12-bit unsigned integer. Specifically, this BA record bitmap is the BA record bitmap corresponding to the generic scoreboard context control maintained by the receiving MLD.

[0279] In some implementations, after receiving a roaming response frame, the Non-AP STA can perform one or more of operations 1 to 3.

[0280] Operation 1: If the PTK is not updated (i.e., the PTK used by the link between the non-AP STA and the target AP is the same as the PTK used by the link between the non-AP STA and the source AP), then before the link between the non-AP STA and the source AP is deleted or disabled, the non-AP STA can simultaneously receive downlink data from both the source AP and the target AP, and use the aforementioned PTK to decrypt individually addressed downlink data received on any link. Furthermore, after the link between the non-AP STA and the source AP is deleted or disabled, the non-AP STA only receives downlink data from the target AP.

[0281] Operation 2: After disabling or deleting the link between the non-AP STA and the source AP, and establishing the link between the non-AP STA and the source AP, the non-AP STA determines the receive reordering buffer control parameters WinStartB, WinSizeB, and / or scoreboard context control parameters WinStartR, WinSizeR for the first TID (or per TID) corresponding to the DL BA protocol as the receiver. Of course, in this embodiment, the non-AP STA can also update the parameters WinStartB and WinStartR corresponding to the DL BA protocol as the receiver based on the receive reordering buffer control status parameter information updated by the target AP.

[0282] Operation 3: If the PTK is updated (i.e., the PTK used in the link between the non-AP STA and the target AP is different from the PTK used in the link between the non-AP STA and the source AP), the non-AP STA, upon receiving the roaming response frame, completes the processing of the downlink data from the source AP in its receive buffer. This processing for the source AP includes sending the buffered downlink data to a higher layer or clearing the downlink data. Of course, in this embodiment, the non-AP STA may only receive downlink data from the target AP and use the new PTK to decrypt the separately addressed downlink data from the target AP.

[0283] It should be noted that the above description uses downlink data corresponding to the first TID. In this embodiment, the downlink data can also be downlink data for the TA. In this embodiment, the TA is not limited. In some implementations, the TA can be one or more of the following: the TA of the source AP, the TA of the target AP, the TA of the roaming AP MLD (e.g., the roaming AP MLD to which the source AP and the target AP belong), and the TA of the seamless mobility domain SMD (e.g., the SMD to which the source AP and the target AP belong). The TA can be, for example, a MAC address.

[0284] Additionally, it should be noted that in the embodiments of this application, the first TID can be one of the TIDs corresponding to the downlink data of the non-AP STA, or the first TID can be multiple TIDs corresponding to the downlink data of the non-AP STA. This application embodiment does not limit this. Furthermore, in the embodiments of this application, downlink data can be understood as separately addressed QoS data frames or QoS Null frames sent to the non-AP STA.

[0285] It should be noted that Figure 7A illustrates the case where the data communication context notification frame is transmitted before the roaming request frame. In other scenarios, the data communication context notification frame can be transmitted after the roaming request frame. The following description uses Figure 7B as an example. It should be noted that the operations performed by the relevant devices in Figure 7B and the information carried in each frame can be found in Figure 7A. The following mainly describes the differences in the execution order of the steps. The method shown in Figure 7B includes steps S730 to S746.

[0286] In step S730, the non-AP STA sends roaming notification frame 1 to the source AP.

[0287] In step S732, the source AP sends roaming notification frame 2 to the non-AP STA.

[0288] In step S734, the source AP sends the data communication context for downlink data to the target AP for the non-AP STA. For a related introduction to the communication context, please refer to the introduction to the communication protocol context above.

[0289] In step S736, the source AP migrates the downlink data of the non-AP STA to the target AP.

[0290] In step S738, the source AP sends a data communication context notification frame 1 to the non-AP STA to indicate the data communication context of the downlink data. The frame format of the data communication context notification frame 1 can be found in the preceding description.

[0291] In step S740, the non-AP STA sends a data communication context notification frame 2 from the source AP to the target AP to indicate the data communication context of the downlink data. The frame format of the data communication context notification frame 2 can be found in the preceding description.

[0292] In step S742, the non-AP STA sends a roaming request frame to the source AP to request roaming from the source AP to the target AP.

[0293] In step S744, the source AP sends a roaming response frame to the non-AP STA.

[0294] In step S746, the non-AP STA deletes or deactivates the downlink with the source AP.

[0295] Figure 8 is a schematic diagram of synchronization based on the communication protocol context according to an embodiment of this application. Figure 8 can be used in conjunction with the method flow shown in Figure 7A or Figure 7B. For simplicity, the method flow shown in Figure 7A or Figure 7B will not be described again below; the main focus will be on the synchronization scheme based on the communication protocol context. Of course, in this embodiment, it can be used in conjunction with method flows for other roaming scenarios.

[0296] In addition, this embodiment of the application takes the non-access point device as a non-AP MLD, the source AP as AP MLD1, the target AP as AP MLD2, and the downlink data as a data packet as an example for introduction.

[0297] Suppose a non-AP MLD roams from the current AP MLD1 to AP MLD2, and the AP MLD (AP MLD1 or AP MLD2) can be set with a roaming timeout, where the roaming timeout is greater than or equal to the timeout for the non-AP MLD to receive data packets from AP MLD1.

[0298] In some implementations, during non-AP MLD roaming, AP MLD1 copies or migrates the communication protocol context associated with that non-AP MLD to AP MLD2. Specifically, for the Block Ack protocol in downlink packet transmission, the communication protocol context includes one or more of the following: the last packet SN (denoted as SN(AP MLD1, TID, DL.latest)) to arrive in the buffer queue for a specific TID (or per TID) in AP MLD1 in the downlink direction; and the transmission status of downlink packets buffered by AP MLD1 for a specific TID (or per TID) in the non-AP MLD.

[0299] In some implementations, during non-AP MLD roaming, AP MLD1 or AP MLD2 may feed back one or more of the following to the non-AP MLD: SN(AP MLD1, TID, DL.latest); the transmission status of downlink packets for a specific TID (or per TID) cached by AP MLD1 for the non-AP MLD (represented as state(AP MLD1, DL, TID)).

[0300] In some implementations, during roaming, i.e. within the roaming timeout period, if the reception or processing of a downlink data packet from a specific TID (or per TID) in AP MLD1 is completed, the link between the non-AP MLD and AP MLD1 can be disabled (or deleted) ahead of schedule, or the association between the non-AP MLD and AP MLD1 can be terminated.

[0301] In some implementations, AP MLD1 or AP MLD2 may provide feedback to the non-AP MLD on whether packet migration via the distributed system DS (over-the-DS) is supported, the SN of the last packet arriving in the buffer queue in the downlink direction for a specific TID (or per TID) in AP MLD1, and / or the SN of the latest packet sent by AP MLD1 for a specific TID (or per TID).

[0302] It should be noted that if packet migration via DS is not supported, the AP MLD (AP MLD1 or AP ML2) can determine whether the downlink packets for a specific TID (or per TID) sent by AP MLD1 to the non-AP MLD have been completed, and / or whether to initiate (or execute) the disabling (or deletion) of the link between the non-AP MLD and AP MLD1 in advance (i.e., stop receiving downlink packets from AP MLD1) based on the last packet SN that arrives in the buffer queue in the downlink direction for a specific TID (or per TID) in AP MLD1, as well as the transmission status of packets before (and including) that SN.

[0303] Conversely, if packet migration via DS is supported, AP MLD1 can determine, based on the latest downlink packet SN (or the highest SN of downlink packets sent by AP MLD1) in a specific TID (or per TID), and the transmission status of packets before (including) that SN, whether the downlink packets sent by AP MLD1 to non-AP MLD for a specific TID (or per TID) have been completed, and / or whether to prematurely initiate (or execute) the disabling (or deletion) of the link between non-AP MLD and AP MLD1 (i.e., stop receiving downlink packets from AP MLD1).

[0304] In some implementations, before disabling (or deleting) the link between non-AP MLD and AP MLD1 (i.e., stopping the reception of downlink data packets from AP MLD1), non-AP MLD feeds back to AP MLD the reception (or processing) status information of downlink data packets from AP MLD1 for a specific TID (or per TID), and / or determines whether to initiate (or execute) disabling (or deleting) the link between non-AP MLD and AP MLD1 in advance (i.e., stopping the reception of downlink data packets from AP MLD1).

[0305] In some implementations, AP MLD1 or AP MLD2 can feed back the receive reordering buffer control status parameter update information for a specific TID (or per TID) based on the transmit buffer control status information for a specific TID (or per TID) after the migration is completed.

[0306] In some implementations, during roaming, specifically within the roaming timeout period, the information fed back by the non-AP MLD to AP MLD1 for the block acknowledgment protocol of downlink data packet transmission includes one or more of the following: reception (or processing) status information of downlink data packets from AP MLD1 for a specific TID (or per TID), i.e., control status information of the receive reordering buffer. For example, the control status information carries one or more of the following: the current WinStartB parameter value for each TA / TID; the current parameter WinEndB for each TA / TID; and the current receive reordering buffer record bitmap value. Here, the current parameter WinEndB represents the highest sequence number expected to be received in the current receive window. Accordingly, after AP MLD1 receives the control status information of the receive reordering buffer, the processing methods that can be adopted include: for data units whose corresponding SN position is 1 in the record bitmap within the range of (WinStartB, WinEndB) sent for a specific TID (i.e., data units that have been received by the receiver), if the AP MLD1 buffer still has the data unit, then the corresponding data unit is cleared and no longer sent, which helps to avoid AP MLD1 retransmitting downlink data packets that have already been received by non-AP MLD.

[0307] In some implementations, when the roaming timeout period is reached, even if AP MLD1 still has downlink data packets with a specific TID (or per TID) to be transmitted to the non-AP MLD, the link between the non-AP MLD and AP MLD1 is not enabled (or deleted) (i.e., downlink data packets from AP MLD1 are stopped being received). Accordingly, the non-AP MLD processes the receive buffer status and downlink data based on the feedback information.

[0308] For example, assuming that packet transmission or migration from AP MLD1 to AP MLD2 is not supported, the synchronization scheme of the communication protocol context between AP MLD1, AP MLD2, and non-AP MLD is shown in Figure 8. For AP MLD1, the transmit buffer control parameters WinStartO and WinSizeO are 100+M. When the DS mapping update is completed, the PN of the last packet in the buffer queue is N, and the SN is 100+N. When the communication protocol context is transferred to AP MLD2, the PN of the last packet sent by AP MLD1 is L, and the SN is 100+L, where L is a positive integer less than N, and M is a positive integer less than N.

[0309] Accordingly, AP MLD1 or AP MLD2 may send feedback information to the non-AP MLD to indicate one or more of the following: SN(AP MLD1, TID, DL.latest); downlink packets that have not been sent in a specific TID (or per TID) cached by the non-AP MLD; and packet migration via DS is not supported. Accordingly, the non-AP MLD performs one or more of processing methods 1 to 3 based on the feedback information.

[0310] Processing Method 1: After receiving SN(AP MLD1, TID, DL.latest), if a data packet with SN less than or equal to SN(AP MLD1, TID, DL.latest) exists in the receive buffer of the corresponding TA / TID but failed to reach the upper layer, the non-AP MLD discards or clears the data unit. Referring to Figure 8, if SN(AP MLD1, TID, DL.latest) is 100+L, then data units with SN 103 and SN 104 are data packets less than or equal to SN(AP MLD1, TID, DL.latest) that failed to reach the upper layer. In this case, the non-AP MLD clears the data units with SN 103 and 104.

[0311] Processing Method 2: Update the status and control parameters of the non-AP MLD receive reordering buffer. As shown in Figure 8, set WinStartB to SN(AP MLD1, TID, DL.latest)+1, and correspondingly set WinEndB to WinStartB+WinSizeB-1, so that the range of SNs corresponding to downlink data in AP MLD2 does not overlap with the range of SNs corresponding to downlink data in AP MLD1.

[0312] Processing Method 3: Update the scoreboard control parameters for non-AP MLD. As shown in Figure 8, set WinStartR to SN(AP MLD1, TID, DL.latest) + 1, and correspondingly set WinEndR to WinStartR + WinSizeR - 1, so that the range of SNs corresponding to downlink data in AP MLD2 does not overlap with the range of SNs corresponding to downlink data in AP MLD1.

[0313] It should be noted that, in this embodiment, the SN and / or PN corresponding to the downlink data can be reordered, which helps to ensure that the range of SNs corresponding to the downlink data in AP MLD2 does not overlap with the range of SNs corresponding to the downlink data in AP MLD1. Referring again to Figure 8, after reordering the downlink data packet with SN 100+N+1, the SN of the downlink data packet is 0 and the PN is N+1. After reordering the downlink data packet with SN 100+N+2, the SN of the downlink data packet is 2 and the PN is N+2. After reordering the downlink data packet with SN 100+N+3, the SN of the downlink data packet is 2 and the PN is N+3. After reordering the downlink data packet with SN 100+N+4, the SN of the downlink data packet is 3 and the PN is N+4.

[0314] For example, assuming packet transmission or migration from AP MLD1 to AP MLD2 is supported, the synchronization scheme of the communication protocol context between AP MLD1, AP MLD2, and non-AP MLDs is shown in Figure 8. For AP MLD1, the transmit buffer control parameters WinStartO and WinSizeO are 100+M. When the DS mapping update is completed, the PN of the last packet in the buffer queue is N, and the SN is 100+N. When the communication protocol context is transferred to AP MLD2, the PN of the last packet sent by AP MLD1 is L, and the SN is 100+L, where L is a positive integer less than N, and M is a positive integer less than N.

[0315] Accordingly, AP MLD1 or AP MLD2 can send feedback information to the non-AP MLD to indicate support for packet migration via DS. Before disabling (or deleting) the link between the non-AP MLD and AP MLD1 (i.e., stopping the reception of downlink packets from AP MLD1), the non-AP MLD can send feedback to the AP MLD on the reception (or processing) status information of downlink packets from AP MLD1 for a specific TID (or per TID).

[0316] In some implementations, AP MLD1 or AP MLD2 can feed back the receive reordering buffer control status parameter update information for a specific TID (or per TID) based on the transmit buffer control status information for a specific TID (or per TID) after the migration is completed.

[0317] In some implementations, for the block acknowledgment protocol of downlink packet transmission, the information fed back by the non-AP MLD to AP MLD1 includes: the reception or processing status information of downlink packets from AP MLD1 for a specific TID (or per TID), i.e., receive reordering buffer control status information. The receive reordering buffer control status information indicates the current WinStartB parameter value, the current WinEndB parameter value, and the current receive reordering buffer record bitmap value for each TA / TID.

[0318] In some implementations, AP MLD1 performs processing method 1 and / or processing method 2 based on the information fed back by non-AP MLD.

[0319] Processing Method 1: For data units whose corresponding SN position in the record bitmap within the range of (WinStartB, WinEndB) sent for a specific TID is 0 (i.e., data units that the receiver has not yet received), migrate the corresponding data unit to AP MLD2. For example, as shown in Figure 8, the reception status (Rx status) of the data unit with SN 102 indicates that the data unit is a data unit that the receiver has not yet received. In this case, data unit 102 can be migrated to AP MLD2.

[0320] Processing Method 2: For data units whose corresponding SN position in the record bitmap within the range of (WinStartB, WinEndB) sent for a specific TID is 1 (i.e., data units already received by the receiver), if the buffer still contains such data units, the corresponding data units are cleared and no further migration is performed. For example, as shown in Figure 8, the receive status (Rx status) corresponding to the data unit with SN 103 indicates that the data unit has been received by the receiver, but the send status (Tx status) corresponding to the data unit with SN 103 indicates that the data unit has not received block acknowledgment by the sender. In this case, data unit 103 can be cleared and no further migration is performed, which helps to prevent AP MLD1 from retransmitting downlink data packets already received by non-AP MLD.

[0321] In some implementations, AP MLD2 can send a receive reordering buffer control status parameter update frame to non-AP MLD based on the updated transmit buffer control status information, updating the WinStartB and WinStartR parameters of the DL BA protocol corresponding to the non-AP MLD as the receiver. The format can be found in the current specification (9.6.4.5 PBAC WinStart Update frame format).

[0322] In this embodiment, the SN and / or PN corresponding to the downlink data can be reordered, which helps to ensure that the range of SNs corresponding to the downlink data in AP MLD2 does not overlap with the range of SNs corresponding to the downlink data in AP MLD1. Referring again to Figure 8, after reordering the downlink data packet with SN 100+N+1, the SN of the downlink data packet is 0 and the PN is N+1. After reordering the downlink data packet with SN 100+N+2, the SN of the downlink data packet is 2 and the PN is N+2. After reordering the downlink data packet with SN 100+N+3, the SN of the downlink data packet is 2 and the PN is N+3. After reordering the downlink data packet with SN 100+N+4, the SN of the downlink data packet is 3 and the PN is N+4.

[0323] For example, during non-AP MLD roaming, the synchronization scheme of the communication protocol context between AP MLD1, AP MLD2, and the non-AP MLD is shown in Figure 8. For AP MLD1, the transmit buffer control parameters WinStartO and WinSizeO are 100+M. When the DS mapping update is completed, the PN of the last data packet in the buffer queue is N, and the SN is 100+N. When the communication protocol context is transmitted to AP MLD2, the PN of the last data packet sent by AP MLD1 is L, and the SN is 100+L, where L is a positive integer less than N, and M is a positive integer less than N.

[0324] Accordingly, AP MLD1 copies or migrates the communication protocol context associated with the non-AP MLD to AP MLD2. For block acknowledgment protocols for downlink packet transmission, the communication protocol context may also include the SN (or the highest SN of downlink packets sent by AP MLD1 for a specific TID) (or per TID). During non-AP MLD roaming, AP MLD1 or AP MLD2 may send back to the non-AP MLD the SN of the latest downlink packets sent by AP MLD1 for a specific TID (or per TID).

[0325] Accordingly, the non-AP MLD can obtain the SN of the downlink data packet of the latest TID (or per TID) sent by AP MLD1 (or the highest SN among the SNs of downlink data packets sent by AP MLD1), and determine whether to disable (or delete) the link between the non-AP MLD and AP MLD1 in advance (i.e. stop receiving downlink data packets from AP MLD1) based on the reception status of data packets sent before the SN of the latest downlink data packet.

[0326] When the downlink data packet for the latest TA / TID sent by AP MLD1, and all downlink data packets sent before that downlink data packet have been received or processed, the link between non-AP MLD and AP MLD1 can be disabled (or deleted) in advance. For example, before the roaming timeout, the link between non-AP MLD and AP MLD1 can be disabled (or deleted). Additionally, after disabling (or deleting) the link between non-AP MLD and AP MLD1 and establishing the link between non-AP MLD and AP MLD2, the non-AP MLD determines the receive reordering buffer control parameters (e.g., WinStartB, WinSizeB) and / or scoreboard context control parameters WinStartR, WinSizeR for the specific TID (or per TID) corresponding to the DL BA protocol of the receiver. Of course, in this embodiment, the non-AP MLD can also update the frame according to the receive reordering buffer control status parameter information fed back by AP MLD2, and update the WinStartB and WinStartR parameters corresponding to the DL BA protocol of the non-AP MLD as the receiver.

[0327] Accordingly, AP MLD2 can determine the transmit buffer control status information for a specific TID (or per TID) based on the SN of the downlink data packet latest transmitted by AP MLD1. This transmit buffer control status information may include the start sequence number WinStartO of the transmit window (or transmit buffer), the buffer size or number negotiated in the block acknowledgment protocol WinSizeO, and WinEndO, etc. Optionally, AP MLD2 can send a receive reordering buffer control status parameter update frame to the non-AP MLD based on the updated transmit buffer control status information, updating the WinStartB and WinStartR parameters corresponding to the DL BA protocol for the non-AP MLD as the receiver.

[0328] Referring to Figure 8, the SN and / or PN corresponding to the downlink data can be reordered, which helps to ensure that the range of SNs corresponding to the downlink data in AP MLD2 does not overlap with the range of SNs corresponding to the downlink data in AP MLD1. Continuing to refer to Figure 8, after reordering the downlink data packet with SN 100+N+1, the SN of the downlink data packet is 0 and the PN is N+1. After reordering the downlink data packet with SN 100+N+2, the SN of the downlink data packet is 2 and the PN is N+2. After reordering the downlink data packet with SN 100+N+3, the SN of the downlink data packet is 2 and the PN is N+3. After reordering the downlink data packet with SN 100+N+4, the SN of the downlink data packet is 3 and the PN is N+4.

[0329] The following section describes the FT protocol optimization scheme based on data continuity provided in the embodiments of this application, with reference to Figure 9. Figure 9 uses a non-AP MLD as the FTO and the source AP MLD and / or target AP MLD as the FTR as an example. It should be understood that the non-AP MLD can be the non-AP STA described above, and the source AP MLD and / or target AP MLD can be the source AP and the target AP. Assume that the non-AP MLD is associated with the source AP MLD and mobile domain scenario association or FT initial mobile domain scenario association is performed. The scheme in Figure 9 includes steps S910 to S928.

[0330] In step S910, the non-AP MLD sends an FT request to the source AP MLD.

[0331] In some implementations, if a non-AP MLD initiates an FT process from the current AP MLD to the target AP MLD, the non-AP MLD sends an FT request to the source AP MLD.

[0332] In some implementations, the FT request carries information indicating one or more of the following: FTO, target AP MLD, MDE, and basic multi-link element, wherein the MDE indicates support for or permission for fast switching between two AP MLDs belonging to the same mobile domain.

[0333] It should be understood that the aforementioned FT request can also be sent from the source AP MLD to the target AP MLD.

[0334] In step S912, the source AP MLD sends an FT response to the non-AP MLD.

[0335] In some implementations, the FT response carries information indicating one or more of the following: FTO, target AP MLD, MDE, TIE, and underlying multilink element, wherein the TIE indicates the deadline for FTC confirmation, the MDE indicates that support is provided or permission is granted for fast switching between two AP MLDs belonging to the same mobile domain.

[0336] In step S914, the non-AP MLD sends an FT confirmation to the source AP MLD.

[0337] In some implementations, the FT confirmation carries information indicating one or more of the following: FTO, target AP MLD, MDE, RIC request, and underlying multilink elements, wherein the RIC request carries BA context elements and / or SA context elements, which can be found in the preceding description.

[0338] In step S916, the communication protocol context for migrating downlink data between the source AP MLD and the target AP MLD is established. For example, the communication protocol context may include BA protocol control parameters and status parameters, which can be found above.

[0339] In step S918, downlink data is migrated between the source AP MLD and the target AP MLD.

[0340] In step S920, the non-AP MLD sends an FT ACK to the source AP MLD.

[0341] In some implementations, the FT ACK carries information indicating one or more of the following: FTO, target AP MLD, MDE, TIE, RIC response, and underlying multilink element, wherein the TIE is used to indicate the deadline for the reassociation response, and the RIC response carries BA context element and / or SA context element, wherein the BA context element and SA context element can be found in the previous description.

[0342] In some implementations, steps S914 to S920 are applicable to copying or migrating the MLD context, state, and all or part of the context, state, and buffer of the corresponding MLD associated with the MLD from the source AP MLD to the target AP MLD for non-AP MLD.

[0343] In step S922, the target AP MLD sends a communication protocol context status notification frame to the non-AP MLD through the source AP MLD.

[0344] In some implementations, the communication protocol context state notification frame is used to indicate the sender status of downlink data, where the sender status is used, for example, to indicate whether an acknowledgment for the downlink data has been received.

[0345] In some implementations, the source AP MLD or the target AP MLD can use a communication protocol context state notification frame to notify the roaming non-AP MLD of the migration status of the communication protocol context. The migration status is used to indicate that the migration of the non-AP MLD's block acknowledgment protocol context state information and / or security association context state information has been completed.

[0346] In step S924, the non-AP MLD sends a communication protocol context status notification frame to the target AP MLD through the source AP MLD.

[0347] In some implementations, the communication protocol context state notification frame is used to indicate the reception or processing status of downlink data. This reception or processing status indicates whether the downlink data was successfully received and / or whether it was submitted to a higher layer. See the preceding text for further details.

[0348] In some implementations, a non-AP MLD can use a communication protocol context state notification frame to feed back the current block acknowledgment protocol context and / or security association context to the source AP MLD or the target AP MLD.

[0349] In step S926, the non-AP MLD sends an association request frame or a reassociation request frame (Re)Association Request to the target AP MLD.

[0350] In some implementations, the association request frame or reassociation request frame carries information indicating one or more of the following: MDE, BA context element, SA context element, and basic multilink element, where the BA context element and SA context element can be found in the previous description. The MDE is used to indicate that a non-AP MLD is associated with an AP MLD in a mobile domain scenario (or that a non-AP MLD is associated with an AP MLD attached to the mobile domain), and to indicate that fast switching between two AP MLDs attached to the same MLD is supported or allowed.

[0351] The so-called non-AP MLD associated with the AP MLD in the mobile domain scenario (or non-AP MLD associated with the AP MLD attached to the mobile domain MLD) refers to establishing a mapping relationship between the AP MLD attached to the mobile domain and the non-AP MLD (including the mapping relationship between the mobile domain and the AP MLD and the mapping relationship between the AP MLD and the non-AP MLD), and through the mapping relationship between the AP MLD and the DS, enabling the non-AP MLD to access the DS for downlink data packet transmission.

[0352] In step S928, the target AP MLD sends an association response frame or a reassociation response frame to the non-AP MLD.

[0353] In some implementations, the associated response frame or reassociated response frame carries information indicating one or more of the following: MDE, BA context element, SA context element, and underlying multilink element.

[0354] It should be noted that in the scheme shown in Figure 9, the data packet data transmission and processing mechanism of non-AP MLD before, during, and after roaming can be referred to Figures 7 and 8. Additionally, regarding the block acknowledgment protocol for downlink data packet transmission, whether the downlink data packet transmission key (e.g., PTK) has been updated, and / or the parameters of the block acknowledgment protocol (e.g., ...)<TA,RA,TID> Whether the parameters in the tuple change, the sending and receiving ends employ differentiated data packet transmission and processing mechanisms, as detailed above.

[0355] In some implementations, for the block acknowledgment protocol of downlink data packet transmission, after the source AP MLD or target AP MLD has completed the communication protocol context migration, it can send the data communication context migration status to the non-AP MLD. Accordingly, the non-AP MLD can optimize the downlink data packet transmission and processing mechanism based on the communication protocol context migration status. For relevant solutions, please refer to the above.

[0356] The following section, with reference to Figure 10, describes the data continuity-oriented link reconfiguration scheme provided by an embodiment of this application. In some implementations, the frame type and format definition and function update of the data continuity-oriented link reconfiguration protocol and interaction in the MLD architecture (or SMD architecture) include one or more of the following: MDE definition update, link reconfiguration protocol definition update, link reconfiguration request frame definition update, link reconfiguration response frame definition update, FT request and response protocol definition update, FT resource request and response protocol definition update, FT request frame (FT Request) definition update, FT response frame (FT Response) definition update, FT Confirm frame (FT Confirm) definition update, and FT ACK frame (FT ACK) definition update.

[0357] In some implementations, the protocol and signaling interaction for data communication context migration can take either Mode 1 or Mode 2. In Mode 1, interaction is conducted via link reconfiguration notification frames. In Mode 2, exchange can be performed using one or more of the following frames: FT request and response protocol, FT resource request and response protocol, FT request frame, FT response frame, FT confirm frame, and FT ACK frame.

[0358] Referring to Figure 10, the method shown in Figure 10 includes steps S1010 to S1026. It is assumed that the non-AP MLD performs initial MLD (or SMD) association through the source AP MLD.

[0359] In step S1010, the non-AP MLD sends a link reconfiguration notification to the source AP MLD.

[0360] In some implementations, the link reconfiguration notification carries information indicating one or more of the following: MDE, candidate target MLD.

[0361] In some implementations, the MDE includes a "whether the FT is in the same MLD (or the same SMD)" subfield and / or an MLD (or SMD) information subfield.

[0362] In some implementations, the "FT in MobileDomainMLD" subdomain (also known as the "FTinMobileDomainMLD" subdomain) can be used to indicate whether fast conversion between two AP MLDs belonging to the same MLD (or SMD) is supported or allowed. For example, when the value of the "FT in MobileDomainMLD" subdomain is 1, it indicates that fast conversion between two AP MLDs belonging to the same MLD (or SMD) is supported or allowed; otherwise, when the value of the "FT in MobileDomainMLD" subdomain is 2, it indicates that fast conversion between two AP MLDs belonging to the same MLD (or SMD) is not supported or is rejected.

[0363] It should be noted that the values ​​of the above subfields are not limited in the embodiments of this application. For example, when the value of the "FT is in the same MLD (or the same SMD)" subfield is 2, it indicates that fast conversion between two AP MLDs attached to the same MLD (or the same SMD) is supported or allowed; otherwise, when the value of the "FT is in the same MLD (or the same SMD)" subfield is 1, it indicates that fast conversion between two AP MLDs attached to the same MLD (or the same SMD) is not supported or refused.

[0364] In some implementations, the MLD (or SMD) information subfield (also known as the MobileDomainMLD Info subfield) is used to indicate MLD (or SMD) identification information and MLD (or SMD) MAC address information.

[0365] In step S1012, the communication protocol context for migrating downlink data between the source AP MLD and the target AP MLD is established. For example, the communication protocol context may include BA protocol negotiation parameters, which can be found above.

[0366] In step S1014, the source AP MLD sends a link reconfiguration notification to the non-AP MLD.

[0367] In some implementations, the link reconfiguration notification carries information indicating one or more of the following: MDE, candidate target MLD, TIE, BA context element, SA context element, where the TIE indicates the deadline for link reconfiguration.

[0368] In step S1016, the non-AP MLD sends a link reconfiguration request to the source AP MLD.

[0369] In some implementations, the link reconfiguration request carries information indicating one or more of the following: MDE, RME of the source AP MLD, RME of the target AP MLD, and OCI. Therefore, the link reconfiguration request is represented as Link Reconfiguration Request(MDE(FTinMobileDomainMLD, MobileDomainMLD Info), RME for CurrentAPMLD, RME for TargetAPMLD, OCI, TID-To-Link Mapping element).

[0370] In some implementations, the aforementioned MDE carries updated migration domain information, namely MDE(FTinMobileDomainMLD, MobileDomainMLD Info), instructing the non-AP MLD to request link reconfiguration based on existing multi-links in the source AP MLD and target AP MLD to which the MLD is attached, for example, adding links or deleting links from existing multi-links. For example, for FT-oriented link reconfiguration, it requests the deletion of existing links from existing multi-links in the source AP MLD to which the MLD is attached, and the creation of one or more new links in the target MLD to which the MLD is attached.

[0371] In some implementations, the link reconfiguration request frame carries the reconfiguration multilink element (RME for CurrentAPMLD) of the source AP MLD and the reconfiguration multilink element (RME for TargetAPMLD) of the target AP MLD, which respectively describe the non-AP MLD request and the reconfiguration multilink information of the source AP MLD and the target AP MLD.

[0372] In some implementations, the link reconfiguration request frame may also carry one or two flow identifier to link mapping elements, providing flow identifier to link mapping information and indicating that the corresponding flow identifier to link mapping request should be made on the link established by the target AP MLD.

[0373] In step S1018, the communication protocol context for migrating downlink data between the source AP MLD and the target AP MLD is established. For example, the communication protocol context may include BA protocol control parameters and status parameters, which can be found above.

[0374] In some implementations, the source AP MLD or the target AP MLD can use a communication protocol context state notification frame to notify the roaming non-AP MLD of the migration status of the communication protocol context. The migration status is used to indicate that the migration of the non-AP MLD's block acknowledgment protocol context state information and / or security association context state information has been completed.

[0375] In step S1020, downlink data is migrated between the source AP MLD and the target AP MLD.

[0376] In step S1022, the target AP MLD sends a communication protocol context status notification frame to the non-AP MLD through the source AP MLD.

[0377] In some implementations, the communication protocol context state notification frame is used to indicate the sender status of downlink data, where the sender status is used, for example, to indicate whether an acknowledgment for the downlink data has been received.

[0378] In step S1024, the non-AP MLD sends a communication protocol context status notification frame to the target AP MLD through the source AP MLD.

[0379] In some implementations, the communication protocol context state notification frame is used to indicate the reception or processing status of downlink data. This reception or processing status indicates whether the downlink data was successfully received and / or whether it was submitted to a higher layer. See the preceding text for further details.

[0380] In some implementations, a non-AP MLD can use a communication protocol context state notification frame to feed back the current block acknowledgment protocol context and / or security association context to the source AP MLD or the target AP MLD.

[0381] In step S1026, the source AP MLD sends a connection reconfiguration response to the non-AP MLD.

[0382] In some implementations, the connection reconfiguration response carries information indicating one or more of the following: MDE, RSL of the source AP MLD, RSL of the target AP MLD, GKD, OCI, BME, BA context element, and SA context element. Therefore, the connection reconfiguration response can be represented as Link Reconfiguration Response(MDE(FTinMobileDomainMLD, MobileDomainMLD Info), RSL for CurrentAPMLD, RSL for TargetAPMLD, GKD, OCI, BME, TID-To-Link Mapping element).

[0383] In some implementations, the link reconfiguration response frame carries an updated MDE (FTinMobileDomainMLD, MobileDomainMLD Info), indicating that this frame is a response to a link reconfiguration request frame containing an MDE, that is, a response to a link reconfiguration request based on the established multiple links of the source AP MLD and the target AP MLD to which the MLD is attached.

[0384] In some implementations, the link reconfiguration response carries link reconfiguration status code information (i.e., the status code field in the action domain), indicating the status code for link reconfiguration in an MLD scenario. If the status code indicates "Reject Mobile Domain Link Reconfiguration," the link reconfiguration response does not contain reconfiguration status list information for the source AP MLD and target AP MLD link reconfiguration (i.e., the number of reconfiguration status tuples and the reconfiguration status list). If the status code indicates "SUCCESS," the link reconfiguration response also carries reconfiguration status list information for the source AP MLD and target AP MLD link reconfiguration, indicating the number of reconfiguration status tuples and the reconfiguration status in the reconfiguration status list for the source AP MLD and target AP MLD link reconfiguration. Specifically, in the link reconfiguration response frame, the reconfiguration status list for the source AP MLD and target AP MLD is carried in the reconfiguration status tuple subfield corresponding to each link ID indicated in the Per-STA Profile sub-element of the corresponding link reconfiguration request.

[0385] In some implementations, for the reconfiguration status information of the source AP MLD, if the source AP MLD accepts a link deletion request for a link ID, the corresponding status subfield in the reconfiguration status tuple subfield is set to SUCCESS. For the reconfiguration status information of the target AP MLD, if the target AP MLD accepts a link addition request for the corresponding link ID, the corresponding status subfield should be set to SUCCESS in the reconfiguration status tuple subfield, and the status code field contained in the corresponding STA configuration file subfield in the Per-STA configuration file subfield of the basic multi-link element should indicate SUCCESS.

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

[0387] If the link reconfiguration response carries a status code indicating "SUCCESS," meaning the target AP MLD accepts the addition of one or more links, then when using RSN, both the source AP MLD and the target AP MLD should include a Group Key Data subfield in the link reconfiguration response. For each link added by the target AP MLD, both the source AP MLD and the target AP MLD should include an MLO GTK KDE, an MLO IGTK KDE, and an MLO BIGTK KDE in the Group Key Data subfield, providing a group key identified by the Link ID subfield for the link added by the target AP MLD.

[0388] In some implementations, the link reconfiguration response may also include one or two flow identifier-to-link mapping elements to respond to the received link reconfiguration request carrying flow identifier-to-link mapping elements. The link reconfiguration response indicates the result of the flow identifier-to-link mapping performed by the non-AP MLD and the target AP MLD on the accepted established link. The rules governing the flow identifier-to-link mapping performed by the target AP MLD and the non-AP MLD on the accepted established link, as well as the manner in which the link reconfiguration request or link reconfiguration response indicates the flow identifier-to-link mapping result, are consistent with the rules and manner in which the associated response frame sent by the target AP MLD responds to the associated request frame carrying flow identifier-to-link mapping elements it receives, indicating the flow identifier-to-link mapping result.

[0389] It should be noted that the link reconfiguration response in this embodiment may not include the flow identifier-to-link mapping element. Additionally, the link reconfiguration request in this embodiment may or may not include the flow identifier-to-link mapping element.

[0390] In some implementations, the non-AP MLD sends an association request frame or a reassociation request frame to the source AP MLD, and correspondingly, the source AP MLD sends an association response frame or a reassociation response frame back to the non-AP MLD.

[0391] The association request frame or reassociation request frame can be represented as (Re)Association Request(MDE(FTinMobileDomainMLD,MobileDomainMLD Info),Basic Multi-Link element), and correspondingly, the association response frame or reassociation response frame can be represented as (Re)Association Response(MDE(FTinMobileDomainMLD,MobileDomainMLD Info),Basic Multi-Link element).

[0392] The association request frame or reassociation request frame carries an updated MDE (FTinMobileDomainMLD, MobileDomainMLD Info information field), instructing the non-AP MLD to associate with the AP MLD in the MLD scenario (or the non-AP MLD associating with the AP MLD attached to the MLD), and indicating that fast conversion between two AP MLDs attached to the same MLD is supported or allowed.

[0393] In other implementations, the link reconfiguration scheme described above in the embodiments of this application can be used in conjunction with the FT process, which refers to the non-AP MLD initiating the FT process from the current AP MLD to the target AP MLD in the MLD scenario.

[0394] In some implementations, if the non-AP MLD can determine that it is transitioning from the source AP MLD to the target AP MLD in an MLD scenario, then the non-AP MLD sends a fast transition request frame to the target AP MLD through the source AP MLD. Correspondingly, the target AP MLD sends a fast transition response frame back to the non-AP MLD through the source AP MLD.

[0395] The fast conversion request frame can be represented as FT Request(FTO,TargetAP,MDE(FTinMobileDomainMLD,MobileDomainMLD Info),Basic Multi-Link element), and the fast conversion response frame can be represented as FT Response(FTO,TargetAP,MDE(FTinMobileDomainMLD,MobileDomainMLD Info),Basic Multi-Link element).

[0396] The fast conversion request frame and fast conversion response frame carry an updated MDE (FTinMobileDomainMLD, MobileDomainMLD Info field), indicating that fast conversion is supported or permitted between two AP MLDs belonging to the same mobile domain MLD.

[0397] In some implementations, the above FT process also includes, for non-AP MLDs, copying or migrating the MLD context, MLD state, all or part of the context of the corresponding subordinate MLD, the state of the subordinate MLD, and the buffer of the subordinate MLD from the current AP MLD to the target AP MLD.

[0398] In the above process, the non-AP MLD can send an FT acknowledgment frame to the target AP MLD through the source AP MLD, and correspondingly, the target AP MLD can send an FT ACK frame back to the non-AP MLD through the source AP MLD.

[0399] The FT confirmation frame can be represented as FT Confirm(FTO,TargetAP,MDE(FTinMobileDomainMLD,MobileDomainMLD Info),RIC-Request(Block Ack Context element,SA context element),Basic Multi-Link element), and correspondingly, the FT ACK frame can be represented as FT ACK(FTO,TargetAP,MDE(FTinMobileDomainMLD,MobileDomainMLD Info),TIE(ReassociationDeadline),RIC-Response(Block Ack Context element,SA Context element),Basic Multi-Link element).

[0400] In some implementations, FT acknowledgments and FT ACKs can carry BA context elements and SA context elements, indicating the relevant block acknowledgment protocol scenario (or state) information and security association scenario (or state) information. For related information, please refer to the above text.

[0401] It should be noted that the data packet data transmission and processing mechanism of the non-AP MLD in the scheme shown in Figure 10 before, during, and after roaming is as described in Figures 7 and 8. In particular, for the block acknowledgment protocol of downlink data packet transmission, it can be based on whether the key (e.g., PTK) of downlink data packet transmission has been updated, and / or the parameters of the block acknowledgment protocol (e.g., ...<TA,RA,TID> Whether the parameters in the tuple change, the sending and receiving ends use different data packet transmission and processing mechanisms. For related information, please refer to the above text.

[0402] In addition, for the block acknowledgment protocol for downlink data packet transmission, after the current AP MLD or the target AP MLD completes the communication protocol context migration, it sends the data communication context migration status to the non-AP MLD, and the non-AP MLD optimizes the data packet transmission and processing mechanism based on the data communication context migration status.

[0403] The method embodiments of this application have been described in detail above with reference to Figures 1 to 10. The apparatus embodiments of this application will be described in detail below with reference to Figures 11 to 13. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be referred to the preceding method embodiments.

[0404] Figure 11 is a schematic structural diagram of a communication device provided in an embodiment of this application. The communication device 1100 shown in Figure 11 is a first device, and the communication device 1100 shown in Figure 11 includes a transmitting unit 1110.

[0405] The sending unit 1110 is used to send first information to the second device. The first information is associated with the communication protocol context of downlink data. The communication protocol of the downlink data is for non-access point devices. The non-access point device is a non-access point device roaming from the first AP device to the second AP device. If the first device is the non-access point device, then the second device is either the first AP device or the second AP device; or if the first device is either the first AP device or the second AP device, then the second device is the non-access point device; or if the first device is the first AP device, then the second device is the second AP device.

[0406] In this embodiment, the communication device 1100 can be used to execute some or all of the method steps executed by the first device in the above method embodiments. The communication device 1100 includes units or modules for executing the aforementioned method steps. The method flow has been described in detail in the foregoing embodiments. The modules in this embodiment have the same function or perform the same steps, and will not be described again here. However, those skilled in the art should know that the textual descriptions corresponding to the foregoing method embodiments can be incorporated into this embodiment and correspond to the modules in the communication device 1100.

[0407] Figure 12 is a schematic structural diagram of a communication device provided in another embodiment of this application. The communication device 1200 shown in Figure 12 is a second device, and the communication device 1200 shown in Figure 12 includes a receiving unit 1210.

[0408] The receiving unit 1210 is configured to receive first information sent by a first device, the first information being associated with the communication protocol context of downlink data, the communication protocol of the downlink data being for a non-access point device, the non-access point device being a non-access point device roaming from a first AP device to a second AP device; wherein, if the first device is the non-access point device, then the second device is either the first AP device or the second AP device, or if the first device is either the first AP device or the second AP device, then the second device is the non-access point device; or if the first device is the first AP device, then the second device is the second AP device.

[0409] In this embodiment, the communication device 1200 can be used to execute some or all of the method steps executed by the first device in the above method embodiments. The communication device 1200 includes units or modules for executing the aforementioned method steps. The method flow has been described in detail in the foregoing embodiments. The modules in this embodiment have the same function or perform the same steps, and will not be described again here. However, those skilled in the art should know that the textual descriptions corresponding to the foregoing method embodiments can be incorporated into this embodiment and correspond to the modules in the communication device 1200.

[0410] In an optional embodiment, the transmitting unit 1110 may be a transceiver 1330. The communication device 1100 may also include a processor 1310 and a memory 1320, as shown in FIG13.

[0411] In an optional embodiment, the receiving unit 1210 may be a transceiver 1330. The communication device 1200 may also include a processor 1310 and a memory 1320, as shown in FIG13.

[0412] Figure 13 is a schematic structural diagram of a communication device according to an embodiment of this application. The dashed lines in Figure 13 indicate that the unit or module is optional. This device 1300 can be used to implement the methods described in the above method embodiments. Device 1300 can be a chip, a terminal device, or a network device.

[0413] Apparatus 1300 may include one or more processors 1310. The processor 1310 may support apparatus 1300 in implementing the methods described in the preceding method embodiments. The processor 1310 may be a general-purpose processor or a special-purpose processor. For example, the processor may be a central processing unit (CPU). Alternatively, the processor may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0414] The apparatus 1300 may further include one or more memories 1320. The memories 1320 store a program that can be executed by the processor 1310, causing the processor 1310 to perform the methods described in the preceding method embodiments. The memories 1320 may be independent of the processor 1310 or integrated within the processor 1310.

[0415] The device 1300 may also include a transceiver 1330. The processor 1310 can communicate with other devices or chips via the transceiver 1330. For example, the processor 1310 can send and receive data with other devices or chips via the transceiver 1330.

[0416] This application also provides a computer-readable storage medium for storing a program. This computer-readable storage medium can be applied to a terminal or network device provided in this application, and the program causes a computer to execute the methods performed by the terminal or network device in various embodiments of this application.

[0417] This application also provides a computer program product. The computer program product includes a program. The computer program product can be applied to a terminal or network device provided in this application embodiment, and the program causes a computer to execute the methods performed by the terminal or network device in various embodiments of this application.

[0418] This application also provides a computer program. This computer program can be applied to the terminal or network device provided in this application, and the computer program causes the computer to execute the methods performed by the terminal or network device in various embodiments of this application.

[0419] It should be understood that the terms "system" and "network" in this application can be used interchangeably. Furthermore, the terminology used in this application is only for explaining specific embodiments of the application and is not intended to limit the application. The terms "first," "second," "third," and "fourth," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. In addition, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0420] In the embodiments of this application, the term "instruction" can be a direct instruction, an indirect instruction, or an indication of a relationship. For example, A instructing B can mean that A directly instructs B, such as B being able to obtain information through A; it can also mean that A indirectly instructs B, such as A instructing C, so B can obtain information through C; or it can mean that there is a relationship between A and B.

[0421] In the embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0422] In the embodiments of this application, the term "correspondence" can indicate a direct or indirect correspondence between two things, or an association between two things, or a relationship such as instruction and being instructed, configuration and being configured.

[0423] In this application embodiment, "predefined" or "preconfigured" can be implemented by pre-storing corresponding codes, tables, or other means that can be used to indicate relevant information in the device (e.g., including terminal devices and network devices). This application does not limit the specific implementation method. For example, predefined can refer to what is defined in the protocol.

[0424] In this application embodiment, the "protocol" may refer to a standard protocol in the field of communication, such as the LTE protocol, the NR protocol, and related protocols applied to future communication systems. This application does not limit this.

[0425] In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0426] In the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

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

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

[0429] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0430] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can read or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs, DVDs) or semiconductor media (e.g., solid-state disks, SSDs), etc.

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

Claims

1. A communication method characterized by comprising: include: The first device sends first information to the second device. The first information is associated with the communication protocol context of downlink data. The communication protocol of the downlink data is for non-access point devices. The non-access point devices are non-access point devices roaming from the first AP device to the second AP device. Wherein, if the first device is the non-access point device, then the second device is either the first AP device or the second AP device, or If the first device is the first AP device or the second AP device, then the second device is the non-access point device; or If the first device is the first AP device, then the second device is the second AP device.

2. The method of claim 1, wherein, The first information carries some or all of the information in the communication protocol context of the downlink data.

3. The method of claim 1 or 2, wherein, The communication protocol context includes the BA protocol context and / or the RSNA confidentiality and integrity protocol context.

4. The method of any one of claims 1-3, wherein, The first device is either the first AP device or the second AP device, the downlink data is carried in data packets, and the communication protocol context is used to indicate one or more of the following: The SN corresponding to the data packet to be assigned to the first-stream identifier (TID); The SN corresponding to the last data packet that arrives in the buffer queue in the data packet corresponding to the first TID; The SN corresponding to the latest data packet sent by the first AP device in the data packet corresponding to the first TID; Control status information of the send buffer corresponding to the first TID; The PN corresponding to the last data packet to arrive in the buffer queue in the data packet corresponding to the first TID; The minimum threshold for PN depletion and / or the maximum threshold for PN depletion associated with the key corresponding to the first TID; Do the first AP device and / or the second AP device support packet migration via DS? The migration status of the data packet; Is the transmission key of the data packet corresponding to the first AP device the same as the transmission key of the data packet corresponding to the second AP device? 5. The method of claim 4, wherein, The migration status of the data packet is used to indicate whether the data packet has been successfully migrated from the first AP device to the second AP device.

6. The method of claim 4 or 5, wherein, The control status information of the transmit buffer corresponding to the first TID is used to indicate one or more of the following: The starting sequence number corresponding to the sending buffer; The size of the buffer corresponding to the send buffer; Whether the data packets cached in the sending buffer have been successfully sent.

7. The method of claim 6, wherein, The control status information indicates, through the record bitmap corresponding to the downlink, whether the data packets cached in the transmission buffer have been successfully sent.

8. The method of any one of claims 4-7, wherein, The communication protocol context is carried in roaming response frames and / or communication protocol context status notification frames.

9. The method of any one of claims 4-8, wherein, The transmission of the communication protocol context satisfies one or more of the following: This is done before transmitting the roaming request frame; This is performed after the roaming request frame is transmitted; This is performed before transmitting the roaming response frame; This is done simultaneously with the transmission of the roaming response frame.

10. The method of any one of claims 4-9, wherein, The first field contains one or more of the following: the SN corresponding to the data packet to be allocated for the first flow identifier (TID); the SN corresponding to the last data packet to arrive in the buffer queue in the data packet corresponding to the first TID; and the SN corresponding to the latest data packet sent by the first AP device in the data packet corresponding to the first TID. The first field is used to carry block acknowledgment protocol related parameters.

11. The method of any one of claims 4-10, wherein, One or more of the following are carried in one or more fields in the second field: the PN corresponding to the last data packet that arrives in the buffer queue in the data packet corresponding to the first TID; the minimum threshold for PN exhaustion associated with the key corresponding to the first TID; and the maximum threshold for PN exhaustion associated with the key corresponding to the first TID. The second field is used to carry parameters for security association.

12. The method of any one of claims 1-11, wherein, The second device is a non-access point device, and the first information is used to indicate the migration status of the communication protocol context.

13. The method of claim 12, wherein, The migration status of the communication protocol context is used to indicate whether the communication protocol context has been successfully migrated from the first AP device to the second AP device.

14. The method of claim 12 or 13, wherein, The first information is carried in the roaming response frame.

15. The method of any one of claims 1-14, wherein, The first device is the first AP device, the second device is the non-access point device, and the method further includes: The first device sends a first indication message to the second device. The first indication message is used to indicate whether the first AP device has a data packet to be sent to the non-access point device. The data packet is used to carry the downlink data.

16. The method of claim 15, wherein, The first indication information is carried in more data subfields of the frame control field.

17. The method of any one of claims 1-16, wherein, The first device is the first AP device, and the method further includes: If the first condition is met, and the first device has data packets cached that need to be sent to the non-access point device, then the first device clears the data packets. The first condition includes one or more of the following: Roaming timeout timer expired; The link between the first AP device and the non-access point device is deleted; The first AP device sends a roaming response message to the non-access point device.

18. The method of any one of claims 1-14, wherein, The first device is the first AP device, the second device is the second AP device, and the first AP device and the second AP device support the migration of the data packets carrying the downlink data. The method further includes: If the first device has the data packet to be sent to the non-access point device in its cache, then the first device sends the data packet to the second device.

19. The method of claim 18, wherein, If the first AP device receives buffer control status information for the reordered data packets to be transmitted, the data packets include data packets in the data packets buffered by the first AP device that were not received by the non-access point device; and / or If the first AP device does not receive the cache control status information after reordering the data packets to be transmitted, the data packets include the data packets cached by the first AP device.

20. The method of claim 19, wherein, If the first AP device receives buffer control status information after reordering the data packets to be transmitted, the method further includes: The first AP device deletes the data packet stored in its transmission buffer containing the buffer control status information indicating that the non-access point device has successfully received it.

21. The method of any one of claims 1-19, wherein, The first device is the first AP device, and the downlink data is carried in data packets. If the first AP device receives the buffer control status information after reordering the data packets to be transmitted, the first AP device will not send the buffer control status information to the non-access point device to indicate that the non-access point device has successfully received the data packets.

22. The method of claim 21, wherein, The data packets that the non-access point device has successfully received include data packets that the non-access point device has successfully received but has not sent a confirmation of receipt to the first AP device.

23. The method of any one of claims 1-3, wherein, The first device is the non-access point device, the downlink data is carried in data packets, and the communication protocol context is used to indicate one or more of the following: The processing status information of the data packet corresponding to the first TID; The SN corresponding to the last data packet delivered to the higher layer in the data packet corresponding to the first TID; The PN corresponding to the last data packet in the data packet that has been delivered to the higher layer in the first TID; Control status information of the receive buffer corresponding to the reordered data packets; The data packet corresponds to the scoreboard context control status information.

24. The method of claim 23, wherein, The processing status information of the data packet corresponding to the first TID is used to indicate one or more of the following: Has the data packet corresponding to the first TID been successfully received? Whether the data packet corresponding to the first TID is transmitted to a higher layer; Whether the data packet corresponding to the first TID is cached in the receive buffer; Whether to stop processing the data packets from the first AP device.

25. The method of claim 24, wherein, The processing status information of the data packet corresponding to the first TID is indicated by the second indication information as to whether the data packet from the first AP device is no longer being processed. The second indication information is used to indicate that the data packet corresponding to the first TID has been cleared in the receive buffer.

26. The method of any one of claims 23-25, wherein, The cache control status information includes one or more of the following: The first parameter corresponding to the first TID or the first TA is used to indicate the SN corresponding to the first data packet that the non-access point device expects to receive after the data packets to be transmitted are reordered by the second AP device. The second parameter corresponding to the first TID or the first TA, the second parameter is used to indicate the highest SN corresponding to the data packet expected to be received in the receiving window, the receiving window is used to receive the data packet to be transmitted after being reordered by the second AP device; Information used for the cache record bitmap corresponding to the reordered data packet.

27. The method of any one of claims 23-26, wherein, The scoreboard context control status information corresponding to the data packet is used to indicate one or more of the following: The third parameter is used to indicate the lowest SN recorded in the BA record bitmap of the non-access point device; The fourth parameter is used to indicate the highest SN recorded in the BA record bitmap of the non-access point device; The bitmap corresponding to each SN in the BA record bitmap of the non-access point device.

28. The method of any one of claims 23-27, wherein, The communication protocol context is carried in one or more of the following: roaming notification frame, roaming request frame, and communication protocol context status notification frame.

29. The method of any one of claims 23-28, wherein, The transmission of the communication protocol context satisfies one or more of the following: This is done before transmitting the roaming request frame; This is performed after the roaming request frame is transmitted; This is performed before transmitting the roaming response frame; This is done simultaneously with the transmission of the roaming response frame.

30. The method of any one of claims 23-29, wherein, The second device is the first AP device, and the method further includes: Before the first device receives the roaming response frame, the first device receives the data packet sent by the second device.

31. The method of any one of claims 23-29, wherein, The method further includes: Based on the type of the roaming response frame, the first device determines whether to not receive the data packets sent by the first AP device or to continue receiving the data packets sent by the first AP device before the roaming timer expires.

32. The method of claim 31, wherein, If the roaming response frame is a reassociation response frame, the first device does not receive the data packet sent by the first AP device, wherein the reassociation response frame is used to indicate that the non-access point device has successfully reassociated with the second AP; and / or If the type of the roaming response frame is a link reconfiguration frame, the first device continues to receive the data packet sent by the first AP device before the roaming timer expires, wherein the link reconfiguration frame is used to indicate that the link between the first device and the second AP has been successfully established.

33. The method of any one of claims 23-32, wherein, The method further includes: Based on the reception status of the data packets, the first device determines whether to delete the link between the first device and the first AP device.

34. The method of claim 33, wherein, If the data packet reception status indicates that the last data packet sent by the first AP device and the data packets transmitted before the last data packet have been successfully received, then the first device deletes the link between the first device and the first AP device.

35. The method of claim 34, wherein, If, before the roaming timeout timer expires, the data packet reception status indicates that the last data packet sent by the first AP device and all data packets transmitted before the last data packet have been successfully received, then the first device deletes the link between the first device and the first AP device.

36. The method of any one of claims 23-35, wherein, The transmission key for the data packets corresponding to the link between the first device and the first AP device is the same as the transmission key for the data packets corresponding to the link between the first device and the second AP device. The method further includes: After the first device receives the roaming response frame, and before the link between the first device and the first AP device is deleted, the first device receives the data packet sent by the first AP device and / or the second AP device based on the transmission key.

37. The method of any one of claims 23-36, wherein, The transmission key for the data packets corresponding to the link between the first device and the first AP device is different from the transmission key for the data packets corresponding to the link between the first device and the second AP device. The method further includes: After the first device receives the roaming response frame, the first device receives the data packet sent by the second AP device based on the transmission key of the data packet corresponding to the link between the first device and the second AP device.

38. The method of any one of claims 23-37, wherein, If the first AP device and the second AP device do not support the migration of the data packets, the method further includes: If the SN corresponding to the data packet of the first TID cached in the receive buffer of the first device is less than the target SN, then the first device clears all data packets corresponding to the first TID in the receive buffer, wherein the target SN is the highest SN corresponding to the data packet of the first TID sent by the first AP device.

39. A method of communication, comprising: include: The second device receives first information sent by the first device. The first information is associated with the communication protocol context of downlink data. The communication protocol of the downlink data is for non-access point devices. The non-access point devices are non-access point devices that roam from the first AP device to the second AP device. Wherein, if the first device is the non-access point device, then the second device is either the first AP device or the second AP device, or If the first device is the first AP device or the second AP device, then the second device is the non-access point device; or If the first device is the first AP device, then the second device is the second AP device.

40. The method of claim 39, wherein, The first information carries some or all of the information in the communication protocol context of the downlink data.

41. The method of claim 39 or 40, wherein, The communication protocol context includes the BA protocol context and / or the RSNA confidentiality and integrity protocol context.

42. The method of any one of claims 39-41, wherein, The first device is either the first AP device or the second AP device, the downlink data is carried in data packets, and the communication protocol context is used to indicate one or more of the following: The SN corresponding to the data packet to be assigned to the first-stream identifier (TID); The SN corresponding to the last data packet that arrives in the buffer queue in the data packet corresponding to the first TID; The SN corresponding to the latest data packet sent by the first AP device in the data packet corresponding to the first TID; Control status information of the send buffer corresponding to the first TID; The PN corresponding to the last data packet to arrive in the buffer queue in the data packet corresponding to the first TID; The minimum threshold for PN depletion and / or the maximum threshold for PN depletion associated with the key corresponding to the first TID; Do the first AP device and / or the second AP device support packet migration via DS? The migration status of the data packet; Is the transmission key of the data packet corresponding to the first AP device the same as the transmission key of the data packet corresponding to the second AP device? 43. The method of claim 42, wherein, The migration status of the data packet is used to indicate whether the data packet has been successfully migrated from the first AP device to the second AP device.

44. The method of claim 42 or 43, wherein, The control status information of the transmit buffer corresponding to the first TID is used to indicate one or more of the following: The starting sequence number corresponding to the sending buffer; The size of the buffer corresponding to the send buffer; Whether the data packets cached in the sending buffer have been successfully sent.

45. The method of claim 44, wherein, The control status information indicates, through the record bitmap corresponding to the downlink, whether the data packets cached in the transmission buffer have been successfully sent.

46. The method of any one of claims 42-45, wherein, The communication protocol context is carried in roaming response frames and / or communication protocol context status notification frames.

47. The method of any one of claims 42-46, wherein, The transmission of the communication protocol context satisfies one or more of the following: This is done before transmitting the roaming request frame; This is performed after the roaming request frame is transmitted; This is performed before transmitting the roaming response frame; This is done simultaneously with the transmission of the roaming response frame.

48. The method of any one of claims 41-47, wherein, The first field contains one or more of the following: the SN corresponding to the data packet to be allocated for the first flow identifier (TID); the SN corresponding to the last data packet to arrive in the buffer queue in the data packet corresponding to the first TID; and the SN corresponding to the latest data packet sent by the first AP device in the data packet corresponding to the first TID. The first field is used to carry block acknowledgment protocol related parameters.

49. The method of any one of claims 41-48, wherein, One or more of the following are carried in one or more fields in the second field: the PN corresponding to the last data packet that arrives in the buffer queue in the data packet corresponding to the first TID; the minimum threshold for PN exhaustion associated with the key corresponding to the first TID; and the maximum threshold for PN exhaustion associated with the key corresponding to the first TID. The second field is used to carry parameters for security association.

50. The method of any one of claims 39-49, wherein, The second device is a non-access point device, and the first information is used to indicate the migration status of the communication protocol context of the downlink data.

51. The method of claim 50, wherein, The migration status of the communication protocol context is used to indicate whether the communication protocol context has been successfully migrated from the first AP device to the second AP device.

52. The method of claim 50 or 51, wherein, The first information is carried in the roaming response frame.

53. The method of any one of claims 39-52, wherein, The first device is the first AP device, the second device is the non-access point device, and the method further includes: The second device receives a first indication information sent by the first device. The first indication information is used to indicate whether the first AP device has a data packet to be sent to the non-access point device. The data packet is used to carry the downlink data.

54. The method of claim 53, wherein, The first indication information is carried in more data subfields of the frame control field.

55. The method of any one of claims 39-52, wherein, The first device is the first AP device, the second device is the second AP device, and the first AP device and the second AP device support the migration of downlink data packets. The method further includes: If the first device has a data packet that is to be sent to the non-access point device, then the second device receives the data packet sent by the first device.

56. The method of claim 55, wherein, If the first AP device receives buffer control status information for the reordered data packets to be transmitted, the data packets include data packets in the data packets buffered by the first AP device that were not received by the non-access point device; and / or If the first AP device does not receive the cache control status information after reordering the data packets to be transmitted, the data packets include the data packets cached by the first AP device.

57. The method of any one of claims 39-41, wherein, The first device is the non-access point device, the downlink data is carried in data packets, and the communication protocol context is used to indicate one or more of the following: The processing status information of the data packet corresponding to the first TID; The SN corresponding to the last data packet delivered to the higher layer in the data packet corresponding to the first TID; The PN corresponding to the last data packet in the data packet that has been delivered to the higher layer in the first TID; Control status information of the receive buffer corresponding to the reordered data packets; The data packet corresponds to the scoreboard context control status information.

58. The method of claim 57, wherein, The processing status information of the data packet corresponding to the first TID is used to indicate one or more of the following: Has the data packet corresponding to the first TID been successfully received? Whether the data packet corresponding to the first TID is transmitted to a higher layer; Whether the data packet corresponding to the first TID is cached in the receive buffer; Whether to stop processing the data packets from the first AP device.

59. The method of claim 58, wherein, The processing status information of the data packet corresponding to the first TID is indicated by the second indication information as to whether the data packet from the first AP device is no longer being processed. The second indication information is used to indicate that the data packet corresponding to the first TID has been cleared in the receive buffer.

60. The method of any one of claims 57-59, wherein, The cache control status information includes one or more of the following: The first parameter corresponding to the first TID or the first TA is used to indicate the SN corresponding to the first data packet that the non-access point device expects to receive after the data packets to be transmitted are reordered by the second AP device. The second parameter corresponding to the first TID or the first TA, the second parameter is used to indicate the highest SN corresponding to the data packet expected to be received in the receiving window, the receiving window is used to receive the data packet to be transmitted after being reordered by the second AP device; Information used for the cache record bitmap corresponding to the reordered data packet.

61. The method of any one of claims 57-60, wherein, The scoreboard context control status information corresponding to the data packet is used to indicate one or more of the following: The third parameter is used to indicate the lowest SN recorded in the BA record bitmap of the non-access point device; The fourth parameter is used to indicate the highest SN recorded in the BA record bitmap of the non-access point device; The bitmap corresponding to each SN in the BA record bitmap of the non-access point device.

62. The method of any one of claims 57-61, wherein, The communication protocol context is carried in one or more of the following: roaming notification frame, roaming request frame, and communication protocol context status notification frame.

63. The method of any one of claims 57-62, wherein, The transmission of the communication protocol context satisfies one or more of the following: This is done before transmitting the roaming request frame; This is performed after the roaming request frame is transmitted; This is performed before transmitting the roaming response frame; This is done simultaneously with the transmission of the roaming response frame.

64. The method of any one of claims 57-63, wherein, The second device is the first AP device, and the method further includes: Before the first device receives the roaming response frame, the first AP device sends a data packet to the first device.

65. A communications device, characterized by The communication device is a first device, comprising: A sending unit is used to send first information to a second device, the first information being associated with the communication protocol context of downlink data, the communication protocol of the downlink data being for a non-access point device, the non-access point device being a non-access point device roaming from the first AP device to the second AP device; Wherein, if the first device is the non-access point device, then the second device is either the first AP device or the second AP device, or If the first device is the first AP device or the second AP device, then the second device is the non-access point device; or If the first device is the first AP device, then the second device is the second AP device.

66. The communications device of claim 65, wherein, The first information carries some or all of the information in the communication protocol context of the downlink data.

67. The communication device of claim 65 or 66, wherein, The communication protocol context includes the BA protocol context and / or the RSNA confidentiality and integrity protocol context.

68. The communication device of any of claims 65-67, wherein, The first device is either the first AP device or the second AP device, the downlink data is carried in data packets, and the communication protocol context is used to indicate one or more of the following: The SN corresponding to the data packet to be assigned to the first-stream identifier (TID); The SN corresponding to the last data packet that arrives in the buffer queue in the data packet corresponding to the first TID; The SN corresponding to the latest data packet sent by the first AP device in the data packet corresponding to the first TID; Control status information of the send buffer corresponding to the first TID; The PN corresponding to the last data packet to arrive in the buffer queue in the data packet corresponding to the first TID; The minimum threshold for PN depletion and / or the maximum threshold for PN depletion associated with the key corresponding to the first TID; Do the first AP device and / or the second AP device support packet migration via DS? The migration status of the data packet; Is the transmission key of the data packet corresponding to the first AP device the same as the transmission key of the data packet corresponding to the second AP device? 69. The communications device of claim 68, wherein, The migration status of the data packet is used to indicate whether the data packet has been successfully migrated from the first AP device to the second AP device.

70. The communication device of claim 68 or 69, wherein, The control status information of the transmit buffer corresponding to the first TID is used to indicate one or more of the following: The starting sequence number corresponding to the sending buffer; The size of the buffer corresponding to the send buffer; Whether the data packets cached in the sending buffer have been successfully sent.

71. The communications device of claim 70 wherein, The control status information indicates, through the record bitmap corresponding to the downlink, whether the data packets cached in the transmission buffer have been successfully sent.

72. The communication device of any of claims 68-71, wherein, The communication protocol context is carried in roaming response frames and / or communication protocol context status notification frames.

73. The communication device of any of claims 68-72, wherein, The transmission of the communication protocol context satisfies one or more of the following: This is done before transmitting the roaming request frame; This is performed after the roaming request frame is transmitted; This is performed before transmitting the roaming response frame; This is done simultaneously with the transmission of the roaming response frame.

74. The communication device of any of claims 67-73, wherein, The first field contains one or more of the following: the SN corresponding to the data packet to be allocated for the first flow identifier (TID); the SN corresponding to the last data packet to arrive in the buffer queue in the data packet corresponding to the first TID; and the SN corresponding to the latest data packet sent by the first AP device in the data packet corresponding to the first TID. The first field is used to carry block acknowledgment protocol related parameters.

75. The communication device of any of claims 67-74, wherein, One or more of the following are carried in one or more fields in the second field: the PN corresponding to the last data packet that arrives in the buffer queue in the data packet corresponding to the first TID; the minimum threshold for PN exhaustion associated with the key corresponding to the first TID; and the maximum threshold for PN exhaustion associated with the key corresponding to the first TID. The second field is used to carry parameters for security association.

76. The communication device of any of claims 65-75, wherein, The second device is a non-access point device, and the first information is used to indicate the migration status of the communication protocol context of the downlink data.

77. The communications device of claim 76 wherein, The migration status of the communication protocol context is used to indicate whether the communication protocol context has been successfully migrated from the first AP device to the second AP device.

78. The communication device of claim 76 or 77, wherein, The first information is carried in the roaming response frame.

79. The communication device of any of claims 65-78, wherein, The first device is the first AP device, and the second device is the non-access point device. The sending unit is used to send first indication information to the second device. The first indication information is used to indicate whether the first AP device has cached data packets to be sent to the non-access point device. The data packets are used to carry the downlink data.

80. The communications device of claim 79 wherein, The first indication information is carried in more data subfields of the frame control field.

81. The communication device of any of claims 65-80, wherein, The first device is the first AP device, and the communication device further includes: If a first condition is met, and the first device has downlink data cached to be sent to the non-access point device, then the first processing unit is used to clear the downlink data, wherein the first condition includes one or more of the following: Roaming timeout timer expired; The link between the first AP device and the non-access point device is deleted; The first AP device sends a roaming response message to the non-access point device.

82. The communication device of any of claims 65-78, wherein, The first device is the first access point (AP) device, and the second device is the second access point (AP) device. The first AP device and the second AP device support the migration of data packets carrying the downlink data. If the first device has a data packet that is to be sent to the non-access point device, then the sending unit is used to send the data packet to the second device.

83. The communications device of claim 82 wherein, If the first AP device receives buffer control status information for the reordered data packets to be transmitted, the data packets include data packets in the data packets buffered by the first AP device that were not received by the non-access point device; and / or If the first AP device does not receive the cache control status information after reordering the data packets to be transmitted, the data packets include the data packets cached by the first AP device.

84. The communications device of claim 83 wherein, If the first AP device receives buffer control status information after reordering the data packets to be transmitted, the communication device further includes a second processing unit. The second processing unit is used to delete data packets stored in the transmission buffer that indicate that the non-access point device has successfully received them, as indicated by the buffer control status information.

85. The communication device of any of claims 65-78, wherein, The first device is the first AP device, and the downlink data is carried in data packets. If the first AP device receives the buffer control status information after reordering the data packets to be transmitted, the first AP device will not send the buffer control status information to the non-access point device to indicate that the non-access point device has successfully received the data packets.

86. The communications device of claim 85 wherein, The data packets that the non-access point device has successfully received include data packets that the non-access point device has successfully received but has not sent a confirmation of receipt to the first AP device.

87. The communication device of any of claims 65-67, wherein, The first device is the non-access point device, the downlink data is carried in data packets, and the communication protocol context is used to indicate one or more of the following: The processing status information of the data packet corresponding to the first TID; The SN corresponding to the last data packet delivered to the higher layer in the data packet corresponding to the first TID; The PN corresponding to the last data packet in the data packet that has been delivered to the higher layer in the first TID; Control status information of the receive buffer corresponding to the reordered data packets; The data packet corresponds to the scoreboard context control status information.

88. The communications device of claim 87 wherein, The processing status information of the data packet corresponding to the first TID is used to indicate one or more of the following: Has the data packet corresponding to the first TID been successfully received? Whether the data packet corresponding to the first TID is transmitted to a higher layer; Whether the data packet corresponding to the first TID is cached in the receive buffer; Whether to stop processing the data packets from the first AP device.

89. The communication device of claim 88 wherein, The processing status information of the data packet corresponding to the first TID is indicated by the second indication information as to whether the data packet from the first AP device is no longer being processed. The second indication information is used to indicate that the data packet corresponding to the first TID has been cleared in the receive buffer.

90. The communication device of any of claims 87-89, wherein, The cache control status information includes one or more of the following: The first parameter corresponding to the first TID or the first TA is used to indicate the SN corresponding to the first data packet that the non-access point device expects to receive after the data packets to be transmitted are reordered by the second AP device. The second parameter corresponding to the first TID or the first TA, the second parameter is used to indicate the highest SN corresponding to the data packet expected to be received in the receiving window, the receiving window is used to receive the data packet to be transmitted after being reordered by the second AP device; Information used for the cache record bitmap corresponding to the reordered data packet.

91. The communication device of any of claims 87-90, wherein, The scoreboard context control status information corresponding to the data packet is used to indicate one or more of the following: The third parameter is used to indicate the lowest SN recorded in the BA record bitmap of the non-access point device; The fourth parameter is used to indicate the highest SN recorded in the BA record bitmap of the non-access point device; The bitmap corresponding to each SN in the BA record bitmap of the non-access point device.

92. The communication device of any of claims 87-91, wherein, The communication protocol context is carried in one or more of the following: roaming notification frame, roaming request frame, and communication protocol context status notification frame.

93. The communication device of any of claims 87-92, wherein, The transmission of the communication protocol context satisfies one or more of the following: This is done before transmitting the roaming request frame; This is performed after the roaming request frame is transmitted; This is performed before transmitting the roaming response frame; This is done simultaneously with the transmission of the roaming response frame.

94. The communication device of any of claims 87-93, wherein, The second device is the first AP device, and the communication device further includes: Before the first device receives the roaming response frame, the receiving unit is used to receive the data packets sent by the second device.

95. The communication device of any of claims 87-93, wherein, The communication device also includes: The third processing unit is used to determine, based on the type of the roaming response frame, whether to not receive the data packet sent by the first AP device or to continue receiving the data packet sent by the first AP device before the roaming timer expires.

96. The communications device of claim 95, wherein, If the roaming response frame is a reassociation response frame, the first device does not receive the data packet sent by the first AP device, wherein the reassociation response frame is used to indicate that the non-access point device has successfully reassociated with the second AP; and / or If the type of the roaming response frame is a link reconfiguration frame, the first device continues to receive the data packet sent by the first AP device before the roaming timer expires, wherein the link reconfiguration frame is used to indicate that the link between the first device and the second AP has been successfully established.

97. The communication device of any of claims 87-96, wherein, The communication device also includes: The fourth processing unit is used to determine whether to delete the link between the first device and the first AP device based on the reception status of the data packet.

98. The communications device of claim 97 wherein, If the data packet reception status indicates that the last data packet sent by the first AP device and the data packets transmitted before the last data packet have been successfully received, then the first device deletes the link between the first device and the first AP device.

99. The communications device of claim 98 wherein, If, before the roaming timeout timer expires, the data packet reception status indicates that the last data packet sent by the first AP device and all data packets transmitted before the last data packet have been successfully received, then the first device deletes the link between the first device and the first AP device.

100. The communication device of any of claims 87-99, wherein, The transmission key for the data packets corresponding to the link between the first device and the first AP device is the same as the transmission key for the data packets corresponding to the link between the first device and the second AP device. The communication device further includes: After the first device receives the roaming response frame and before the link between the first device and the first AP device is deleted, the fifth processing unit is configured to receive the data packet sent by the first AP device and / or the second AP device based on the transmission key.

101. The communication device of any of claims 87-100, wherein, The transmission key for the data packets corresponding to the link between the first device and the first AP device is different from the transmission key for the data packets corresponding to the link between the first device and the second AP device. The communication device further includes: After the first device receives the roaming response frame, the sixth processing unit is used to receive the data packet sent by the second AP device based on the transmission key of the data packet corresponding to the link between the first device and the second AP device.

102. The communication device of any of claims 87-101, wherein, If the first AP device and the second AP device do not support the migration of the data packets, the communication device further includes: If the SN corresponding to the data packet of the first TID cached in the receive buffer of the first device is less than the target SN, then the seventh processing unit is used to clear all data packets corresponding to the first TID in the receive buffer, wherein the target SN is the highest SN corresponding to the data packet of the first TID sent by the first AP device.

103. A method of communication, comprising: include: The second device receives first information sent by the first device. The first information is associated with the communication protocol context of downlink data. The communication protocol of the downlink data is for non-access point devices. The non-access point devices are non-access point devices that roam from the first AP device to the second AP device. Wherein, if the first device is the non-access point device, then the second device is either the first AP device or the second AP device, or If the first device is the first AP device or the second AP device, then the second device is the non-access point device; or If the first device is the first AP device, then the second device is the second AP device.

104. The method of claim 103, wherein, The first information carries some or all of the information in the communication protocol context of the downlink data.

105. The method of claim 103 or 104, wherein, The communication protocol context includes the BA protocol context and / or the RSNA confidentiality and integrity protocol context.

106. The method of any one of claims 103-105, wherein, The first device is either the first AP device or the second AP device, the downlink data is carried in data packets, and the communication protocol context is used to indicate one or more of the following: The SN corresponding to the data packet to be assigned to the first-stream identifier (TID); The SN corresponding to the last data packet that arrives in the buffer queue in the data packet corresponding to the first TID; The SN corresponding to the latest data packet sent by the first AP device in the data packet corresponding to the first TID; Control status information of the send buffer corresponding to the first TID; The PN corresponding to the last data packet to arrive in the buffer queue in the data packet corresponding to the first TID; The minimum threshold for PN depletion and / or the maximum threshold for PN depletion associated with the key corresponding to the first TID; Do the first AP device and / or the second AP device support packet migration via DS? The migration status of the data packet; Is the transmission key of the data packet corresponding to the first AP device the same as the transmission key of the data packet corresponding to the second AP device? 107. The method of claim 106, wherein, The migration status of the data packet is used to indicate whether the data packet has been successfully migrated from the first AP device to the second AP device.

108. The method of claim 106 or 107, wherein, The control status information of the transmit buffer corresponding to the first TID is used to indicate one or more of the following: The starting sequence number corresponding to the sending buffer; The size of the buffer corresponding to the send buffer; Whether the data packets cached in the sending buffer have been successfully sent.

109. The method of claim 108, wherein, The control status information indicates, through the record bitmap corresponding to the downlink, whether the data packets cached in the transmission buffer have been successfully sent.

110. The method of any one of claims 106-109, wherein, The communication protocol context is carried in roaming response frames and / or communication protocol context status notification frames.

111. The method of any one of claims 106-110, wherein, The transmission of the communication protocol context satisfies one or more of the following: This is done before transmitting the roaming request frame; This is performed after the roaming request frame is transmitted; This is performed before transmitting the roaming response frame; This is done simultaneously with the transmission of the roaming response frame.

112. The method of any one of claims 105-111, wherein, The first field contains one or more of the following: the SN corresponding to the data packet to be allocated for the first flow identifier (TID); the SN corresponding to the last data packet to arrive in the buffer queue in the data packet corresponding to the first TID; and the SN corresponding to the latest data packet sent by the first AP device in the data packet corresponding to the first TID. The first field is used to carry block acknowledgment protocol related parameters.

113. The method of any one of claims 105-112, wherein, One or more of the following are carried in one or more fields in the second field: the PN corresponding to the last data packet that arrives in the buffer queue in the data packet corresponding to the first TID; the minimum threshold for PN exhaustion associated with the key corresponding to the first TID; and the maximum threshold for PN exhaustion associated with the key corresponding to the first TID. The second field is used to carry parameters for security association.

114. The method of any one of claims 103-113, wherein, The second device is a non-access point device, and the first information is used to indicate the migration status of the communication protocol context of the downlink data.

115. The method of claim 114, wherein, The migration status of the communication protocol context is used to indicate whether the communication protocol context has been successfully migrated from the first AP device to the second AP device.

116. The method as described in claim 114 or 115, characterized in that, The first information is carried in the roaming response frame.

117. The method according to any one of claims 103-116, characterized in that, The first device is the first AP device, the second device is the non-access point device, and the method further includes: The second device receives a first indication information sent by the first device. The first indication information is used to indicate whether the first AP device has a data packet to be sent to the non-access point device, and the data packet carries the downlink data.

118. The method as described in claim 117, characterized in that, The first indication information is carried in more data subfields of the frame control field.

119. The method according to any one of claims 103-116, characterized in that, The first device is the first AP device, the second device is the second AP device, and the first AP device and the second AP device support the migration of data packets carrying the downlink data. The method further includes: If the first device has a data packet that is to be sent to the non-access point device, then the second device receives the data packet sent to the first device.

120. The method as described in claim 119, characterized in that, If the first AP device receives buffer control status information for the reordered data packets to be transmitted, the data packets include data packets in the data packets buffered by the first AP device that were not received by the non-access point device; and / or If the first AP device does not receive the cache control status information after reordering the data packets to be transmitted, the data packets include the data packets cached by the first AP device.

121. The method according to any one of claims 103-105, characterized in that, The first device is the non-access point device, the downlink data is carried in data packets, and the communication protocol context is used to indicate one or more of the following: The processing status information of the data packet corresponding to the first TID; The SN corresponding to the last data packet delivered to the higher layer in the data packet corresponding to the first TID; The PN corresponding to the last data packet in the data packet that has been delivered to the higher layer in the first TID; Control status information of the receive buffer corresponding to the reordered data packets; The data packet corresponds to the scoreboard context control status information.

122. The method as described in claim 121, characterized in that, The processing status information of the data packet corresponding to the first TID is used to indicate one or more of the following: Has the data packet corresponding to the first TID been successfully received? Whether the data packet corresponding to the first TID is transmitted to a higher layer; Whether the data packet corresponding to the first TID is cached in the receive buffer; Whether to stop processing the data packets from the first AP device.

123. The method as described in claim 122, characterized in that, The processing status information of the data packet corresponding to the first TID is indicated by the second indication information as to whether the data packet from the first AP device is no longer being processed. The second indication information is used to indicate that the data packet corresponding to the first TID has been cleared in the receive buffer.

124. The method according to any one of claims 121-123, characterized in that, The cache control status information includes one or more of the following: The first parameter corresponding to the first TID or the first TA is used to indicate the SN corresponding to the first data packet that the non-access point device expects to receive after the data packets to be transmitted are reordered by the second AP device. The second parameter corresponding to the first TID or the first TA, the second parameter is used to indicate the highest SN corresponding to the data packet expected to be received in the receiving window, the receiving window is used to receive the data packet to be transmitted after being reordered by the second AP device; Information used for the cache record bitmap corresponding to the reordered data packet.

125. The method according to any one of claims 121-124, characterized in that, The scoreboard context control status information corresponding to the data packet is used to indicate one or more of the following: The third parameter is used to indicate the lowest SN recorded in the BA record bitmap of the non-access point device; The fourth parameter is used to indicate the highest SN recorded in the BA record bitmap of the non-access point device; The bitmap corresponding to each SN in the BA record bitmap of the non-access point device.

126. The method according to any one of claims 121-125, characterized in that, The communication protocol context is carried in one or more of the following: roaming notification frame, roaming request frame, and communication protocol context status notification frame.

127. The method according to any one of claims 121-126, characterized in that, The transmission of the communication protocol context satisfies one or more of the following: This is done before transmitting the roaming request frame; This is performed after the roaming request frame is transmitted; This is performed before transmitting the roaming response frame; This is done simultaneously with the transmission of the roaming response frame.

128. The method according to any one of claims 121-127, characterized in that, The second device is the first AP device, and the method further includes: Before the first device receives the roaming response frame, the first AP device sends the data packet to the first device.

129. A communication device, characterized in that, The device includes a transceiver, a memory, and a processor. The memory stores a program, and the processor invokes the program in the memory and controls the transceiver to receive or transmit signals so that the communication device performs the method as described in any one of claims 1-64.

130. An apparatus, characterized in that, Includes a processor for calling a program from memory to cause the device to perform the method as described in any one of claims 1-64.

131. A chip, characterized in that, Includes a processor for calling a program from memory, causing a device on which the chip is mounted to perform the method as described in any one of claims 1-64.

132. A computer-readable storage medium, characterized in that, It contains a program that causes a computer to perform the method as described in any one of claims 1-64.

133. A computer program product, characterized in that, Includes a program that causes a computer to perform the method as described in any one of claims 1-64.

134. A computer program, characterized in that, The computer program causes the computer to perform the method as described in any one of claims 1-64.

Images