Migration methods and apparatuses, and devices and storage medium

Abstract

The present application belongs to the technical field of WiFi communications. Disclosed are migration methods and apparatuses, and devices and a storage medium. A migration method comprises: receiving a first frame, the first frame being used for indicating context information for migration from a first access point device to a second access point device and / or the migration status of the context information, wherein the context information is context for an uplink data communication protocol of a non-access-point device. Thus, non-access-point devices are enabled to learn the migration status of data communication context information during roaming in a timely manner, thereby avoiding the loss and / or delay of uplink data in the roaming process of the non-access-point devices as much as possible.

Description

Migration methods, apparatus, equipment and storage media Technical Field

[0001] This application relates to the field of Wireless Fidelity (WiFi) communication technology, and particularly to a migration method, apparatus, device, and storage medium. Background Technology

[0002] During the roaming process initiated by a non-access point device, uplink data sent from the non-access point device to the access point device may be lost and / or delayed. Summary of the Invention

[0003] This application provides a migration method, apparatus, device, and storage medium. The technical solution is as follows:

[0004] On one hand, embodiments of this application provide a migration method, which is executed by a non-access point device, the method comprising:

[0005] Receive a first frame, the first frame being used to indicate context information and / or the migration status of the context information from the first access point device to the second access point device;

[0006] The context information refers to the context of the uplink data communication protocol for the non-access point device.

[0007] On the other hand, embodiments of this application provide a migration method, which is executed by a first access point device, and the method includes:

[0008] Send a first frame to a non-access point device, the first frame being used to indicate context information and / or the migration status of the context information from the first access point device to the second access point device;

[0009] The context information refers to the context of the uplink data communication protocol for the non-access point device.

[0010] On the other hand, embodiments of this application provide a migration method, which is executed by a second access point device, and the method includes:

[0011] Send a first frame to a non-access point device, the first frame being used to indicate context information and / or the migration status of the context information from the first access point device to the second access point device;

[0012] The context information refers to the context of the uplink data communication protocol for the non-access point device.

[0013] On the other hand, embodiments of this application provide a migration method, which is performed by a non-access point device, the method comprising:

[0014] Send a third frame, the third frame being used to indicate the migration context information from the first access point device to the second access point device;

[0015] The context information refers to the context of the uplink data communication protocol for the non-access point device.

[0016] On the other hand, embodiments of this application provide a migration apparatus, the apparatus comprising:

[0017] A receiving module is configured to receive a first frame, wherein the first frame is used to indicate context information and / or the migration status of the context information from the first access point device to the second access point device.

[0018] The context information refers to the context of the uplink data communication protocol for the non-access point device.

[0019] On the other hand, embodiments of this application provide a migration apparatus, the apparatus comprising:

[0020] The sending module is used to send a first frame to a non-access point device, wherein the first frame is used to indicate context information and / or the migration status of the context information from the first access point device to the second access point device.

[0021] The context information refers to the context of the uplink data communication protocol for the non-access point device.

[0022] On the other hand, embodiments of this application provide a migration apparatus, the apparatus comprising:

[0023] A sending module is used to send a third frame, the third frame being used to indicate the migration context information from the first access point device to the second access point device;

[0024] The context information refers to the context of the uplink data communication protocol for the non-access point device.

[0025] On the other hand, embodiments of this application provide a non-access point device, the non-access point device comprising:

[0026] processor;

[0027] A transceiver connected to the processor;

[0028] Memory used to store the processor's executable instructions;

[0029] The processor is configured to load and execute executable instructions to implement the migration methods described above.

[0030] On the other hand, embodiments of this application provide a first access point device, the first access point device comprising:

[0031] processor;

[0032] A transceiver connected to the processor;

[0033] Memory used to store the processor's executable instructions;

[0034] The processor is configured to load and execute executable instructions to implement the migration methods described above.

[0035] On the other hand, embodiments of this application provide a second access point device, the second access point device comprising:

[0036] processor;

[0037] A transceiver connected to the processor;

[0038] Memory used to store the processor's executable instructions;

[0039] The processor is configured to load and execute executable instructions to implement the migration methods described above.

[0040] On the other hand, embodiments of this application provide a computer-readable storage medium storing a computer program that is executed by a processor to implement the migration methods described above.

[0041] On the other hand, embodiments of this application provide a chip including programmable logic circuits and / or program instructions, which, when the chip is run on a non-access point device, are used to implement the migration methods described above for various aspects executed by the non-access point device.

[0042] On the other hand, embodiments of this application provide a chip that includes programmable logic circuits and / or program instructions. When the chip is run on a first access point device, it is used to implement the migration methods of the various aspects executed by the first access point device described above.

[0043] On the other hand, embodiments of this application provide a chip including programmable logic circuits and / or program instructions, which, when the chip is run on a second access point device, is used to implement the migration methods of the various aspects executed by the second access point device described above.

[0044] On the other hand, embodiments of this application provide a computer program product, the computer program product including computer instructions stored in a computer-readable storage medium; a processor of a non-access point device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the non-access point device to implement the migration methods of the above aspects.

[0045] On the other hand, embodiments of this application provide a computer program product, the computer program product including computer instructions stored in a computer-readable storage medium; the processor of a first access point device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the first access point device to implement the migration methods of the above aspects.

[0046] On the other hand, embodiments of this application provide a computer program product, the computer program product including computer instructions stored in a computer-readable storage medium; the processor of a second access point device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the second access point device to implement the migration methods of the above aspects.

[0047] On the other hand, embodiments of this application provide a computer program executed by a processor of a non-access point device to implement the migration methods described above for various aspects executed by the non-access point device.

[0048] On the other hand, embodiments of this application provide a computer program executed by a processor of a first access point device to implement the migration methods of the various aspects executed by the first access point device described above.

[0049] On the other hand, embodiments of this application provide a computer program executed by the processor of a second access point device to implement the migration methods of the various aspects executed by the second access point device described above.

[0050] The technical solutions provided in this application embodiment may have the following beneficial effects:

[0051] By having the non-access point device receive the first frame, it can promptly learn about the migration of data communication context information during roaming (before / during / after roaming). This facilitates timely synchronization of uplink data transmission between the non-access point device and the first and / or second access point devices, ensuring the continuity of data transmission during roaming, minimizing packet loss or achieving zero packet loss, and reducing packet transmission latency. Attached Figure Description

[0052] Figure 1 shows a schematic diagram of the multi-link configuration provided in an embodiment of this application;

[0053] Figure 2 shows a schematic diagram of a site roaming method provided in an embodiment of this application;

[0054] Figure 3 shows a schematic diagram of the communication system provided in an embodiment of this application;

[0055] Figure 4 shows a flowchart of a data transmission and reception method during roaming provided in an embodiment of this application;

[0056] Figure 5 shows a schematic diagram of a distribution system provided in an embodiment of this application;

[0057] Figure 6 shows a flowchart of a migration method provided in an embodiment of this application;

[0058] Figure 7 shows a flowchart of a migration method provided in an embodiment of this application;

[0059] Figure 8 shows a flowchart of a migration method provided in an embodiment of this application;

[0060] Figure 9 shows a flowchart of a migration method provided in an embodiment of this application;

[0061] Figure 10 shows a schematic diagram of a migration method provided in an embodiment of this application;

[0062] Figure 11 shows a schematic diagram of a migration method provided in an embodiment of this application;

[0063] Figure 12 shows a flowchart of a migration method provided in an embodiment of this application;

[0064] Figure 13 shows a flowchart of a migration method provided in an embodiment of this application;

[0065] Figure 14 shows a structural block diagram of a migration device provided in an embodiment of this application;

[0066] Figure 15 shows a structural block diagram of a migration device provided in an embodiment of this application;

[0067] Figure 16 shows a structural block diagram of a migration device provided in an embodiment of this application;

[0068] Figure 17 shows a structural block diagram of a migration device provided in an embodiment of this application;

[0069] Figure 18 shows a schematic diagram of the structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0070] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. Exemplary embodiments will be described in detail here, examples of which are illustrated in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. All other embodiments obtained by those skilled in the art without inventive effort in relation to the embodiments of this application are within the scope of protection of this application. The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The singular forms “a,” “the,” and “the” used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more associated listed items. It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word “if” as used herein may be interpreted as “when”, “when”, or “in response to determination”.

[0071] Next, let's introduce the relevant technologies:

[0072] Multi-link operation

[0073] The relevant standards define Multi-Link Operation (MLO), Access Point Multi-Link Device (AP MLD) with multi-link operation capability, and non-Access Point Multi-Link Device (non-AP MLD). AP MLD and non-AP MLD can establish multiple links on multiple different frequency bands / channels.

[0074] As shown in Figure 1, three links are established between the AP MLD and the non-AP MLD at 2.4 GHz, 5 GHz, and 6 GHz. These are, for example, 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 all affiliated APs of the AP MLD. Similarly, non-AP STA 1 operating on Link 1, non-AP STA 2 operating on Link 2, and non-AP STA 3 operating on Link 3 are all affiliated non-AP STAs of the non-AP MLD.

[0075] • Logical AP MLD (or Roaming MLD)

[0076] As shown in Figure 2, Qualcomm's IEEE proposal suggests treating multiple non-collocated Access Points (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 multi-link operation architecture allows the AP MLD to use different affiliated APs and different links to provide services to the STA, thus better enabling uninterrupted roaming for the STA. As shown in Figure 2, STA x uses multiple links to connect to AP 1 and AP 2 respectively. When STA x sends a move request, the link connection to AP 1 is disconnected, but the link connection to AP 2 is not affected, thus improving the STA's mobility support.

[0077] • Fast Basic Service Set (BSS) Transition (FT)

[0078] The goal of rapid BSS transition is to reduce the duration of connection loss between a Station (STA) and the Distribution System (DS) during BSS transition, or the duration of connection loss between a non-AP MLD and the DS during BSS transition. The FT protocol, part of the reassociation service, applies only to transitions between APs or AP MLDs within the same Extended Service Set (ESS) / mobility domain for either STA or non-AP MLD. APs publish functions and policies supporting the FT protocol and methods. FT functions are published in beacon and probe response frames by including a Mobility Domain Element (MDE). The MDE, published in beacon and probe response frames, indicates the Mobility Domain Identifier (MDID), FT capabilities, and FT policies.

[0079] The FT protocol requires the exchange of information between the STA (called the Fast BSS Transition Originator, FTO) and the AP (called the Fast BSS Transition Responder, FTR) or between a non-AP MLD (called the FT Originator (FTO)) and the AP MLD (called the FT Responder (FTR)). The initial exchange is called the FT Initial Mobile Domain Association. Subsequent reassociation with FTRs within the same mobile domain can use the FT protocol.

[0080] The FT defines two FT protocols:

[0081] • FT Protocol. This protocol is executed during the conversion from FTO to the target FTR, and no resource requests are required before the conversion.

[0082] • FT Resource Request Protocol. This protocol is executed when the FTO needs to request resources before transformation.

[0083] For an FTO that moves to a target FTR using the FT protocol, message exchange is performed using one of the following two methods:

[0084] • Wireless. The FTO communicates directly with the target FTR, is IEEE 802.11 certified, and uses the FT authentication algorithm.

[0085] • Over-the-DS. The FTO communicates with the target FTR via the current FTR. Communication between the FTO and the target FTR takes place in the FT Action frame 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". The current AP translates between the two encapsulations.

[0086] Robust Secure Network Association (RSNA) confidentiality and integrity protocol

[0087] The Wi-Fi standard defines the following RSNA data confidentiality and integrity protocols: Counter Mode (CTR) with Cipher-Block Chaining Message Authentication Code (CBC-MAC) Protocol (CTR with CBC-MAC Protocol, CCMP) and Galois / Counter Mode Protocol (GCMP).

[0088] 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 MAC Protocol Data Unit (MPDU) data fields and selected portions of the IEEE 802.11 MPDU header. CCM is a general mode that can be used with any block-oriented encryption algorithm. CCM requires a new ephemeral key for each session. CCM also requires that each frame protected by the given ephemeral key has a unique nonce value. Reusing a nonce value with the same ephemeral key will invalidate all security guarantees.

[0089] For secure Protocol Version 0 (PV0) MPDUs, CCMP encrypts the frame body field of the plaintext MPDU and encapsulates the resulting ciphertext. By adding a packet number (PN), a new non-zero PN is obtained for each MPDU, so that the PN will not be repeated for the same temporary key.

[0090] The PN value is assigned sequentially to each MPDU number. Each sender STA not attached to an MLD should maintain a single PN (48-bit counter) for each Pairwise Transient Key Security Association (PTKSA) and Group Temporal Key Security Association (GTKSA). Each sender STA attached to an MLD should use either the PN (48-bit counter) maintained by the MLD for the PTKSA, or the PN maintained by the STA for the GTKSA. The PN should be implemented as a strictly incrementing 48-bit integer, initialized to 0 when the corresponding temporary key is initialized or refreshed (via key update).

[0091] The PN value increments by a positive number for each MPDU. For constituent MPDUs of fragmented MAC Service Data Units (MSDUs), aggregated MSDUs (A-MSDUs), and 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 Partial Stream Identifier (PTID) will never be repeated.

[0092] When the PN space is exhausted (i.e., the PN exceeds the thresholds defined by the minimum and maximum PN exhaustion thresholds), the available options are to replace the corresponding key or terminate communication. 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 for transmission through all affiliated STAs.

[0093] The receiver shall discard any received data frame whose PN is less than or equal to the replay counter value 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 affiliated STA, the receiver shall discard any received data frame whose PN is less than or equal to the replay counter value associated with the sender MLD MAC address, the receiver MLD MAC address (personal or group address), and the priority value of the received MPDU.

[0094] For a separate 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.

[0095] • Block confirmation mechanism

[0096] The Block Ack (BA) mechanism improves channel efficiency by aggregating multiple acknowledgments into a single frame. The STA that sends data using the BA mechanism is called the initiator, and the intended receiving station is called the receiver.

[0097] Besides GLK-GCR block acknowledgments or the use of an extended mechanism like Unsolicited Block Acknowledgments, the block acknowledgment mechanism is initialized by exchanging ADDBA request / response frames. After initialization, the originator can transmit a series of QoS data frames for a block to the recipient. A block can be started in a polled Transmission Opportunity (TXOP), a scheduled polling (SP), or by winning a TXOP through Enhanced Distributed Channel Access (EDCA). The number of data frames in a block is finite, as is the amount of state retained by the recipient. MPDUs within a block's frames are acknowledged by BlockAck frames, which are requested by BlockAckReq frames.

[0098] The initiator includes a send buffer control that uses WinStartO and WinSizeO to submit MPDUs for transmission and releases the send buffer upon receiving a BlockAck frame from the receiver. WinStartO is the starting sequence number of the send window, and WinSizeO is the number of buffers negotiated in the block acknowledgment protocol. The initiator can transmit Quality of Service (QoS) data frames with Flow Identifiers (TIDs) matching the block return protocol in any order, as long as their sequence numbers are within the current transmission window.

[0099] The receiver contains receive reordering buffer control for each TA / TID, including 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. It is also responsible for identifying and discarding duplicate frames (i.e., frames with the same sequence number).

[0100] For MLDs, they follow the mechanism defined by the block acknowledgment operation, as well as the additional rules defined by the block acknowledgment process in multi-link operations. The MLD that sends data using the block acknowledgment mechanism is called the sender MLD, and the MLD that is the intended recipient of that data is called the receiver MLD.

[0101] 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 running on the enabled link, depending on the power state of the non-AP STAs running 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 running on the enabled link, with the ADDBA response frame depending on the power state of the non-AP STAs running on that link. The receiving MLD can choose to accept or reject the request. If the receiving MLD accepts the request, the BACK is established between the sending and receiving MLDs for the TID specified in the ADDBA frame.

[0102] 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 rules and multi-link power management rules.

[0103] 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 each block return, in order to submit MPDUs for transmission on links restricted by flow identifier-to-link mapping rules. 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.

[0104] The receiver MLD is for each [unclear - possibly a specific type of device] under the block acknowledgment protocol.<peer MLD,TID> The group maintains a single, shared 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. It is also 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.

[0105] • Block Ack Agreement context elements and related field definitions

[0106] The Block Acknowledgment Protocol (BAP) scenario (or context) element contains information about the BAP scenarios or status that a specific MLD has established and maintained with one or more peer MLDs. It mainly includes the BAP scenario parameter control subfield and the BAP scenario parameter set list subfield, as shown in Table 1 below.

[0107] Table 1

[0108] The element identifier field, length field, and element identifier extension field in the block acknowledgment protocol scenario elements adopt the general definitions of elements in the IEEE 802.11 standard. The format of the block acknowledgment protocol scenario parameter control field is shown in Table 2 below.

[0109] Table 2

[0110] The definitions of each subfield in the block acknowledgment protocol scenario parameter control domain are as follows:

[0111] The MLD MAC address subfield indicates the MAC address of the MLD containing the block acknowledgment protocol scenario described by the block acknowledgment protocol scenario element. The MLD MAC address can be the MLD address of a roaming MLD.

[0112] Whether the Peer MLD is the same MLD subfield indicates whether the peer MLDs targeted by the block confirmation protocol scenario scenario described by the block confirmation protocol scenario element are the same MLD. When its value is 0, it means that the peer MLDs targeted by the block confirmation protocol scenario scenario described by the block confirmation protocol scenario element are the same MLD, and when its value is 1, it means that the peer MLDs targeted by the block confirmation protocol scenario scenario described by the block confirmation protocol scenario element are multiple MLDs.

[0113] The Peer MLD MAC address indicates the MAC address of the peer MLD to which the block acknowledgment protocol scenario described by the block acknowledgment protocol scenario element is targeted. When the value of "Whether Peer MLD is the same MLD subfield" is 0, the Peer MLD MAC address subfield exists in the block acknowledgment protocol scenario parameter control field; when the value of "Whether Peer MLD is the same MLD subfield" is 1, the Peer MLD MAC address subfield does not exist in the block acknowledgment protocol scenario parameter control field.

[0114] The Single Block Acknowledgment Protocol Scenario Parameter Set Quantity subfield is a 16-bit unsigned integer indicating the number of single block acknowledgment protocol scenario parameter set subfields in the Block Acknowledgment Protocol Scenario Parameter Set List field.

[0115] The Block Acknowledgment Protocol (BAP) scenario parameter set list field is shown in Table 3 below. This field consists of one or more individual BAP scenario parameter sets and padding subfields.

[0116] Table 3

[0117] The parameter set format for a single block acknowledgment protocol scenario is shown in Tables 4 and 5 below:

[0118] Table 4 (The MLD in the Block Confirmation Protocol scenario is the initiator MLD role)

[0119] Table 5 (The MLD in the Block Acknowledgment Protocol scenario is the receiver MLD role)

[0120] The MLD role subfield indicates the role of the MLD in the block acknowledgment protocol scenario described by the single block acknowledgment protocol scenario parameter set within that block acknowledgment protocol. A value of 0 indicates that the MLD in the block acknowledgment protocol scenario described by the single block acknowledgment protocol scenario parameter set is the initiator MLD in the block acknowledgment protocol; a value of 1 indicates that the MLD in the block acknowledgment protocol scenario described by the single block acknowledgment protocol scenario parameter set is the receiver MLD in the block acknowledgment protocol. The format of the single block acknowledgment protocol scenario parameter set is shown in Table 4 when the MLD in the block acknowledgment protocol scenario is the initiator role; the format is shown in Table 5 when the MLD in the block acknowledgment protocol scenario is the receiver role.

[0121] The Peer MLD MAC address indicates the MAC address of the peer MLD to which the block acknowledgment protocol scenario described by the subfield of the single block acknowledgment protocol scenario parameter set is targeted.

[0122] The Block Acknowledgment Parameter Set subfield indicates the set of parameters related to the established block acknowledgment protocol corresponding to the block acknowledgment protocol scenario described by the individual block acknowledgment protocol scenario subfield. See Table 6 below:

[0123] Table 6

[0124] The Block Acknowledgment Timeout subfield contains the 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.

[0125] The Send Window Start Sequence Number (WinStartO) subfield is a send buffer control parameter that indicates the start sequence number of the send window.

[0126] The transmit window size (WinSizeO) subfield is a transmit buffer control parameter that indicates the buffer size of the transmit window negotiated in the block acknowledgment protocol. Specifically, the transmit window size (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 STA transmits the Block Ack Parameter Set field), the number of bytes each buffer can hold is equal to the maximum size of the MSDU. When the STA supported A-MSDU field is equal to 1, the number of bytes each buffer can hold is equal to the maximum size of the a-MSDU supported by the STA.

[0127] The last data unit SN subfield (or subfield) transmitted to the upper layer indicates the last (or latest) SN number of the MPDU and MMPDU that the receiver of the corresponding BA protocol has transmitted from the receiver's buffer to the upper layer (or DS). Let this SN be SN(TID, UL.latest).

[0128] The Receive Buffer Start Sequence Number (WinStartB) is a control parameter for the Receive Reordering Buffer. It 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.

[0129] The receive window size (WinSizeB) is a control parameter for the receive reordering buffer, indicating the size of the receive window.

[0130] The record bitmap start sequence number (WinStartR) is a Scoreboard Context Control parameter, a 12-bit unsigned integer start sequence number that indicates the lowest sequence number position in the block confirmation record bitmap (indexed by sequence number).

[0131] Record the maximum sequence number of the bitmap (WinEndR), which represents the highest sequence number of the current transmission window.

[0132] Record bitmap size (WinSizeR) is a Scoreboard Context Control parameter, the maximum transfer window size, set to the smaller of the values ​​of BitmapLength (11ax) and the Buffer size field of the relevant ADDBA response frame in the Establish Block Return Protocol.

[0133] The record bitmap subfield indicates a block acknowledgment bitmap value 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, with the starting sequence number being a 12-bit unsigned integer.

[0134] • Security Association context elements and related domain definitions

[0135] The security association scenario element contains the sender PN configuration and PN counter status information and / or receiver replay detection scenario and replay counter status information that a specific MLD has 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 scenario element mainly includes the security association scenario parameter control field and the security association scenario parameter set list field, as shown in Table 7 below.

[0136] Table 7

[0137] The element identifier field, length field, and element identifier extension field in the security association scenario elements adopt the general definitions of elements in the IEEE 802.11 standard. The format of the parameter control field for the security association scenario is shown in Table 8 below:

[0138] Table 8

[0139] The format of the parameter set list field for security-related scenarios is shown in Table 9 below:

[0140] Table 9

[0141] The parameter set format for security-related scenarios is shown in Tables 10 and 11 below:

[0142] Table 10 (Parameter Set Format for Receiver Replay Scenario)

[0143] Table 11 (Parameter Set Format for Receiver Replay Scenario)

[0144] The MLD Role subfield indicates the role of the MLD within the security-associated scenario described by the Security-Associated Scenario Parameter Set subfield in that security-associated scenario. Specifically, a value of 0 in the MLD Role subfield indicates that the MLD within the security-associated scenario described by the Security-Associated Scenario Parameter Set subfield is acting as a receiver MLD, meaning it describes the receiver's replay scenario parameter set. A value of 1 in the MLD Role subfield indicates that the MLD within the security-associated scenario described by the Security-Associated Scenario Parameter Set subfield is acting as a sender MLD, meaning it describes the sender's PN counter scenario parameter set.

[0145] 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 the table. 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.

[0146] The PTKSA / GTKSA / TPKSA field values ​​and their meanings are shown in Table 12 below:

[0147] Table 12

[0148] • Data communication context information migration status notification frame format definition

[0149] The Data Communication Context Information Migration Status Notification Frame is used by the current access point device or the target access point device to notify roaming non-access point devices of the data communication context information migration status, including block acknowledgment protocol scenario (or context) information and / or security association scenario (or context) information that has been migrated. The Data Communication Context Information Migration Status Notification Frame is based on the Action frame format defined in the IEEE 802.11 specification, and the information contained in its Action field is shown in Table 13 below.

[0150] Table 13

[0151] The category field is defined according to the relevant definition in the IEEE 802.11 standard.

[0152] The protected UHR action field contains 1 byte, which follows the category field and is used to distinguish the UHR action frame format.

[0153] The dialogue token field is set to a non-zero value by the AP MLD of the data communication context information migration status notification frame.

[0154] The definition of the block confirmation protocol scenario element is shown above. The block confirmation protocol scenario element carries the block confirmation protocol context information or migration status information that has been migrated.

[0155] The definition of security association scenario elements is shown above. These elements carry security association context information or migration status information that has been successfully migrated.

[0156] Figure 3 shows a schematic diagram of a wireless communication system 10 provided in an exemplary embodiment of this application. The wireless communication system 10 includes stations and access points. In this application, STAs include access point stations (AP STAs) and / or non-access point stations (non-AP STAs), where an AP STA can be simply referred to as an AP. Communication between STAs can be implemented as communication between an AP and a non-AP STA, communication between two non-AP STAs, or communication between a STA and a peer STA. A peer STA refers to a device communicating with the STA from the other end; a peer STA may be an AP or a non-AP STA.

[0157] Figure 3 illustrates the wireless communication system 10, which includes an AP 110 and a non-AP STA 120.

[0158] The AP 110 is a device deployed in a Wireless Local Area Network (WLAN) / Wireless Fidelity (Wi-Fi) system to provide wireless communication capabilities to STAs (Stations). The AP 110 acts as a bridge connecting wired and wireless networks, its main function being to connect various wireless network clients together and then connect the wireless network to the Ethernet. The AP 110 can be a terminal device or network device (such as a router) with a WLAN / Wi-Fi chip.

[0159] In some embodiments, AP 110 can be a device that supports various current and future Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of WLAN standards, including 802.11be, 802.11bn, 802.11ax, 802.11ac, 802.11n, 802.11g, 802.11b, and 802.11a. AP 110 can also be used in network environments that support next-generation WLAN systems / next-generation Wi-Fi communications.

[0160] The non-AP STA 120 can be a wireless communication device that supports WLAN / Wi-Fi technology, such as a wireless communication device with a WLAN / Wi-Fi chip.

[0161] In some embodiments, the non-AP STA 120 can be a device that supports various current and future IEEE 802.11 family of WLAN standards, including 802.11be, 802.11bn, 802.11ax, 802.11ac, 802.11n, 802.11g, 802.11b, and 802.11a. The non-AP STA 120 can also be used in network environments that support next-generation WLAN systems / next-generation Wi-Fi communication.

[0162] In this embodiment, the next-generation WLAN system is an evolution of the 802.11be system and is backward compatible with the 802.11be system. Next-generation Wi-Fi communication refers to any new generation of Wi-Fi communication after Wi-Fi 7 based on the 802.11be specification, such as Ultra High Reliability (UHR) communication.

[0163] In some embodiments, both AP 110 and non-AP STA 120 support the IEEE 802.11 protocol, but are not limited to the IEEE 802.11 protocol.

[0164] It's understandable that the role of a STA in wireless communication is not absolute. For example, when phone A is connected to a router, phone A is a non-AP STA, but when phone A acts as a hotspot for phone B, phone A acts as an AP.

[0165] In this application embodiment, 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 can be, 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.

[0166] 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 with wireless communication capabilities, other processing devices connected to wireless modems, in-vehicle devices, wearable devices, terminal devices in 5G networks, and Beyond 5G. Terminal devices in 5G (B5G) networks, terminal devices in 6G networks, and terminal devices in future evolved Public Land Mobile Networks (PLMNs) can also be televisions, refrigerators, washing machines, kitchen appliances, door locks, fish tanks, robot vacuum cleaners, game consoles, cameras / camcorders, sensors, etc. with wireless connectivity. This application embodiment is not limited to these.

[0167] By way of example and not limitation, the STA in the embodiments of this application can also be a wearable device. Wearable devices, also known as wearable smart devices, are a general term for devices that apply 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 need to be used in conjunction with other devices such as smartphones, such as various smart bracelets and smart jewelry for vital sign monitoring.

[0168] Furthermore, the STA in this application embodiment 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 of human-machine interconnection and object-to-object interconnection. In this application embodiment, IoT technology can achieve massive connectivity, deep coverage, and terminal power saving through technologies such as narrowband (NB).

[0169] Furthermore, the STA in this application embodiment can also be an in-vehicle communication device in a vehicle-to-everything (V2X) system or the vehicle itself. 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.

[0170] In some embodiments, the frequency bands supported by the wireless communication system 100 include, but are not limited to: millimeter wave (mmWave) bands (such as 45GHz, 60GHz, etc., which belong to the 30-300GHz range) and low-frequency bands. Among them, low-frequency bands include Sub-7GHz bands (such as 2.4GHz, 5GHz, 6GHz, etc., which belong to the 1-7.25GHz range).

[0171] In some embodiments, there are one or more links between AP 110 and non-AP STA 120.

[0172] In some embodiments, multi-band communication is supported between AP 110 and non-AP STA 120. For example, communication can occur simultaneously on one or more frequency bands such as 2.4 GHz, 5 GHz, 6 GHz, 45 GHz, and 60 GHz. Alternatively, communication can occur simultaneously on different channels within the same frequency band or on different channels within different frequency bands. Multi-band communication can improve communication throughput and / or reliability between devices. Such a device supporting multi-band communication can be considered to have multi-link operation (MLO) capability and is commonly referred to as a multi-band device or multi-link device (MLD), sometimes also called a multi-band entity or multi-link entity. In other words, an MLD is an entity or device that supports communication with other MLD entities using multiple wireless links.

[0173] An AP MLD can include one or more APs; that is, an AP MLD's associated STAs include one or more APs. A non-AP MLD can include one or more non-AP STAs; that is, a non-AP MLD's associated STAs include one or more non-AP STAs. One or more links can be formed between AP MLDs and non-AP MLDs, allowing communication between APs associated with an AP MLD and between non-AP STAs associated with a non-AP MLD. One or more peer-to-peer (P2P) links can also be formed between non-AP MLDs, allowing communication between non-AP STAs associated with two different non-AP MLDs. Similarly, one or more P2P links can be formed between AP MLDs, allowing communication between APs associated with two different AP MLDs.

[0174] Next, let's talk about roaming:

[0175] Roaming refers to the process of a non-access point device migrating from its currently associated first access point device to a second access point device. Alternatively, it can be understood as the process of migrating from its currently associated source access point device to a target access point device. The source access point device is also known as the current access point device.

[0176] In some embodiments, the non-access point device includes a non-access point single site device (non-AP STA) or a non-AP MLD.

[0177] In some embodiments, the first access point device includes a first access point single-site device or a first access point multi-link device. Alternatively, the first access point device is a source access point device, including a source access point single-site device or a source access point multi-link device. Alternatively, the first access point device is a current access point device, including a current access point single-site device or a current access point multi-link device.

[0178] In some embodiments, the second access point device includes a second access point single-site device or a second access point multi-link device. Alternatively, the second access point device is a target access point device, including a target access point single-site device or a target access point multi-link device.

[0179] In some embodiments, the first access point device and the second access point device belong to the same Extended Service Set (ESS), or the same Seamless Mobility Domain (SMD), or the same Roaming AP MLD.

[0180] In this embodiment, the non-access point device is taken as a non-access point multi-link device, the first access point device is taken as the source access point multi-link device, and the second access point device is taken as the target access point multi-link device for illustration. Referring to Figure 4, the process of a non-AP MLD roaming from the current AP MLD to the target AP MLD is shown. In some embodiments, before the non-AP MLD decides to initiate roaming, the non-AP MLD is associated / connected with the current AP MLD. Uplink and downlink data transmission can be performed between the non-AP MLD and the current AP MLD, and uplink and downlink data transmission can also be performed between the current AP MLD and the Distribution System (DS).

[0181] In some embodiments, the non-AP MLD determines whether to initiate roaming. When the non-AP MLD decides to initiate roaming, step 1 is performed.

[0182] Further, the non-AP MLD performs step 2, sending a roaming notification frame to notify the current AP MLD or the target AP MLD that the non-AP MLD is about to roam. The roaming notification frame carries one or more candidate AP MLDs, including the target AP MLD among them.

[0183] Furthermore, after receiving a roaming notification frame from a non-AP MLD, the current AP MLD may optionally select a target AP MLD from one or more candidate AP MLDs, and may optionally execute step 3 to migrate data communication context information (such as BA protocol negotiation parameters) to the target AP MLD.

[0184] Further, the current AP MLD or the target AP MLD executes step 4, sending a roaming notification frame to the non-AP MLD to notify the non-AP MLD of: the target AP MLD, the roaming request timeout parameter, the BA protocol negotiation parameter migration status, etc.

[0185] Further, the non-AP MLD performs step 5, sending a roaming request frame to the current AP MLD or the target AP MLD to initiate a roaming request.

[0186] Furthermore, after the non-AP MLD roaming ends, i.e., after the non-AP MLD migrates from the current AP MLD to the target AP MLD, the target AP MLD executes step 6, sending a roaming response frame to the non-AP MLD. Optionally, this roaming response frame is used to instruct the non-AP MLD to prepare to send Class 3 frames to the target AP MLD. When the non-AP MLD receives this roaming response frame, it can send Class 3 frames to the target AP MLD. Class 3 frames refer to three types of frames: data frames, management frames, and control frames.

[0187] In some embodiments, during the non-AP MLD's transmission of roaming request frames and reception of roaming response frames, data communication context information (such as BA protocol negotiation parameters and / or BA protocol control and status parameters) may optionally be migrated.

[0188] In some embodiments, after the non-AP MLD roaming ends, the non-AP MLD is associated / connected with the target AP MLD. Uplink and downlink data transmission can occur between the non-AP MLD and the target AP MLD, and uplink and downlink data transmission can also occur between the target AP MLD and the DS.

[0189] Here's a brief introduction to the distribution system. For example, as shown in Figure 5, the main function of the Distribution Controller (DS) is to connect different Basic Service Sets (BSS), allowing communication devices between different BSSs to communicate. For instance, by connecting BSS1 and BSS2, data in BSS1 and BSS2 can be forwarded to each other. In some embodiments, each BSS includes one or more communication devices; for example, BSS1 includes site 1 (STA1) and site 2 (STA2), and BSS2 includes site 3 (STA3) and site 4 (STA4). For example, the DS can forward data from site 2 (STA2) to site 3 (STA3), or vice versa.

[0190] In related technologies, during the roaming process initiated by a non-access point device (NAPD), if the migrated BA protocol context information is not synchronized with the NAPD, the sending and receiving of data packets will be affected, hindering the continuity of data transmission during roaming, such as causing significant packet loss and delayed data packet transmission. Based on this, this application proposes a migration method that helps improve the continuity of data transmission during the roaming process of NAPDs, minimizes packet loss, and reduces data packet transmission latency.

[0191] It should be noted that the "data packet" mentioned in the embodiments of this application can be understood as a MAC Protocol Data Unit (MPDU) and / or a Management MAC Protocol Data Unit (MMPDU). Alternatively, it can also be understood as a Fragmented MAC Service Data Unit (MSDU) and / or an Aggregated MSDU (A-MSDU).

[0192] Figure 6 illustrates a flowchart of a migration method provided in an exemplary embodiment of this application. The method is performed by a non-access point device. Optionally, the non-access point device in this embodiment includes a non-access point single-site device or a non-access point multi-link device. The method includes:

[0193] Step 220: The non-access point device receives a first frame, which is used to indicate the context information and / or the migration status of the context information from the first access point device to the second access point device.

[0194] In some embodiments, the context information is the context of the uplink data communication protocol for the non-access point device. Alternatively, it can be understood as the context related to uplink data transmission, the context related to the uplink data transmission process, or the context negotiated or maintained for uplink data communication.

[0195] In some embodiments, for the uplink data communication protocol, the non-access point device is the sender of the data frame and / or the originator of the block acknowledgment protocol; the first access point device or the second access point device is the receiver of the data frame and / or the recipient of the block acknowledgment protocol.

[0196] In some embodiments, the uplink data communication protocol includes the uplink data frame transmission block acknowledgment protocol (UL BA agreement).

[0197] In some embodiments, the migrated context information refers to the context information of the uplink data communication protocol for the non-access point device that needs to be migrated due to the roaming of the non-access point device and is located at the first access point device.

[0198] In some embodiments, the first frame is used to indicate the migration status and / or context information during / in the roaming process of the non-access point device. It should be noted that the "roaming process" described in this embodiment specifically refers to the "roaming process of the non-access point device." Optionally, the roaming process can be divided into pre-roaming, during-roaming, and post-roaming phases. Alternatively, it can be understood as the roaming process of the non-access point device spanning from the roaming preparation period to the end of the roaming period.

[0199] In some embodiments, the first frame is used to facilitate the synchronization of context information between the non-access point device and the first and / or second access point device. Alternatively, it can be understood as synchronizing information related to uplink data transmission. Optionally, the first frame is a data communication context information migration / synchronization status notification frame sent by the first or second access point device during the non-access point device's roaming. Or, the first frame is a roaming response frame sent by the first or second access point device to the non-access point device after the non-access point device's roaming has ended.

[0200] In some embodiments, the first frame is sent by the first access point device to the non-access point device. Alternatively, the first frame is sent by the second access point device to the non-access point device.

[0201] In some embodiments, the non-access point device receives the first frame during roaming. Alternatively, the non-access point device receives the first frame after roaming has ended.

[0202] In some embodiments, the migration status of context information is used to indicate context information that is being migrated and / or has already been migrated. Context information includes one or more of the following:

[0203] • The sequence number of the last data packet that has been transmitted to the upper or higher layer of the first TID;

[0204] • The packet number of the last data packet that has been transmitted to the upper or higher layer of the first TID;

[0205] • Receive reordering cache control status information;

[0206] • Scoreboard context control status information;

[0207] • Block confirmation parameter set information;

[0208] • Block confirmation timeout value.

[0209] In some embodiments, the last data packet that the first TID has been transmitted to the upper or higher layer refers to the last data packet uploaded by the first access point device to the upper or higher layer.

[0210] In some embodiments, for each TID with an established uplink block acknowledgment protocol, there exists a corresponding last data packet that has been transmitted to the upper or higher layer. Assuming that the sequence number of the last data packet transmitted to the upper or higher layer for any TID is SN(TID, UL.latest), then the above context information may optionally include SN(TID, UL.latest). Assuming that the packet number of the last data packet transmitted to the upper or higher layer for any TID is PN(TID, UL.latest), then the above context information may optionally include PN(TID, UL.latest).

[0211] In some embodiments, receiving reorder cache control status information includes one or more of the following:

[0212] • The first parameter value indicates the lowest sequence number expected to be received within the receive window;

[0213] • The second parameter value indicates the highest sequence number expected to be received within the receiving window;

[0214] • Receives the bitmap value of the reordered cache record.

[0215] In some embodiments, taking the current WinStartB parameter value with the first parameter value being the first TID as an example, it represents the value of the sequence number subfield of the first MSDU or A-MSDU that has not yet been received in the current receiving window. In some embodiments, taking the current WinEndB parameter value with the second parameter value being the first TID as an example, it represents the highest sequence number expected to be received in the current receiving window.

[0216] In some embodiments, the receive reordering buffer record bitmap value is used to indicate the receive reordering buffer status. For example, the i-th bit in the receive reordering buffer record bitmap value is used to indicate whether the MSDU or A-MSDU corresponding to the i-th sequence number exists in the receive reordering buffer. Optionally, when the i-th bit in the receive reordering buffer record bitmap value is a first value, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number exists in the receive reordering buffer. When the i-th bit in the receive reordering buffer record bitmap value is a second value, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number does not exist in the receive reordering buffer. For example, when the i-th bit in the receive reordering buffer record bitmap value is 1, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number exists in the receive reordering buffer. When the i-th bit in the receive reordering buffer record bitmap value is 0, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number does not exist in the receive reordering buffer.

[0217] In one possible example, assuming the receive reordering buffer record bitmap value is {1, 1, 0, 1}, it means that the receive reordering buffer has received the MSDU or A-MSDU corresponding to the 1st sequence number, the MSDU or A-MSDU corresponding to the 2nd sequence number, and the MSDU or A-MSDU corresponding to the 4th sequence number, but has not received the MSDU or A-MSDU corresponding to the 3rd sequence number.

[0218] In some embodiments, scoreboard context control status information includes one or more of the following:

[0219] • The third parameter value is used to indicate the lowest sequence number position in the BA record bitmap;

[0220] • The fourth parameter value indicates the position of the highest sequence number in the BA record bitmap;

[0221] ·BA records bitmap values.

[0222] In some embodiments, taking the third parameter value as an example of the WinStartR parameter value of the BA record bitmap as an example, it represents the lowest sequence number position in the current BA record bitmap. In some embodiments, taking the fourth parameter value as an example of the WinEndR parameter value of the BA record bitmap as an example, it represents the highest sequence number position in the current BA record bitmap.

[0223] In some embodiments, the BA record bitmap is a block acknowledgment record maintained by the receiver, which includes a bitmap indexed by sequence number, starting with a 12-bit unsigned integer. Optionally, the BA record bitmap is a generic BA record bitmap corresponding to the scoreboard context control maintained by the receiver.

[0224] In some embodiments, the block acknowledgment parameter set information includes at least one of: A-MSDU Supported, Block Ack Policy, Stream Identifier (TID), and Buffer Size. See Table 6 above for examples.

[0225] In some embodiments, a block acknowledgment timeout value is specified. The block acknowledgment timeout value indicates the duration for which the block acknowledgment protocol is valid, in units of unit (TU).

[0226] In some embodiments, the first frame includes at least one of the following fields:

[0227] • The first field indicates the sequence number of the last data packet that the first TID has been transmitted to the upper or higher layer;

[0228] • The second field indicates the packet number of the last data packet that the first TID has been transmitted to the upper or higher layer;

[0229] • The third field indicates the status information for receiving reordering cache control.

[0230] • The fourth field is used to indicate the scoreboard context control status information;

[0231] • The fifth field is used to indicate the block confirmation parameter set information;

[0232] • The sixth field is used to indicate the block confirmation timeout value.

[0233] In some embodiments, at least one field in the first frame is carried in the block acknowledgment protocol context element and / or security association context element. For example, refer to the description of the block acknowledgment protocol context element and / or security association scenario element above. For example, at least one field in the first frame is carried in the block acknowledgment protocol scenario parameter set (such as Table 4 and / or Table 5 above).

[0234] In some embodiments, the migration status of context information is used to indicate whether the migration of context information was successful. The migration status of context information includes at least one of the following:

[0235] • The first migration state indicates that all context information has been migrated.

[0236] • The second migration status indicates that the migration of the context information portion is complete;

[0237] • The third migration status indicates that all context information migrations are incomplete.

[0238] It should be noted that, in the embodiments of this application, "uplink data" refers to data sent from a non-access point device to an access point device. This includes not only uplink data but also control information related to downlink data, such as block acknowledgment feedback.

[0239] In some embodiments, the first frame is a roaming response frame or a data communication context information migration status notification frame. The time of receiving the data communication context information migration status notification frame includes at least one of the following: before sending the roaming request frame; after sending the roaming request frame; before receiving the roaming response frame; simultaneously with receiving the roaming response frame; and after receiving the roaming response frame.

[0240] In some embodiments, the non-access point device receives the first frame after initiating the roaming decision and before initiating the roaming request. Alternatively, this can be understood as the non-access point device receiving the first frame after sending the roaming notification frame and before sending the roaming request frame.

[0241] In some embodiments, the non-access point device receives the first frame after sending the roaming request frame and before receiving the roaming response frame.

[0242] In some embodiments, when a non-access point device receives a roaming response frame, it also receives the first frame. Alternatively, this can be understood as the roaming response frame and the first frame being two frames received simultaneously. Or, it can be understood as the first frame and the roaming response frame being the same frame, with the information carried in the first frame being carried in the roaming response frame.

[0243] In some embodiments, the non-access point device receives the first frame after receiving the roaming response frame.

[0244] In summary, the method provided in this embodiment enables the non-access point device to receive the first frame, allowing it to promptly learn about the migration of data communication context information during roaming (before / during / after roaming). This facilitates timely synchronization of uplink data transmission between the non-access point device and the first and / or second access point devices, ensuring data transmission continuity as much as possible during roaming, minimizing packet loss or achieving zero packet loss, and reducing packet transmission latency.

[0245] Next, we will introduce the processing flow of non-access point devices at different roaming times:

[0246] For those before roaming:

[0247] In some embodiments, "before roaming" can also be understood as "during roaming preparation," "after initiating a roaming decision and before initiating a roaming request," or "after sending a roaming notification frame and before sending a roaming request frame."

[0248] In some embodiments, the non-access point device processes the uplink data in the transmit buffer after initiating the roaming decision and before initiating the roaming request. For the processing of the uplink BA protocol of any TID (the first TID is used as an example in this embodiment), one or more of the following processing methods (1a, 1b, and 1c) may be adopted:

[0249] 1a Non-access point devices stop adding new data packets to the transmission buffer.

[0250] In some embodiments, after the non-access point device (NAPD) initiates a roaming decision, it stops adding new uplink data packets corresponding to the first TID to the transmit buffer. Optionally, after the NAPD initiates a roaming decision, it stops adding new MPDUs or MMPDUs to the transmit buffer. Since the NAPD may clear the data in the transmit buffer after roaming, stopping the addition of new data packets helps prevent the NAPD from failing to transmit all data packets during roaming and losing those data packets after roaming is complete.

[0251] 1b Non-access point device prioritizes sending the first data packet within the first time period. The first data packet is the data packet to be sent in the transmission buffer.

[0252] Optionally, the first duration is the transmission duration of an uplink data unit. Alternatively, the first duration is the timing duration of an uplink data processing timer. It should be noted that the first duration begins after the non-access point device (NAPD) initiates a roaming decision, or after the NAPD sends a roaming notification frame. The first duration ends before the NAPD initiates a roaming request, or before the NAPD sends a roaming request frame.

[0253] In some embodiments, the first data packet is the data packet to be sent uplink corresponding to the first TID in the send buffer.

[0254] In some embodiments, if the non-access point device fails to send all of the first data packet within the first time period, one or more of the following processing methods (2a and 2b) may be used (or understood as, if 1b is satisfied, at least one of 2a and 2b may be used):

[0255] 2a Clears the second data packet, which is a data packet in the send buffer that has not yet been sent.

[0256] In some embodiments, the second data packet is an uncompleted data packet corresponding to the first TID in the transmission buffer. Optionally, the second data packet is a subset of the first data packet. The non-access point device prioritizes transmitting the first data packet within a first duration. If the first data packet is not fully transmitted, the unsuccessfully transmitted data packets in the first data packet are cleared. Alternatively, if the second data packet in the first data packet is not successfully transmitted, the second data packet is cleared. That is, if some data packets still exist in the transmission buffer that have not been successfully transmitted, those unsuccessfully transmitted data packets are cleared.

[0257] In this embodiment of the application, "data packet not successfully sent" can be understood as: the non-access point device did not send a data packet, or the non-access point device sent a data packet but did not receive a corresponding acknowledgment response (ACK). Or it can be understood as: data packets that were not successfully sent, including: data packets that were not sent, and / or data packets that were sent but for which no acknowledgment response was received.

[0258] 2b reserves the second and / or third data packets.

[0259] In some embodiments, the second data packet is a data packet in the transmission buffer that has not yet been transmitted, and the second data packet is the data packet corresponding to the first TID in the transmission buffer that has not yet been transmitted. Optionally, the second data packet is a subset of the first data packet.

[0260] In some embodiments, the third data packet is a data packet associated with the second data packet. Optionally, the third data packet is a data packet that has been sent and has received an acknowledgment response corresponding to the first TID, and the sequence number of the third data packet is greater than or equal to the sequence number of the second data packet. Optionally, if there is an unsent data packet in the sending buffer, or a sent data packet that has not received an ACK, it is assumed that the SN corresponding to the data packet is SN(UL.unack), and the sequence number of the third data packet is greater than or equal to SN(UL.unack).

[0261] Optionally, the non-access point device (NAPD) prioritizes sending the first data packet within the first time period. If the first data packet is not fully sent, the remaining unsuccessfully sent data packets are retained, and / or, data packets associated with the unsuccessfully sent data packets in the sending buffer are retained. By retaining the second and / or third data packets, it helps to avoid the NAPD losing these data packets before or after roaming. Alternatively, it can prevent retransmission failures caused by the lack of corresponding data packets in the sending buffer during roaming.

[0262] In some embodiments, if the non-access point device retains the second data packet and / or the third data packet, the non-access point device may also employ one or more of the following processing methods (3a and 3b) (or understand it as, if 2b is satisfied, at least one of 3a and 3b is employed):

[0263] 3a Reserve the fourth data packet, whose sequence number is greater than or equal to the sequence number of the second data packet.

[0264] In some embodiments, the fourth data packet is the data packet corresponding to the first TID in the transmit buffer. Optionally, the fourth data packet includes the second data packet and / or the third data packet. Optionally, if there is an untransmitted data packet or a transmitted data packet that has not received an ACK in the transmit buffer, assuming the SN corresponding to the data packet is SN(UL.unack), then data packets in the transmit buffer with a sequence number greater than or equal to SN(UL.unack) are retained. Even if a data packet with a sequence number greater than or equal to SN(UL.unack) has been successfully transmitted (e.g., has received an ACK), the successfully transmitted data packet is also retained. For example, assuming the data packets in the transmit buffer include {SN=1, SN=2, SN=3, SN=4}, if the data packet corresponding to SN=2 has not been successfully transmitted, then the data packets corresponding to SN=3 and SN=4 are retained. In this case, even if the data packet corresponding to SN=3 has been successfully transmitted, the data packet corresponding to SN=3 is also retained. This helps to reduce and avoid uplink data loss.

[0265] 3b prioritizes sending the second data packet in sequence.

[0266] In some embodiments, data packets are sent in sequence according to their sequence numbers. For example, assuming the second data packet includes {SN=5, SN=6, SN=7, SN=8}, the data packet corresponding to SN=5 is sent first, then the data packet corresponding to SN=6, and so on. Alternatively, it can be understood as prioritizing the sending of data packets with smaller or earlier sequence numbers in the second data packet.

[0267] 1c stops sending uplink data packets.

[0268] In some embodiments, a non-access point device (NAPD) may stop sending uplink data after initiating a roaming request. For example, suppose the NAPD prioritizes sending a first data packet within a first duration, where the first data packet is a data packet to be sent in the transmission buffer. When the first duration is 0, uplink data transmission stops.

[0269] In some embodiments, after sending a roaming request frame and before receiving a roaming response frame, the non-access point device (NAPD) stops sending the uplink data packets corresponding to the first TID in the uplink direction. This helps to avoid the loss of uplink data packets that the NAPD continues to send during roaming.

[0270] By employing one or more of the above processing methods before roaming, the uplink data can be processed in a timely manner before roaming, thereby helping to avoid uplink data loss and / or delay during the roaming process of the non-access point device.

[0271] For roaming:

[0272] In some embodiments, "non-access point device in roaming" can also be understood as "non-access point device during roaming", or "non-access point device after initiating a roaming request and before receiving a roaming response", or "non-access point device after sending a roaming request frame and before receiving a roaming response frame".

[0273] In some embodiments, after sending a roaming request frame and before receiving a roaming response frame, a non-access point device may employ the processing method described above for non-access point devices before roaming.

[0274] Optionally, after initiating a roaming request, the non-access point device (NAPD) stops adding new MPDUs or MMPDUs to its transmission buffer until it receives a roaming response. Alternatively, this can be understood as the NAPD stopping adding new MPDUs or MMPDUs to its transmission buffer after initiating a roaming request frame, and resuming adding new MPDUs or MMPDUs to its transmission buffer after receiving a roaming response frame.

[0275] Optionally, after initiating a roaming request, the non-access point device (NAP) can also stop sending uplink data. For example, suppose the NAP prioritizes sending the first data packet (the packet to be sent in the transmission buffer) during the second duration. When the second duration reaches zero, uplink data transmission stops. It should be noted that the second duration begins either after the NAP initiates the roaming request or after the NAP sends the roaming request frame. The second duration ends either before the NAP receives the roaming response or before the NAP receives the roaming response frame.

[0276] In some embodiments, after sending a roaming request frame and before receiving a roaming response frame, the non-access point device stops sending the data packets to be sent in the uplink direction corresponding to the first TID.

[0277] Regarding roaming:

[0278] In some embodiments, after roaming, the non-access point device may also be understood as having migrated from the first access point device to the second access point device (roaming successful or roaming ended), or as having received a roaming response frame.

[0279] In some embodiments, after the non-access point device receives a roaming response frame and confirms that it can send a Class 3 frame to the second access point device, one or more of the following processing methods (4a, 4b, and 4c) may be used:

[0280] 4a For packets with a specific TID originating from an upper or higher layer and destined for the same second access point device (or understood as packets originating from the MAC layer in a non-access point device and destined for the same second access point device), one or more of the following processing methods shall be adopted (4a.1 and 4a.2):

[0281] 4a.1 In the absence of renegotiation of the BA protocol, the original serial number shall be used.

[0282] In some embodiments, without renegotiating the BA protocol, newly added data packets are sequentially processed using the original sequence number; and / or, data packets in the transmit buffer are processed based on the original sequence number and / or the continued sequence number.

[0283] In some embodiments, if the BA protocol is not renegotiated during the roaming of a non-access point device (NAPD), the continuity of the sequence number (SN) needs to be maintained. This can be understood as the sequence numbers of data packets with a specific TID from an upper layer or higher layer being consecutive before and after the NAPD receives the roaming response frame. For example, assuming the last data packet before the NAPD receives the roaming response frame corresponds to SN1, then the first data packet after receiving the roaming response frame should correspond to SN1+1.

[0284] 4a.2 In the case of renegotiated BA protocol, a new sequence number determined based on the renegotiated BA protocol shall be adopted.

[0285] In some embodiments, when the BA protocol has been renegotiated, the first newly added data packet uses the renegotiated starting sequence number, and subsequent data packets are processed sequentially. Alternatively, this can be understood as processing data packets in the transmit buffer based on the renegotiated sequence number.

[0286] In some embodiments, if the BA protocol is renegotiated during roaming of the non-access point device (NAPD), it is not necessary to maintain the continuity of the sequence number (SN). Alternatively, this can be understood as the sequence numbers of data packets with a specific TID from an upper or higher layer being discontinuous before and after the NAPD receives the roaming response frame. For example, assuming the last data packet before the NAP receives the roaming response frame corresponds to SN1, then the first data packet after receiving the roaming response frame should correspond to SN2, where SN2 is not equal to SN1+1.

[0287] Determining whether a new serial number is needed based on whether the BA protocol has been renegotiated is beneficial for ensuring the accuracy of the SN (Serial Number) before and after roaming for non-access point (NP) devices. If the BA protocol has not been renegotiated, it means that consecutive serial numbers can be used before and after roaming for NP devices. If the BA protocol has been renegotiated, it means that maintaining SN continuity is not required before and after roaming for NP devices.

[0288] 4b For packets with a specific TID from an upper or higher layer destined for the same second access point device (or understood as packets from the MAC layer in a non-access point device destined for the same second access point device), one or more of the following processing methods shall be adopted (4b.1 and 4b.2):

[0289] 4b.1 In the case of PTK update, the updated PTK is used to encrypt the data packets to be sent and / or to decrypt the received data packets, and a new PN space is used.

[0290] In some embodiments, if the PTK is updated during roaming of a non-access point device, then for any individually addressed data packet transmitted on any established link with the second access point device, the newly generated PTK is used to encrypt the data packet to be sent, and the PN corresponding to the new PN space is used (or understood as using the new PN space to number the PN). Alternatively, the newly generated PTK is used to decrypt the received data packet, and the PN corresponding to the original PN space is used for verification.

[0291] 4b.2 If the PTK is not updated, the original PTK shall be used to encrypt the data packets to be sent and / or to decrypt the data packets to be received, and the original PN space shall be used.

[0292] In some embodiments, if the PTK is not updated during roaming of the non-access point device, the data packets are encrypted using the PTK used before the update, and the PN number corresponding to the original PN space is used. For example, before and after the non-access point device receives the roaming response frame, the PN corresponding to the data packets of a specific TID from the upper or higher layer is continuous and / or the PN is located in the original PN space.

[0293] It should be noted that the processing method described in 4b above is for cases where data packets need to be encrypted.

[0294] Determining whether a new PTK and PN space are needed based on whether the PTK has been updated helps ensure the accuracy of data packet encryption or decryption before and after roaming for non-access point devices. If the PTK has been updated, different PTKs should be used for encryption or decryption before and after roaming to avoid data packet encryption or decryption failures. If the PTK has not been updated, the same PTK and PN space can be used before and after roaming for the non-access point device.

[0295] If the first data packet (the data packet to be sent in the transmit buffer) still exists in the transmit buffer, 4c employs one or more of the following processing methods (4c.1, 4c.2, 4c.3, and 4c.4):

[0296] 4c.1 In the absence of renegotiation of the BA agreement, one or more of the following treatments (4c.1.1 and 4c.1.2) shall be adopted:

[0297] 4c.1.1 If the sequence number of the fifth packet is less than or equal to the sequence number of the first packet, the fifth packet shall be discarded.

[0298] In some embodiments, the first sequence number is the sequence number of the last data packet uploaded to the upper or higher layer. For example, assuming the first sequence number received by the non-access point device is SN(TID, UL.latest), then if there is a data packet in the transmit buffer with a sequence number less than or equal to SN(TID, UL.latest), the data packet with the sequence number less than or equal to SN(TID, UL.latest) is discarded. For example, suppose the data packets in the transmit buffer correspond to SNs {SN=1, SN=2, SN=3, SN=4}. If the sequence number of the last data packet uploaded to the upper or higher layer is SN=3, then the data packets corresponding to {SN=1, SN=2, SN=3} are discarded.

[0299] 4c.1.2 If the sequence number of the fifth data packet is greater than the sequence number of the first data packet, one or more of the following processing methods (i and ii) shall be used:

[0300] If the fifth data packet is encrypted, i will use one or more of the following processing methods (1i, 2i, and 3i):

[0301] 1i discards the fifth data packet.

[0302] If the PTK is not updated, the original PTK and PN space will be used, keeping the fifth data packet unchanged. Refer to section 4b.2 above.

[0303] When PTK is updated, 3i uses the original PTK to decrypt the fifth data packet, then uses the new PTK to encrypt the fifth data packet, and also uses the new PN space.

[0304] ii. If the fifth data packet is unencrypted (which can be understood as not using the original PTK encryption), one or more of the following processing methods (1ii and 2ii) shall be used:

[0305] 1ii If new PTK encryption is not required, then the fifth data packet remains unchanged. Alternatively, this can be understood as maintaining the content or information of the fifth data packet unchanged.

[0306] 2ii If a new PTK encryption is required, then the new PTK shall be used to encrypt the fifth data packet, and a new PN space shall be used. Refer to section 4b.1 above.

[0307] 4c.2 In the event that the BA agreement has been renegotiated, one or more of the following treatments (4c.2.1 and 4c.2.2) shall be adopted:

[0308] 4c.2.1 If the sequence number of the fifth packet is less than or equal to the sequence number of the first packet, the fifth packet shall be discarded. Refer to section 4c.1.1 above.

[0309] 4c.2.2 If the sequence number of the fifth data packet is greater than the sequence number of the first data packet, one or more of the following processing methods (t, 2t, 3t, and 4t) shall be used:

[0310] The fifth data packet is discarded.

[0311] 2t uses the newly negotiated sequence number. Or, it can be understood as using the newly negotiated SN to reset the SN values ​​in sequence.

[0312] If the fifth data packet is unencrypted (which can be understood as not using the original PTK encryption), then 3t will use one or more of the following processing methods (1r, 2r, and 3r):

[0313] If new PTK encryption is not required, then the fifth data packet remains unchanged. Alternatively, this can be understood as maintaining the content or information of the fifth data packet unchanged.

[0314] 2r If the original PTK encryption is required, then the original PTK encryption should be used to encrypt the fifth data packet, and the original PN space should also be used. Refer to section 4b.2 above.

[0315] 3r If a new PTK encryption is required, then the new PTK will be used to encrypt the fifth data packet, and a new PN space will be used. Refer to section 4b.1 above.

[0316] If the fifth data packet is encrypted (which can be understood as using the original PTK encryption), and a new PTK encryption is required, then the original PTK is used to decrypt the fifth data packet, followed by the new PTK to encrypt the fifth data packet, and a new PN space is used.

[0317] 4c.3 After a non-access point device receives the receive reordering buffer control status information, it shall employ one or more of the following processing methods (4c.3.1 and 4c.3.2):

[0318] 4c.3.1 Determine the sixth data packet to send based on the receive reordering buffer record bitmap value.

[0319] In some embodiments, the sixth data packet is the data packet corresponding to the first bit value in the receive reordering buffer record bitmap value. The sixth data packet is either a data packet that was not successfully transmitted, or a data packet that was not received. For example, the sixth data packet is the data packet corresponding to a bit value of 0 in the receive reordering buffer record bitmap value. Assuming the receive reordering buffer record bitmap value is {1, 0, 0, 1}, corresponding to {SN=1, SN=2, SN=3, SN=4} respectively, then the sixth data packet is the data packet corresponding to SN=2 and the data packet corresponding to SN=3.

[0320] Optionally, before sending the sixth data packet, the sixth data packet may be processed according to 4c.1 or 4c.2 above, depending on whether the BA protocol has been renegotiated.

[0321] 4c.3.2 Clear the seventh data packet based on the received reordering buffer record bitmap value.

[0322] In some embodiments, the seventh data packet is the data packet corresponding to the second bitmap value in the receive reordering buffer record bitmap value. The seventh data packet is either a successfully transmitted data packet or a successfully received data packet. For example, the seventh data packet is the data packet corresponding to a bit value of 1 in the receive reordering buffer record bitmap value. Assuming the receive reordering buffer record bitmap value is {1, 0, 0, 1}, corresponding to {SN=1, SN=2, SN=3, SN=4} respectively, then the seventh data packet is the data packet corresponding to SN=1 and the data packet corresponding to SN=4.

[0323] 4c.4 The non-access point device sends a second frame to the second access point device. The second frame is used to indicate the update of the receive reordering buffer control status information. Alternatively, the second frame can be understood as a receive reordering buffer control status parameter information update frame, used to update the WinStartB and WinStartR parameters corresponding to the uplink BA protocol of the second access point device as the receiver.

[0324] In some embodiments, the second frame includes a third field indicating the receipt of reordering cache control state information. At least one field in the second frame is carried in the block acknowledgment protocol context element and / or security association context element. For example, see the description of the block acknowledgment protocol context element and / or security association scenario element above. For example, at least one field in the second frame is carried in the block acknowledgment protocol scenario parameter set (as shown in Table 5 above).

[0325] Figure 7 illustrates a flowchart of a migration method provided in an exemplary embodiment of this application. The method is performed by a first access point device. Optionally, the first access point device in this embodiment may include a first access point single-site device or a first access point multi-link device. The method includes:

[0326] Step 320: The first access point device sends a first frame to the non-access point device. The first frame is used to indicate the context information and / or the migration status of the context information from the first access point device to the second access point device.

[0327] In some embodiments, the context information is the context of the uplink data communication protocol for the non-access point device. Alternatively, it can be understood as the context related to uplink data transmission, the context related to the uplink data transmission process, or the context negotiated or maintained for uplink data communication.

[0328] In some embodiments, for the uplink data communication protocol, the non-access point device is the sender of the data frame and / or the originator of the block acknowledgment protocol; the first access point device or the second access point device is the receiver of the data frame and / or the recipient of the block acknowledgment protocol.

[0329] In some embodiments, the uplink data communication protocol includes the uplink data frame transmission block acknowledgment protocol (UL BA agreement).

[0330] In some embodiments, the migrated context information refers to the context information of the uplink data communication protocol for the non-access point device that needs to be migrated due to the roaming of the non-access point device and is located at the first access point device.

[0331] In some embodiments, the first frame is used to indicate the migration status and / or context information during / in the roaming process of the non-access point device. It should be noted that the "roaming process" described in this embodiment specifically refers to the "roaming process of the non-access point device." Optionally, the roaming process can be divided into pre-roaming, during-roaming, and post-roaming phases. Alternatively, it can be understood as the roaming process of the non-access point device spanning from the roaming preparation period to the end of the roaming period.

[0332] In some embodiments, the first frame is used to facilitate the synchronization of context information between the non-access point device and the first and / or second access point device. Alternatively, it can be understood as synchronizing information related to uplink data transmission. Optionally, the first frame is a data communication context information migration / synchronization status notification frame sent by the first or second access point device during the non-access point device's roaming. Or, the first frame is a roaming response frame sent by the first or second access point device to the non-access point device after the non-access point device's roaming has ended.

[0333] In some embodiments, the first frame is sent by the first access point device to the non-access point device. Alternatively, the first frame is sent by the second access point device to the non-access point device.

[0334] In some embodiments, the non-access point device receives the first frame during roaming. Alternatively, the non-access point device receives the first frame after roaming has ended.

[0335] In some embodiments, the migration status of context information is used to indicate context information that is being migrated and / or has already been migrated. Context information includes one or more of the following:

[0336] • The sequence number of the last data packet that has been transmitted to the upper or higher layer of the first TID;

[0337] • The packet number of the last data packet that has been transmitted to the upper or higher layer of the first TID;

[0338] • Receive reordering cache control status information;

[0339] • Scoreboard context control status information;

[0340] • Block confirmation parameter set information;

[0341] • Block confirmation timeout value.

[0342] In some embodiments, the last data packet that the first TID has been transmitted to the upper or higher layer refers to the last data packet uploaded by the first access point device to the upper or higher layer.

[0343] In some embodiments, for each TID with an established uplink block acknowledgment protocol, there exists a corresponding last data packet that has been transmitted to the upper or higher layer. Assuming that the sequence number of the last data packet transmitted to the upper or higher layer for any TID is SN(TID, UL.latest), then the above context information may optionally include SN(TID, UL.latest). Assuming that the packet number of the last data packet transmitted to the upper or higher layer for any TID is PN(TID, UL.latest), then the above context information may optionally include PN(TID, UL.latest).

[0344] In some embodiments, receiving reorder cache control status information includes one or more of the following:

[0345] • The first parameter value indicates the lowest sequence number expected to be received within the receive window;

[0346] • The second parameter value indicates the highest sequence number expected to be received within the receiving window;

[0347] • Receives the bitmap value of the reordered cache record.

[0348] In some embodiments, taking the current WinStartB parameter value with the first parameter value being the first TID as an example, it represents the value of the sequence number subfield of the first MSDU or A-MSDU that has not yet been received in the current receiving window. In some embodiments, taking the current WinEndB parameter value with the second parameter value being the first TID as an example, it represents the highest sequence number expected to be received in the current receiving window.

[0349] In some embodiments, the receive reordering buffer record bitmap value is used to indicate the receive reordering buffer status. For example, the i-th bit in the receive reordering buffer record bitmap value is used to indicate whether the MSDU or A-MSDU corresponding to the i-th sequence number exists in the receive reordering buffer. Optionally, when the i-th bit in the receive reordering buffer record bitmap value is a first value, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number exists in the receive reordering buffer. When the i-th bit in the receive reordering buffer record bitmap value is a second value, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number does not exist in the receive reordering buffer. For example, when the i-th bit in the receive reordering buffer record bitmap value is 1, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number exists in the receive reordering buffer. When the i-th bit in the receive reordering buffer record bitmap value is 0, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number does not exist in the receive reordering buffer.

[0350] In one possible example, assuming the receive reordering buffer record bitmap value is {1, 1, 0, 1}, it means that the receive reordering buffer has received the MSDU or A-MSDU corresponding to the 1st sequence number, the MSDU or A-MSDU corresponding to the 2nd sequence number, and the MSDU or A-MSDU corresponding to the 4th sequence number, but has not received the MSDU or A-MSDU corresponding to the 3rd sequence number.

[0351] In some embodiments, scoreboard context control status information includes one or more of the following:

[0352] • The third parameter value is used to indicate the lowest sequence number position in the BA record bitmap;

[0353] • The fourth parameter value indicates the position of the highest sequence number in the BA record bitmap;

[0354] ·BA records bitmap values.

[0355] In some embodiments, taking the third parameter value as an example of the WinStartR parameter value of the BA record bitmap as an example, it represents the lowest sequence number position in the current BA record bitmap. In some embodiments, taking the fourth parameter value as an example of the WinEndR parameter value of the BA record bitmap as an example, it represents the highest sequence number position in the current BA record bitmap.

[0356] In some embodiments, the BA record bitmap is a block acknowledgment record maintained by the receiver, which includes a bitmap indexed by sequence number, starting with a 12-bit unsigned integer. Optionally, the BA record bitmap is a generic BA record bitmap corresponding to the scoreboard context control maintained by the receiver.

[0357] In some embodiments, the block acknowledgment parameter set information includes at least one of: A-MSDU Supported, Block Ack Policy, Stream Identifier (TID), and Buffer Size. See Table 6 above for examples.

[0358] In some embodiments, a block acknowledgment timeout value is specified. The block acknowledgment timeout value indicates the duration for which the block acknowledgment protocol is valid, in units of unit (TU).

[0359] In some embodiments, the first frame includes at least one of the following fields:

[0360] • The first field indicates the sequence number of the last data packet that the first TID has been transmitted to the upper or higher layer;

[0361] • The second field indicates the packet number of the last data packet that the first TID has been transmitted to the upper or higher layer;

[0362] • The third field indicates the status information for receiving reordering cache control.

[0363] • The fourth field is used to indicate the scoreboard context control status information;

[0364] • The fifth field is used to indicate the block confirmation parameter set information;

[0365] • The sixth field is used to indicate the block confirmation timeout value.

[0366] In some embodiments, at least one field in the first frame is carried in the block acknowledgment protocol context element and / or security association context element. For example, refer to the description of the block acknowledgment protocol context element and / or security association scenario element above. For example, at least one field in the first frame is carried in the block acknowledgment protocol scenario parameter set (such as Table 4 and / or Table 5 above).

[0367] In some embodiments, the migration status of context information is used to indicate whether the migration of context information was successful. The migration status of context information includes at least one of the following:

[0368] • The first migration state indicates that all context information has been migrated.

[0369] • The second migration status indicates that the migration of the context information portion is complete;

[0370] • The third migration status indicates that all context information migrations are incomplete.

[0371] It should be noted that, in the embodiments of this application, "uplink data" refers to data sent from a non-access point device to an access point device. This includes not only uplink data but also control information related to downlink data, such as block acknowledgment feedback.

[0372] In some embodiments, the first frame is a roaming response frame or a data communication context information migration status notification frame. The data communication context information migration status notification frame is sent at least one of the following times: before receiving a roaming request frame; after receiving a roaming request frame; before sending a roaming response frame; simultaneously with sending a roaming response frame; and after sending a roaming response frame.

[0373] In summary, the method provided in this embodiment, by sending a first frame to the non-access point device, enables the non-access point device to promptly obtain information about the migration of data communication context information during roaming (before / during / after roaming). This facilitates timely synchronization of uplink data transmission between the non-access point device and the first access point device and / or the second access point device, ensuring the continuity of data transmission during roaming, minimizing data packet loss or achieving zero packet loss, and reducing data packet transmission latency.

[0374] In some embodiments, after the first access point device receives a roaming request frame from a non-access point device, the first access point device sends the final MPDU and MMPDU corresponding to the specific TID to the DS, and initiates data communication context information migration. At this time, the first access point device may employ one or more of the following processing methods (5a and 5b):

[0375] 5a The first access point device clears the eighth data packet in the receive reordering buffer if the first condition is met.

[0376] In some embodiments, the eighth data packet is a data packet that was not successfully migrated from the reordering cache.

[0377] In some embodiments, the first condition includes at least one of the following:

[0378] • PTK is updated after the roaming of non-access point devices ends;

[0379] • After the roaming period of a non-access point device ends, the PTK is not updated, but migration from the first access point device to the second access point device is not supported.

[0380] In some embodiments, if the first access point device confirms that the PTK of the non-access point device has been updated after roaming to the second access point device, and if the MPDU and MMPDU in the receive reordering buffer corresponding to the TID of the uplink BA protocol still exist in the receive reordering buffer, then the MPDU and MMPDU are cleared.

[0381] In some embodiments, if the first access point device confirms that the PTK of the non-access point device does not update after roaming to the second access point device but does not support sending MPDU and MMPDU from the current access point device to the second access point device, then if the MPDU and MMPDU in the receive reordering buffer corresponding to the uplink BA protocol TID still exist in the receive reordering buffer, the MPDU and MMPDU are cleared.

[0382] 5b If the second condition is met, migrate the eighth data packet to the second access point device.

[0383] In some embodiments, the second condition includes:

[0384] After the first site roaming ends, PTK is not updated, and migration from the first access point device to the second access point device is supported.

[0385] In some embodiments, if the PTK of a non-access point device does not change after roaming to a second access point device but supports sending MPDUs and MMPDUs from the current access point device to the second access point device, then if the MPDUs and MMPDUs in the receive reordering buffer corresponding to the TID of the uplink BA protocol still exist in the receive reordering buffer, the MPDUs and MMPDUs are migrated.

[0386] Figure 8 illustrates a flowchart of a migration method provided in an exemplary embodiment of this application. The method is performed by a second access point device. Optionally, the second access point device in this embodiment includes a target access point site device or a target access point multilink device. The method includes:

[0387] Step 420: The second access point device sends a first frame to the non-access point device. The first frame is used to indicate the context information and / or the migration status of the context information from the first access point device to the second access point device.

[0388] In some embodiments, the context information is the context of the uplink data communication protocol for the non-access point device. Alternatively, it can be understood as the context related to uplink data transmission, the context related to the uplink data transmission process, or the context negotiated or maintained for uplink data communication.

[0389] In some embodiments, for the uplink data communication protocol, the non-access point device is the sender of the data frame and / or the originator of the block acknowledgment protocol; the first access point device or the second access point device is the receiver of the data frame and / or the recipient of the block acknowledgment protocol.

[0390] In some embodiments, the uplink data communication protocol includes the uplink data frame transmission block acknowledgment protocol (UL BA agreement).

[0391] In some embodiments, the migrated context information refers to the context information of the uplink data communication protocol for the non-access point device that needs to be migrated due to the roaming of the non-access point device and is located at the first access point device.

[0392] In some embodiments, the first frame is used to indicate the migration status and / or context information during / in the roaming process of the non-access point device. It should be noted that the "roaming process" described in this embodiment specifically refers to the "roaming process of the non-access point device." Optionally, the roaming process can be divided into pre-roaming, during-roaming, and post-roaming phases. Alternatively, it can be understood as the roaming process of the non-access point device spanning from the roaming preparation period to the end of the roaming period.

[0393] In some embodiments, the first frame is used to facilitate the synchronization of context information between the non-access point device and the first and / or second access point device. Alternatively, it can be understood as synchronizing information related to uplink data transmission. Optionally, the first frame is a data communication context information migration / synchronization status notification frame sent by the first or second access point device during the non-access point device's roaming. Or, the first frame is a roaming response frame sent by the first or second access point device to the non-access point device after the non-access point device's roaming has ended.

[0394] In some embodiments, the first frame is sent by the first access point device to the non-access point device. Alternatively, the first frame is sent by the second access point device to the non-access point device.

[0395] In some embodiments, the non-access point device receives the first frame during roaming. Alternatively, the non-access point device receives the first frame after roaming has ended.

[0396] In some embodiments, the migration status of context information is used to indicate context information that is being migrated and / or has already been migrated. Context information includes one or more of the following:

[0397] • The sequence number of the last data packet that has been transmitted to the upper or higher layer of the first TID;

[0398] • The packet number of the last data packet that has been transmitted to the upper or higher layer of the first TID;

[0399] • Receive reordering cache control status information;

[0400] • Scoreboard context control status information;

[0401] • Block confirmation parameter set information;

[0402] • Block confirmation timeout value.

[0403] In some embodiments, the last data packet that the first TID has been transmitted to the upper layer or higher layer refers to the last data packet uploaded by the first access point device to the upper layer.

[0404] In some embodiments, for each TID with an established uplink block acknowledgment protocol, there exists a corresponding last data packet that has been transmitted to the upper or higher layer. Assuming that the sequence number of the last data packet transmitted to the upper or higher layer for any TID is SN(TID, UL.latest), then the above context information may optionally include SN(TID, UL.latest). Assuming that the packet number of the last data packet transmitted to the upper or higher layer for any TID is PN(TID, UL.latest), then the above context information may optionally include PN(TID, UL.latest).

[0405] In some embodiments, receiving reorder cache control status information includes one or more of the following:

[0406] • The first parameter value indicates the lowest sequence number expected to be received within the receive window;

[0407] • The second parameter value indicates the highest sequence number expected to be received within the receiving window;

[0408] • Receives the bitmap value of the reordered cache record.

[0409] In some embodiments, taking the current WinStartB parameter value with the first parameter value being the first TID as an example, it represents the value of the sequence number subfield of the first MSDU or A-MSDU that has not yet been received in the current receiving window. In some embodiments, taking the current WinEndB parameter value with the second parameter value being the first TID as an example, it represents the highest sequence number expected to be received in the current receiving window.

[0410] In some embodiments, the receive reordering buffer record bitmap value is used to indicate the receive reordering buffer status. For example, the i-th bit in the receive reordering buffer record bitmap value is used to indicate whether the MSDU or A-MSDU corresponding to the i-th sequence number exists in the receive reordering buffer. Optionally, when the i-th bit in the receive reordering buffer record bitmap value is a first value, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number exists in the receive reordering buffer. When the i-th bit in the receive reordering buffer record bitmap value is a second value, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number does not exist in the receive reordering buffer. For example, when the i-th bit in the receive reordering buffer record bitmap value is 1, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number exists in the receive reordering buffer. When the i-th bit in the receive reordering buffer record bitmap value is 0, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number does not exist in the receive reordering buffer.

[0411] In one possible example, assuming the receive reordering buffer record bitmap value is {1, 1, 0, 1}, it means that the receive reordering buffer has received the MSDU or A-MSDU corresponding to the 1st sequence number, the MSDU or A-MSDU corresponding to the 2nd sequence number, and the MSDU or A-MSDU corresponding to the 4th sequence number, but has not received the MSDU or A-MSDU corresponding to the 3rd sequence number.

[0412] In some embodiments, scoreboard context control status information includes one or more of the following:

[0413] • The third parameter value is used to indicate the lowest sequence number position in the BA record bitmap;

[0414] • The fourth parameter value indicates the position of the highest sequence number in the BA record bitmap;

[0415] ·BA records bitmap values.

[0416] In some embodiments, taking the third parameter value as an example of the WinStartR parameter value of the BA record bitmap as an example, it represents the lowest sequence number position in the current BA record bitmap. In some embodiments, taking the fourth parameter value as an example of the WinEndR parameter value of the BA record bitmap as an example, it represents the highest sequence number position in the current BA record bitmap.

[0417] In some embodiments, the BA record bitmap is a block acknowledgment record maintained by the receiver, which includes a bitmap indexed by sequence number, starting with a 12-bit unsigned integer. Optionally, the BA record bitmap is a generic BA record bitmap corresponding to the scoreboard context control maintained by the receiver.

[0418] In some embodiments, the block acknowledgment parameter set information includes at least one of: A-MSDU Supported, Block Ack Policy, Stream Identifier (TID), and Buffer Size. See Table 6 above for examples.

[0419] In some embodiments, a block acknowledgment timeout value is specified. The block acknowledgment timeout value indicates the duration for which the block acknowledgment protocol is valid, in units of unit (TU).

[0420] In some embodiments, the first frame includes at least one of the following fields:

[0421] • The first field indicates the sequence number of the last data packet that the first TID has been transmitted to the upper or higher layer;

[0422] • The second field indicates the packet number of the last data packet that the first TID has been transmitted to the upper or higher layer;

[0423] • The third field indicates the status information for receiving reordering cache control.

[0424] • The fourth field is used to indicate the scoreboard context control status information;

[0425] • The fifth field is used to indicate the block confirmation parameter set information;

[0426] • The sixth field is used to indicate the block confirmation timeout value.

[0427] In some embodiments, at least one field in the first frame is carried in the block acknowledgment protocol context element and / or security association context element. For example, refer to the description of the block acknowledgment protocol context element and / or security association scenario element above. For example, at least one field in the first frame is carried in the block acknowledgment protocol scenario parameter set (such as Table 4 and / or Table 5 above).

[0428] In some embodiments, the migration status of context information is used to indicate whether the migration of context information was successful. The migration status of context information includes at least one of the following:

[0429] • The first migration state indicates that all context information has been migrated.

[0430] • The second migration status indicates that the migration of the context information portion is complete;

[0431] • The third migration status indicates that all context information migrations are incomplete.

[0432] It should be noted that, in the embodiments of this application, "uplink data" refers to data sent from a non-access point device to an access point device. This includes not only uplink data but also control information related to downlink data, such as block acknowledgment feedback.

[0433] In some embodiments, the first frame is a roaming response frame or a data communication context information migration status notification frame. The data communication context information migration status notification frame is sent at least one of the following times: before receiving a roaming request frame; after receiving a roaming request frame; before sending a roaming response frame; simultaneously with sending a roaming response frame; and after sending a roaming response frame.

[0434] In summary, the method provided in this embodiment, by sending a first frame to the non-access point device, enables the non-access point device to promptly obtain information about the migration of data communication context information during roaming (before / during / after roaming). This facilitates timely synchronization of uplink data transmission between the non-access point device and the first access point device and / or the second access point device, ensuring the continuity of data transmission during roaming, minimizing data packet loss or achieving zero packet loss, and reducing data packet transmission latency.

[0435] In some embodiments, after the second access point device successfully sends a roaming response frame to the non-access point device, the second access point device may employ one or more of the following processing methods (6a and 6b):

[0436] 6a uses the original PTK to parse received individually addressed data packets and employs the original PN space check if the PTK is not updated.

[0437] In some embodiments, if the PTK is not updated, the non-access point device will use the same PTK to encrypt uplink data before and after roaming. In this case, the second access point device can directly use the original PTK to decrypt the uplink data.

[0438] In the case of a PTK update, version 6b uses the updated PTK to parse received individually addressed packets and employs the original PN space check.

[0439] In some embodiments, when the PTK has been updated, it is explained that the non-access point device will use a different PTK to encrypt the uplink data before and after roaming. In this case, if the second access point device still uses the original PTK to decrypt the uplink data, it will be unable to decrypt the uplink data.

[0440] Figure 9 illustrates a flowchart of a migration method provided in an exemplary embodiment of this application. The method is performed by a non-access point device. The method includes:

[0441] Step 520: The non-access point device sends a third frame, which is used to indicate the migration context information from the first access point device to the second access point device.

[0442] In some embodiments, the context information is the context of the uplink data communication protocol for the non-access point device. Alternatively, it can be understood as the context related to uplink data transmission, the context related to the uplink data transmission process, or the context negotiated or maintained for uplink data communication.

[0443] In some embodiments, for the uplink data communication protocol, the non-access point device is the sender of the data frame and / or the originator of the block acknowledgment protocol; the first access point device or the second access point device is the receiver of the data frame and / or the recipient of the block acknowledgment protocol.

[0444] In some embodiments, the uplink data communication protocol includes the uplink data frame transmission block acknowledgment protocol (UL BA agreement).

[0445] In some embodiments, the migrated context information refers to the context information of the uplink data communication protocol for the non-access point device that needs to be migrated due to the roaming of the non-access point device and is located at the first access point device.

[0446] In some embodiments, the third frame is used to indicate context information that needs to be migrated during / in the roaming of the non-access point device. It should be noted that the "roaming process" described in this embodiment specifically refers to the "roaming process of the non-access point device." Optionally, the roaming process can be divided into pre-roaming, during-roaming, and post-roaming phases. Alternatively, it can be understood that the roaming process of the non-access point device spans from the roaming preparation period to the end of the roaming period.

[0447] In some embodiments, the context information includes one or more of the following:

[0448] • The sequence number of the last data packet that has been transmitted to the upper or higher layer of the first TID;

[0449] • The packet number of the last data packet that has been transmitted to the upper or higher layer of the first TID;

[0450] • Receive reordering cache control status information;

[0451] • Scoreboard context control status information;

[0452] • Block confirmation parameter set information;

[0453] • Block confirmation timeout value.

[0454] In some embodiments, the last data packet that the first TID has been transmitted to the upper layer or higher layer refers to the last data packet uploaded by the first access point device to the upper layer.

[0455] In some embodiments, for each TID with an established uplink block acknowledgment protocol, there exists a corresponding last data packet that has been transmitted to the upper or higher layer. Assuming that the sequence number of the last data packet transmitted to the upper or higher layer for any TID is SN(TID, UL.latest), then the above context information may optionally include SN(TID, UL.latest). Assuming that the packet number of the last data packet transmitted to the upper or higher layer for any TID is PN(TID, UL.latest), then the above context information may optionally include PN(TID, UL.latest).

[0456] In some embodiments, receiving reorder cache control status information includes one or more of the following:

[0457] • The first parameter value indicates the lowest sequence number expected to be received within the receive window;

[0458] • The second parameter value indicates the highest sequence number expected to be received within the receiving window;

[0459] • Receives the bitmap value of the reordered cache record.

[0460] In some embodiments, taking the current WinStartB parameter value with the first parameter value being the first TID as an example, it represents the value of the sequence number subfield of the first MSDU or A-MSDU that has not yet been received in the current receiving window. In some embodiments, taking the current WinEndB parameter value with the second parameter value being the first TID as an example, it represents the highest sequence number expected to be received in the current receiving window.

[0461] In some embodiments, the receive reordering buffer record bitmap value is used to indicate the receive reordering buffer status. For example, the i-th bit in the receive reordering buffer record bitmap value is used to indicate whether the MSDU or A-MSDU corresponding to the i-th sequence number exists in the receive reordering buffer. Optionally, when the i-th bit in the receive reordering buffer record bitmap value is a first value, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number exists in the receive reordering buffer. When the i-th bit in the receive reordering buffer record bitmap value is a second value, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number does not exist in the receive reordering buffer. For example, when the i-th bit in the receive reordering buffer record bitmap value is 1, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number exists in the receive reordering buffer. When the i-th bit in the receive reordering buffer record bitmap value is 0, it is used to indicate that the MSDU or A-MSDU corresponding to the i-th sequence number does not exist in the receive reordering buffer.

[0462] In one possible example, assuming the receive reordering buffer record bitmap value is {1, 1, 0, 1}, it means that the receive reordering buffer has received the MSDU or A-MSDU corresponding to the 1st sequence number, the MSDU or A-MSDU corresponding to the 2nd sequence number, and the MSDU or A-MSDU corresponding to the 4th sequence number, but has not received the MSDU or A-MSDU corresponding to the 3rd sequence number.

[0463] In some embodiments, scoreboard context control status information includes one or more of the following:

[0464] • The third parameter value is used to indicate the lowest sequence number position in the BA record bitmap;

[0465] • The fourth parameter value indicates the position of the highest sequence number in the BA record bitmap;

[0466] ·BA records bitmap values.

[0467] In some embodiments, taking the third parameter value as an example of the WinStartR parameter value of the BA record bitmap as an example, it represents the lowest sequence number position in the current BA record bitmap. In some embodiments, taking the fourth parameter value as an example of the WinEndR parameter value of the BA record bitmap as an example, it represents the highest sequence number position in the current BA record bitmap.

[0468] In some embodiments, the BA record bitmap is a block acknowledgment record maintained by the receiver, which includes a bitmap indexed by sequence number, starting with a 12-bit unsigned integer. Optionally, the BA record bitmap is a generic BA record bitmap corresponding to the scoreboard context control maintained by the receiver.

[0469] In some embodiments, the block acknowledgment parameter set information includes at least one of: A-MSDU Supported, Block Ack Policy, Stream Identifier (TID), and Buffer Size. See Table 6 above for examples.

[0470] In some embodiments, a block acknowledgment timeout value is specified. The block acknowledgment timeout value indicates the duration for which the block acknowledgment protocol is valid, in units of unit (TU).

[0471] In some embodiments, the third frame includes at least one of the following fields:

[0472] • The first field indicates the sequence number of the last data packet that the first TID has been transmitted to the upper or higher layer;

[0473] • The second field indicates the packet number of the last data packet that the first TID has been transmitted to the upper or higher layer;

[0474] • The third field indicates the status information for receiving reordering cache control.

[0475] • The fourth field is used to indicate the scoreboard context control status information;

[0476] • The fifth field is used to indicate the block confirmation parameter set information;

[0477] • The sixth field is used to indicate the block confirmation timeout value.

[0478] In some embodiments, at least one field in the third frame is carried in the block acknowledgment protocol context element and / or security association context element. For example, refer to the description of the block acknowledgment protocol context element and / or security association scenario element above. For example, at least one field in the third frame is carried in the block acknowledgment protocol scenario parameter set (such as Table 4 and / or Table 5 above).

[0479] It should be noted that, in the embodiments of this application, "uplink data" refers to data sent from a non-access point device to an access point device. This includes not only uplink data but also control information related to downlink data, such as block acknowledgment feedback.

[0480] In some embodiments, the third frame is a roaming request frame. Alternatively, it can be understood that the information carried in the third frame is contained within the roaming request frame. In some embodiments, the third frame and the roaming request frame are sent simultaneously.

[0481] In some embodiments, the third frame is a data communication context information migration indication frame, used to indicate the context information of the migration of the first access point device and / or the second access point device.

[0482] In some embodiments, the third frame is a data communication context information migration notification frame, used to indicate the context information of the migration of the first access point device and / or the second access point device.

[0483] Optionally, the third frame may be a request frame, an indication frame, or a notification frame.

[0484] In some embodiments, the third frame is sent by the non-access point device to the first access point device and / or the second access point device. Optionally, the first access point device and / or the second access point device receive the third frame and migrate context information according to the indication of the third frame.

[0485] In summary, the method provided in this embodiment sends a third frame through the non-access point device, enabling the first and second access point devices to accurately migrate context information according to the instructions in the third frame. This ensures the continuity of data transmission for the non-access point device during roaming, minimizes packet loss or achieves zero packet loss during roaming, and reduces packet transmission latency.

[0486] In some embodiments, the method described in this application is shown in FIG10, where a non-AP MLD roams from the current AP MLD (i.e., AP MLD1) to the target AP MLD (i.e., AP MLD2). During the non-AP MLD roaming, AP MLD1 copies or migrates the data communication context information associated with the non-AP MLD to AP MLD2. For the Block Ack protocol of uplink data packet transmission, the data communication context information includes the SN number (i.e., SN(TID, UL.latest)) of the last (or latest) data packet transmitted to the upper layer (or DS) for a specific TID. After the data communication context information has been migrated from AP MLD1 to AP MLD2, AP MLD1 or AP MLD2 can send the SN(TID, UL.latest) back to the non-AP MLD. After receiving the SN(TID, UL.latest), if there is a data unit in the receive buffer with an SN less than or equal to SN(TID, UL.latest), the non-AP MLD discards or clears the data unit, i.e., clears the data unit with SN 102 in the figure. If there is an unsent MPDU or MMPDU, or an MPDU or MMPDU that has been sent but has not received an ACK, let its corresponding SN be SN(UL.unack), i.e. 103 in the figure, then the MPDU or MMPDU with a corresponding SN greater than or equal to SN(UL.unack) should be retained in the transmission buffer even if an ACK for the MPDU or MMPDU is received, i.e., even if an ACK corresponding to the data unit with SN 104 is received, the data unit should still be retained in the transmission buffer.

[0487] In some embodiments, the method shown in this application is illustrated in FIG11, where a non-AP MLD roams from the current AP MLD (i.e., AP MLD1) to the target AP MLD (i.e., AP MLD2). During the non-AP MLD roaming, AP MLD1 copies or migrates the data communication context information associated with the non-AP MLD to AP MLD2. For the Block Ack protocol of uplink packet transmission, the data communication context information may include receive reordering buffer control status information, such as i) the current WinStartB parameter value per TA / TID; ii) the current WinEndB parameter value per TA / TID; iii) the current receive reordering buffer record bitmap value. After the data communication context information has been migrated from AP MLD1 to AP MLD2, AP MLD1 or AP MLD2 can send back the migrated receive reordering buffer control status information to the non-AP MLD. After receiving the receive reordering buffer control status information, the non-AP MLD processes it as follows:

[0488] • For data units whose corresponding SN position in the record bitmap within the range of (WinStartB, WinEndB) sent for a specific TID are 0 (i.e., data units that the receiver has not yet received), send the corresponding data unit, such as the data unit with SN number 103 in the figure;

[0489] • 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 already received by the receiving end), if the buffer still contains such data units, the corresponding data units will be cleared (e.g., data units with SN number 104 in the figure), and no further transmission will be performed.

[0490] In some embodiments, the methods shown in this application can be applied to data continuity-based FT protocols and data continuity-oriented link reconfiguration protocols.

[0491] The FT optimization protocol and frame interaction mechanism based on data persistence mainly include the following processes:

[0492] (1) Non-AP MLD is associated with the current AP MLD and mobile domain scenario association is performed or FT initial mobile domain scenario association is performed;

[0493] The Non-AP MLD sends an association request frame or reassociation request frame to the current AP MLD (FTR), and then the current AP MLD (FTR) sends an association response frame or reassociation response frame back to the Non-AP MLD, including:

[0494] The Non-AP MLD sends: (Re)Association Request (MDE, Basic Multi-Link element) to the current AP MLD (FTR); the current AP MLD (FTR) sends: (Re)Association Response (MDE, Basic Multi-Link element) to the Non-AP MLD.

[0495] The association request frame or reassociation request frame carries an MDE element, instructing the non-AP MLD to associate with the AP MLD in the mobile domain scenario (or the non-AP MLD is associated with the AP MLD attached to the mobile domain), and indicating that fast switching is supported or allowed between two AP MLDs attached to the same mobile domain MLD.

[0496] (2) Non-AP MLD initiates the FT process from the current AP MLD to the target AP MLD in the mobile domain scenario;

[0497] When a Non-AP MLD (FTO) determines that a transition from the current AP MLD to the target AP MLD is needed in a mobile domain MLD scenario, the FTO sends a Fast Transition Request (FT Request(FTO, TargetAP, MDE, Basic Multi-Link element)) to the target FTR via the current FTR. Then, the target AP MLD (FTR) sends a Fast Transition Response (FT Response(FTO, TargetAP, MDE, Basic Multi-Link element)) back to the Non-AP MLD via the current AP MLD (FTR).

[0498] The fast transition request frame and fast transition response frame carry MDE elements, indicating that fast transition is supported or permitted between two AP MLDs belonging to the same mobile domain.

[0499] (3) For Non-AP MLD, copy or migrate all or part of the context, state, and buffer of the mobile domain MLD from the current AP MLD to the target AP MLD.

[0500] Specifically, the FTO sends an FT Confirm frame (FT Confirm(FTO, TargetAP, MDE, RIC-Request(Block Ack Context element, SA context element), Basic Multi-Link element)) to the target FTR via the current FTR. Then, the target AP MLD(FTR) sends an FT ACK frame (FT ACK(FTO, TargetAP, MDE, TIE(ReassociationDeadline), RIC-Response(Block Ack Context element, SA Context element), Basic Multi-Link element)) to the Non-AP MLD via the current AP MLD(FTR).

[0501] Among them, FT Confirm and FT ACK carry Block Ack Context element and SA Context element, indicating the relevant block confirmation protocol scenario (or status) information and security association scenario (or status) information.

[0502] Once the data communication context information migration is complete, the target AP MLD sends a data communication context information migration status notification frame (or can be understood as the first frame mentioned above) to the non-AP MLD to notify the data communication context information migration status, including the block confirmation protocol scenario (or context) information and / or security association scenario (or context) information that has been migrated.

[0503] (4) Non-AP MLD is reassociated with target AP MLD in mobile domain scenario.

[0504] The Non-AP MLD sends an association request frame or reassociation request frame to the target AP MLD (FTR), and then the target AP MLD (FTR) sends an association response frame or reassociation response frame back to the Non-AP MLD, including:

[0505] The Non-AP MLD sends a (Re)Association Request (MDE, Basic Multi-Link element) to the target AP MLD (FTR); the target AP MLD (FTR) sends a (Re)Association Response (MDE, Block Ack Context element, SA Context element, Basic Multi-Link element) to the Non-AP MLD.

[0506] The association request frame or reassociation request frame carries an MDE element, instructing the non-AP MLD to associate with the target AP MLD in the mobile domain scenario (or the non-AP MLD is associated with the target AP MLD attached to the mobile domain), and indicating support for fast switching between two AP MLDs attached to the same mobile domain.

[0507] 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 to transmit uplink and / or downlink data packets.

[0508] The data packet data transmission and processing mechanism of non-AP MLD before, during, and after roaming is as described in the above embodiments. Optionally, for the block acknowledgment (BACK) protocol of uplink data packet transmission, whether the key (e.g., PTK) of uplink data packet transmission has been updated, and / or the parameters of the block acknowledgment protocol (e.g., ...)<TA,RA,TID> Depending on whether the parameters in the tuple change, different data packet transmission and processing mechanisms are adopted at the sending and receiving ends. Simultaneously, for the block acknowledgment (BACK) protocol in uplink data packet transmission, after the current AP MLD or the target AP MLD completes the data communication context information migration, it sends the data communication context information 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 information migration status.

[0509] • Link reconfiguration methods and protocols for data continuity

[0510] The frame type and format definitions and function updates for the link reconfiguration protocol and interaction under the Mobile Domain MLD architecture for FT include: updates to the definitions of Mobile Domain Elements (MDEs), link reconfiguration protocols, link reconfiguration request frames, and link reconfiguration associated frames; updates to the definitions of FT request and response protocols, FT resource request and response protocols, and frames such as FT Request, FT Response, FT Confirm, and FT ACK.

[0511] The link reconfiguration protocol for FT mainly includes the following process:

[0512] (1) Non-AP MLD is associated with the current AP MLD and mobile domain MLD scene association is performed or FT initial mobile domain MLD scene association is performed;

[0513] The Non-AP MLD sends an association request frame or reassociation request frame to the current AP MLD (FTR), and then the current AP MLD (FTR) sends an association response frame or reassociation response frame back to the Non-AP MLD, including:

[0514] The Non-AP MLD sends the following to the current AP MLD (FTR): (Re)Association Request(MDE(FTinMobileDomainMLD, MobileDomainMLD Info), Basic Multi-Link element); the current AP MLD (FTR) sends the following to the Non-AP MLD: (Re)Association Response(MDE(FTinMobileDomainMLD, MobileDomainMLD Info), Basic Multi-Link element).

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

[0516] (2) Non-AP MLD Initiation: In the mobile domain MLD scenario, the FT process from the current AP MLD to the target AP MLD is initiated;

[0517] When the Non-AP MLD (FTO) determines that a transition from the current AP MLD to the target AP MLD is needed in a mobile domain MLD scenario, the FTO sends a fast transition request frame (FT Request(FTO, TargetAP, MDE(FTinMobileDomainMLD, MobileDomainMLD Info), Basic Multi-Link element)) to the target FTR through the current FTR. Then, the target AP MLD (FTR) sends a fast transition response frame (FT Response(FTO, TargetAP, MDE(FTinMobileDomainMLD, MobileDomainMLD Info), Basic Multi-Link element)) back to the Non-AP MLD through the current AP MLD (FTR).

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

[0519] (3) For Non-AP MLD, copy or migrate all or part of the context, state, and buffer of the mobile domain MLD from the current AP MLD to the target AP MLD.

[0520] Specifically, the FTO sends an FT Confirm frame (FT Confirm(FTO, TargetAP, MDE(FTinMobileDomainMLD, MobileDomainMLD Info), RIC-Request(Block Ack Context element, SA context element), Basic Multi-Link element)) to the target FTR via the current FTR. Then, the target AP MLD (FTR) sends an FT ACK frame (FT ACK(FTO, TargetAP, MDE(FTinMobileDomainMLD, MobileDomainMLD Info), TIE(ReassociationDeadline), RIC-Response(Block Ack Context element, SA Context element), Basic Multi-Link element)) to the Non-AP MLD via the current AP MLD (FTR).

[0521] Among them, FT Confirm and FT ACK carry Block Ack Context element and SA Context element, indicating the relevant block confirmation protocol scenario (or status) information and security association scenario (or status) information.

[0522] (4) Based on the mobile domain MLD scenario, perform link reconfiguration between the Non-AP MLD and the current AP MLD and target AP MLD attached to the mobile domain MLD.

[0523] The Non-AP MLD sends a link reconfiguration request to the current AP MLD and then sends it to the target AP MLD (FTR). The target AP MLD (FTR) then sends a link reconfiguration response frame back to the Non-AP MLD through the current AP MLD.

[0524] The Non-AP MLD sends a Link Reconfiguration Request (MDE(FTinMobileDomainMLD, MobileDomainMLD Info), RME for CurrentAPMLD, RME for TargetAPMLD, OCI, TID-To-Link Mapping element) to both the current AP MLD and the target AP MLD (FTR).

[0525] The link reconfiguration request frame carries updated MDE elements (FTinMobileDomainMLD, MobileDomainMLD Info field), instructing a non-AP MLD, in a mobile domain MLD scenario, to request link reconfiguration on existing multi-links between the current AP MLD and the target AP MLD attached to the mobile domain MLD. This involves either adding a link or deleting a link from the existing multi-links. Specifically, for FT-oriented link reconfiguration, the request removes an existing link from the existing multi-links in the current AP MLD attached to the mobile domain MLD and creates one or more new links in the target MLD attached to the mobile domain MLD.

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

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

[0528] Once the data communication context information migration is complete, the current AP MLD sends a data communication context information migration status notification frame (or can be understood as the first frame mentioned above) to the non-AP MLD to notify the data communication context information migration status, including the block confirmation protocol scenario (or context) information and / or security association scenario (or context) information that has been migrated.

[0529] The target AP MLD (FTR) sends a link reconfiguration response to the Non-AP MLD through the current AP MLD: Link Reconfiguration Response(MDE(FTinMobileDomainMLD, MobileDomainMLD Info), RSL for CurrentAPMLD, RSL for TargetAPMLD, GKD, OCI, BME, TID-To-Link Mapping element).

[0530] The link reconfiguration response frame carries an updated MDE element (FTinMobileDomainMLD, MobileDomainMLD Info field), indicating that this frame is a response to a link reconfiguration request frame containing MDE, that is, a response to a link reconfiguration request between the current AP MLD and the target AP MLD attached to the mobile domain MLD in the mobile domain MLD scenario, based on the established multi-link.

[0531] Meanwhile, the link reconfiguration response frame carries link reconfiguration status code information (i.e., the status code field in the action domain), indicating the status code for link reconfiguration in the mobile domain MLD scenario; if the status code indicates "reject mobile domain link reconfiguration", the link reconfiguration response frame does not contain the reconfiguration status list information (i.e., the number of reconfiguration status tuples and the reconfiguration status list) for the link reconfiguration of the current AP MLD and the target AP MLD.

[0532] If the link reconfiguration status code information (i.e., the status code field in the action domain) carried in the link reconfiguration response frame indicates "SUCCESS", then the link reconfiguration response frame also carries reconfiguration status list information for the current AP MLD and the target AP MLD link reconfiguration, indicating the number of reconfiguration status tuples and the reconfiguration status list for the current AP MLD and the target AP MLD link reconfiguration. Specifically, in the link reconfiguration response frame, each link ID indicated in the Per-STA Profile sub-element of the corresponding link reconfiguration request frame for the current AP MLD and the target AP MLD contains a reconfiguration status tuple sub-field.

[0533] Specifically, for the reconfiguration status information of the current AP MLD, if the current AP MLD accepts a request to delete a link for a link ID, the corresponding status subfield in the reconfiguration status tuple subfield should be set to SUCCESS. For the reconfiguration status information of the target AP MLD, if the target AP MLD accepts a request to add a link for the corresponding link ID, the corresponding status 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.

[0534] Simultaneously, the link reconfiguration response frame carries a basic multilink element for the target AP MLD, used to provide 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.

[0535] If the link reconfiguration status code information (i.e., the status code field in the action domain) carried in the link reconfiguration response frame indicates "SUCCESS," meaning the target AP MLD accepts the addition of one or more links, then when using RSN, both the current AP MLD and the target AP MLD should include a Group Key Data subfield in the link reconfiguration response frame. For each link added by the target AP MLD, both the current AP MLD and the target AP MLD should include an MLO GTK KDE, an MLO IGTK KDE, and an MLO 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.

[0536] Simultaneously, the link reconfiguration response frame may optionally include one or two flow identifier-to-link mapping elements, or may not include flow identifier-to-link mapping elements, to respond to the received link reconfiguration request frame carrying or not carrying flow identifier-to-link mapping elements, indicating the result of the flow identifier-to-link mapping performed by the non-AP MLD and the target AP MLD on the established link. The rules governing the flow identifier-to-link mapping performed by the target AP MLD and the non-AP MLD on the established link, and the manner in which the link reconfiguration response frame responds to the link reconfiguration request frame carrying or not carrying flow identifier-to-link mapping elements and indicates the flow identifier-to-link mapping result, are consistent with the rules and manner in which the association response frame sent by the target AP MLD responds to the association request frame it receives carrying or not carrying flow identifier-to-link mapping elements and indicates the flow identifier-to-link mapping result.

[0537] The data packet data transmission and processing mechanism of non-AP MLD before, during, and after roaming is as described in the above embodiments. Optionally, for the block acknowledgment (BACK) protocol of uplink data packet transmission, whether the key (e.g., PTK) of uplink data packet transmission has been updated, and / or the parameters of the block acknowledgment protocol (e.g., ...)<TA,RA,TID> Depending on whether the parameters in the tuple change, different data packet transmission and processing mechanisms are adopted at the sending and receiving ends. Simultaneously, for the block acknowledgment (BACK) protocol in uplink data packet transmission, after the current AP MLD or the target AP MLD completes the data communication context information migration, it sends the data communication context information 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 information migration status.

[0538] In some embodiments, the roaming request frame may 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.

[0539] In some embodiments, the roaming response frame may 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.

[0540] It should be noted that the frame formats, element formats, and field formats shown in the above embodiments are examples and not limitations. This application supports changes to the formats of each frame, element, and field based on the format design described above, such as changing the order of fields / elements, changing the number of bytes in fields / elements, changing the number of bits in fields / elements, changing the names of fields / elements / frames, etc. It also supports setting some fields / elements as reserved fields.

[0541] It should be understood that the format, name, and value of the frames / elements / fields involved in the various embodiments of this application are merely examples and do not imply any limitation on the format, name, and value of the frames / elements / fields. In different embodiments or designs, it is possible that one or more of the aforementioned element / field names, their positions in the frame, their arrangement order with other elements / fields, the number of bytes occupied, or the number of bits occupied may change. Similarly, in different embodiments or designs, it is possible that one or more of the aforementioned frame names, included elements / fields, the number of bytes occupied, or the number of bits occupied may change.

[0542] It should also be noted that the migration method provided in this application embodiment is applicable to the uplink data communication process, but the migration method provided in this application embodiment can also be applied to the downlink data communication process. And / or, the relevant frames, elements, and fields involved in the embodiments of this application are applicable to the migration process of the context information of the uplink data communication protocol, but can also be applied to the migration process of the context information of the downlink data communication protocol.

[0543] Figure 12 illustrates a flowchart of a migration method provided in an exemplary embodiment of this application. The method is jointly executed by a first access point device and a non-access point device. The method includes:

[0544] Step 1: The first access point device sends the first frame to the non-access point device;

[0545] For specific implementation details, please refer to step 320 above.

[0546] Step 2: The non-access point device receives the first frame.

[0547] For specific implementation details, please refer to step 220 above.

[0548] Figure 13 illustrates a flowchart of a migration method provided in an exemplary embodiment of this application. The method is jointly executed by a second access point device and a non-access point device. The method includes:

[0549] Step 11: The second access point device sends the first frame to the non-access point device;

[0550] For specific implementation details, please refer to step 420 above.

[0551] Step 12: The non-access point device receives the first frame.

[0552] For specific implementation details, please refer to step 220 above.

[0553] It should be noted that any of the above embodiments executed by the non-access point device, the first access point device, and the second access point device can be freely combined, and this application does not limit this.

[0554] Figure 14 shows a structural block diagram of a migration apparatus provided in an exemplary embodiment of this application. Optionally, the apparatus can be implemented as a non-access point device. A non-access point device includes a non-access point site device or a non-access point multilink device. The apparatus includes:

[0555] The receiving module 1110 is used to receive a first frame, which indicates the context information and / or the migration status of the context information from the first access point device to the second access point device. The context information is the context of the uplink data communication protocol for the non-access point device.

[0556] In some embodiments, the context information includes one or more of the following:

[0557] The sequence number of the last data packet that has been transmitted to the upper or higher layer in the first TID;

[0558] The packet number of the last data packet that has been transmitted to the upper or higher layer in the first TID;

[0559] Receive reordering cache control status information;

[0560] Scoreboard context control status information;

[0561] Block confirmation parameter set information;

[0562] Block confirmation timeout value.

[0563] In some embodiments, receiving reorder cache control status information includes one or more of the following:

[0564] The first parameter value is used to indicate the lowest sequence number expected to be received in the receive window;

[0565] The second parameter value is used to indicate the highest sequence number expected to be received in the receive window;

[0566] Receives the bitmap value of the reordered cache record.

[0567] In some embodiments, the scoreboard context control status information includes one or more of the following:

[0568] The third parameter value is used to indicate the lowest sequence number position in the block confirmation BA record bitmap;

[0569] The fourth parameter value is used to indicate the position of the highest sequence number in the BA record bitmap;

[0570] BA records bitmap values.

[0571] In some embodiments, the first frame includes at least one of the following fields:

[0572] The first field is used to indicate the sequence number of the last data packet that has been transmitted to the upper or higher layer of the first TID;

[0573] The second field is used to indicate the packet number of the last data packet that has been transmitted to the upper layer for the first TID;

[0574] The third field is used to indicate the status information of receiving reordering cache control;

[0575] The fourth field is used to indicate the scoreboard context control status information;

[0576] The fifth field is used to indicate the block confirmation parameter set information;

[0577] The sixth field is used to indicate the block confirmation timeout value.

[0578] In some embodiments, at least one field in the first frame is carried in the block acknowledgment protocol context element and / or the security association context element.

[0579] In some embodiments, the migration status includes at least one of the following:

[0580] The first migration state indicates that all context information has been migrated.

[0581] The second migration status is used to indicate that the migration of the context information portion is complete;

[0582] The third migration status indicates that the migration of all context information is not yet complete.

[0583] In some embodiments, after the non-access point device initiates a roaming decision and before sending a roaming request frame, the above-mentioned apparatus further includes:

[0584] The processing module 1120 is used to stop adding new data packets to the transmit buffer corresponding to the first TID that are to be transmitted uplink; and / or, within a first time period, to prioritize transmitting the first data packet in the transmit buffer, wherein the first data packet is the data packet to be transmitted uplink corresponding to the first TID in the transmit buffer.

[0585] In some embodiments, if the first data packet is not completely sent within the first time period, the processing module 1120 is further configured to clear the second data packet, which is the unsent data packet corresponding to the first TID in the sending buffer; and / or, retain the second data packet and / or the third data packet, which is the data packet corresponding to the first TID that has been sent and has received an acknowledgment response, and the sequence number of the third data packet is greater than or equal to the sequence number of the second data packet. Unsent data packets include unsent data packets and / or data packets that have been sent but have not received an acknowledgment response.

[0586] In some embodiments, while retaining the second data packet and / or the third data packet, the processing module 1120 is further configured to retain the fourth data packet, which is the data packet corresponding to the first TID, and the sequence number of the fourth data packet is greater than or equal to the sequence number of the second data packet; and / or, to preferentially send the data packet with the earlier sequence number in the second data packet.

[0587] In some embodiments, after the non-access point device sends a roaming request frame and before receiving a roaming response frame, the processing module 1120 is further configured to stop adding new data packets to be sent uplink corresponding to the first TID to the sending buffer until the roaming response frame is received; and / or, within a second time period, prioritize sending the first data packet in the sending buffer, the first data packet being the data packet to be sent uplink corresponding to the first TID in the sending buffer; and / or, stop sending the data packet to be sent uplink corresponding to the first TID.

[0588] In some embodiments, if the first data packet is not completely sent within the second time period, the processing module 1120 is further configured to clear the second data packet, which is the data packet corresponding to the first TID in the transmission buffer that has not been completely sent; and / or, retain the second data packet and / or the third data packet, which is the data packet that has been sent and has received an acknowledgment response, and the sequence number of the third data packet is greater than or equal to the sequence number of the second data packet. Data packets that have not been completely sent include unsent data packets and / or data packets that have been sent but have not received an acknowledgment response.

[0589] In some embodiments, while retaining the second data packet and / or the third data packet, the processing module 1120 is further configured to retain the fourth data packet, which is the data packet corresponding to the first TID, and the sequence number of the fourth data packet is greater than or equal to the sequence number of the second data packet; and / or, to preferentially send the data packet with the earlier sequence number in the second data packet.

[0590] In some embodiments, after the non-access point device receives a roaming response frame, the processing module 1120 is further configured to continue the original sequence number of newly added data packets in sequence if the BA protocol has not been renegotiated; or, if the BA protocol has been renegotiated, process the data packets in the transmission buffer based on the renegotiated sequence number.

[0591] In some embodiments, after the non-access point device receives a roaming response frame, the processing module 1120 is further configured to, in the case of a PTK update, encrypt the data packet to be sent and / or decrypt the received data packet using the updated PTK, and use the new PN space; or, in the case of a PTK not being updated, encrypt the data packet to be sent and / or decrypt the received data packet using the original PTK, and use the original PN space.

[0592] In some embodiments, after the non-access point device receives the roaming response frame, if the first data packet still exists in the transmission buffer and the BA protocol has not been renegotiated, the processing module 1120 is further configured to discard the fifth data packet if the sequence number of the fifth data packet is less than or equal to the first sequence number, where the first sequence number is the sequence number of the last data packet uploaded to the upper or higher layer; or,

[0593] If the sequence number of the fifth data packet is greater than the sequence number of the first data packet, and the fifth data packet is encrypted, discard the fifth data packet; or,

[0594] If the sequence number of the fifth data packet is greater than the sequence number of the first data packet, and the fifth data packet is encrypted, and if the PTK has not been updated, then the original PTK and the original PN space are used to maintain the fifth data packet unchanged; or,

[0595] If the sequence number of the fifth data packet is greater than the sequence number of the first data packet, and the fifth data packet is encrypted, and the PTK is updated, then the original PTK is used to decrypt the fifth data packet, followed by the new PTK to encrypt the fifth data packet, and a new PN space is used; or,

[0596] If the sequence number of the fifth data packet is greater than the sequence number of the first data packet, and the fifth data packet is unencrypted, then if no new PTK encryption is needed, the fifth data packet remains unchanged; or,

[0597] If the sequence number of the fifth data packet is greater than the sequence number of the first data packet, and the fifth data packet is unencrypted, then if a new PTK encryption is required, the new PTK will be used to encrypt the fifth data packet, and a new PN space will be used.

[0598] The first data packet is the data packet to be sent uplink corresponding to the first TID in the sending buffer, and the fifth data packet is a subset of the first data packet.

[0599] In some embodiments, if the first data packet still exists in the transmit buffer after the non-access point device receives the roaming response frame, and the BA protocol has been renegotiated, the processing module 1120 is further configured to discard the fifth data packet if the sequence number of the fifth data packet is less than or equal to the first sequence number, where the first sequence number is the sequence number of the last data packet uploaded to the upper or higher layer; or,

[0600] If the sequence number of the fifth data packet is greater than the sequence number of the first data packet, discard the fifth data packet; or,

[0601] If the sequence number of the fifth data packet is greater than the sequence number of the first data packet, the newly negotiated sequence number shall be used; or,

[0602] If the sequence number of the fifth data packet is greater than the sequence number of the first data packet, and the fifth data packet is unencrypted, then if PTK encryption is not required, the fifth data packet remains unchanged; or,

[0603] If the sequence number of the fifth data packet is greater than the sequence number of the first data packet, and the fifth data packet is unencrypted, then if the original PTK encryption is required, the original PTK should be used to encrypt the fifth data packet, and the original PN space should be used; or,

[0604] If the sequence number of the fifth data packet is greater than the sequence number of the first data packet, and the fifth data packet is unencrypted, then if a new PTK encryption is required, the new PTK will be used to encrypt the fifth data packet, and a new PN space will be used; or,

[0605] If the sequence number of the fifth data packet is greater than the sequence number of the first data packet, and the fifth data packet is encrypted, and a new PTK encryption is required, then the original PTK is used to decrypt the fifth data packet, and then the new PTK is used to encrypt the fifth data packet, and a new PN space is used.

[0606] The first data packet is the data packet to be sent uplink corresponding to the first TID in the sending buffer, and the fifth data packet is a subset of the first data packet.

[0607] In some embodiments, after the non-access point device receives a roaming response frame, the processing module 1120 is further configured to determine, based on the received reordering cache record bitmap value, to send a sixth data packet and / or to clear a seventh data packet.

[0608] The sixth data packet is the data packet corresponding to the first bitmap value in the received reordered buffer record bitmap value, and the seventh data packet is the data packet corresponding to the second bitmap value in the received reordered buffer record bitmap value.

[0609] In some embodiments, after the non-access point device receives the roaming response frame, the processing module 1120 is further configured to send a second frame to the second access point device. The second frame is used to indicate the update of the receive reordering cache control status information. The second frame includes a third field for indicating the receive reordering cache control status information. At least one field in the second frame is carried in the block acknowledgment protocol context element and / or security association context element.

[0610] In some embodiments, the first frame is a roaming response frame or a data communication context information migration status notification frame. The time of receiving the data communication context information migration status notification frame includes at least one of the following: before sending the roaming request frame; after sending the roaming request frame; before receiving the roaming response frame; simultaneously with receiving the roaming response frame; and after receiving the roaming response frame.

[0611] In some embodiments, the non-access point device is a non-access point single-site device or a non-access point multi-link device; the first access point device is a first access point single-site device or a first access point multi-link device; and the second access point device is a second access point single-site device or a second access point multi-link device.

[0612] Figure 15 shows a structural block diagram of a migration apparatus provided in an exemplary embodiment of this application. Optionally, the apparatus may be implemented as a first access point device. The first access point device includes a first access point single-site device or a first access point multi-link device. The apparatus includes:

[0613] The sending module 1210 is configured to send a first frame to the non-access point device. The first frame indicates the context information and / or the migration status of the context information from the first access point device to the second access point device. The context information refers to the context of the uplink data communication protocol for the non-access point device.

[0614] In some embodiments, the context information includes one or more of the following:

[0615] The sequence number of the last data packet that has been transmitted to the upper or higher layer in the first TID;

[0616] The packet number of the last data packet that has been transmitted to the upper or higher layer in the first TID;

[0617] Receive reordering cache control status information;

[0618] Scoreboard context control status information;

[0619] Block confirmation parameter set information;

[0620] Block confirmation timeout value.

[0621] In some embodiments, receiving reorder cache control status information includes one or more of the following:

[0622] The first parameter value is used to indicate the lowest sequence number expected to be received in the receive window;

[0623] The second parameter value is used to indicate the highest sequence number expected to be received in the receive window;

[0624] Receives the bitmap value of the reordered cache record.

[0625] In some embodiments, the scoreboard context control status information includes one or more of the following:

[0626] The third parameter value is used to indicate the lowest sequence number position in the BA record bitmap;

[0627] The fourth parameter value is used to indicate the position of the highest sequence number in the BA record bitmap;

[0628] BA records bitmap values.

[0629] In some embodiments, the first frame includes at least one of the following fields:

[0630] The first field is used to indicate the sequence number of the last data packet that has been transmitted to the upper or higher layer of the first TID;

[0631] The second field is used to indicate the packet number of the last data packet that has been transmitted to the upper layer for the first TID;

[0632] The third field is used to indicate the status information of receiving reordering cache control;

[0633] The fourth field is used to indicate the scoreboard context control status information;

[0634] The fifth field is used to indicate the block confirmation parameter set information;

[0635] The sixth field is used to indicate the block confirmation timeout value.

[0636] In some embodiments, at least one field in the first frame is carried in the block acknowledgment protocol context element and / or the security association context element.

[0637] In some embodiments, the migration status includes at least one of the following:

[0638] The first migration state indicates that all context information has been migrated.

[0639] The second migration status is used to indicate that the migration of the context information portion is complete;

[0640] The third migration status indicates that the migration of all context information is not yet complete.

[0641] In some embodiments, after the first access point device receives a roaming request frame, the above-mentioned apparatus further includes:

[0642] The processing module 1220 is configured to clear the eighth data packet in the receive reordering buffer, where the eighth data packet is a data packet that was not successfully migrated in the receive reordering buffer, if a first condition is met; or, if a second condition is met, migrate the eighth data packet to the second access point device.

[0643] In some embodiments, the first condition includes at least one of the following:

[0644] PTK update;

[0645] PTK has not been updated, and migration from the first access point device to the second access point device is not supported.

[0646] In some embodiments, the second condition includes:

[0647] PTK has not been updated and supports migration from the first access point device to the second access point device.

[0648] In some embodiments, the first frame is a roaming response frame or a data communication context information migration status notification frame. The data communication context information migration status notification frame is sent at least one of the following times: before receiving a roaming request frame; after receiving a roaming request frame; before sending a roaming response frame; simultaneously with sending a roaming response frame; and after sending a roaming response frame.

[0649] In some embodiments, the non-access point device is a non-access point single-site device or a non-access point multi-link device; the first access point device is a first access point single-site device or a first access point multi-link device; and the second access point device is a second access point single-site device or a second access point multi-link device.

[0650] Figure 16 shows a structural block diagram of a migration apparatus provided in an exemplary embodiment of this application. Optionally, the apparatus can be implemented as a second access point device. The second access point device includes a second access point single-site device or a second access point multi-link device. The apparatus includes:

[0651] The sending module 1310 is configured to send a first frame to the non-access point device. The first frame indicates context information and / or the migration status of the context information from the first access point device to the second access point device. The context information refers to the context of the uplink data communication protocol for the non-access point device.

[0652] In some embodiments, the context information includes one or more of the following:

[0653] The sequence number of the last data packet that has been transmitted to the upper or higher layer in the first TID;

[0654] The packet number of the last data packet that has been transmitted to the upper or higher layer in the first TID;

[0655] Receive reordering cache control status information;

[0656] Scoreboard context control status information;

[0657] Block confirmation parameter set information;

[0658] Block confirmation timeout value.

[0659] In some embodiments, receiving reorder cache control status information includes one or more of the following:

[0660] The first parameter value is used to indicate the lowest sequence number expected to be received in the receive window;

[0661] The second parameter value is used to indicate the highest sequence number expected to be received in the receive window;

[0662] Receives the bitmap value of the reordered cache record.

[0663] In some embodiments, the scoreboard context control status information includes one or more of the following:

[0664] The third parameter value is used to indicate the lowest sequence number position in the BA record bitmap;

[0665] The fourth parameter value is used to indicate the position of the highest sequence number in the BA record bitmap;

[0666] BA records bitmap values.

[0667] In some embodiments, the first frame includes at least one of the following fields:

[0668] The first field is used to indicate the sequence number of the last data packet that has been transmitted to the upper or higher layer of the first TID;

[0669] The second field is used to indicate the packet number of the last data packet that has been transmitted to the upper layer for the first TID;

[0670] The third field is used to indicate the status information of receiving reordering cache control;

[0671] The fourth field is used to indicate the scoreboard context control status information;

[0672] The fifth field is used to indicate the block confirmation parameter set information;

[0673] The sixth field is used to indicate the block confirmation timeout value.

[0674] In some embodiments, at least one field in the first frame is carried in the block acknowledgment protocol context element and / or the security association context element.

[0675] In some embodiments, the migration status includes at least one of the following:

[0676] The first migration state indicates that all context information has been migrated.

[0677] The second migration status is used to indicate that the migration of the context information portion is complete;

[0678] The third migration status indicates that the migration of all context information is not yet complete.

[0679] In some embodiments, after the second access point device sends a roaming response frame, the above-described apparatus further includes:

[0680] The processing module 1320 is used to parse the received individually addressed data packets using the original PTK and to perform the original PN space check when the PTK is not updated; or, when the PTK is updated, to parse the received individually addressed data packets using the updated PTK and to perform the original PN space check.

[0681] In some embodiments, the first frame is a roaming response frame or a data communication context information migration status notification frame. The data communication context information migration status notification frame is sent at least one of the following times: before receiving a roaming request frame; after receiving a roaming request frame; before sending a roaming response frame; simultaneously with sending a roaming response frame; and after sending a roaming response frame.

[0682] In some embodiments, the non-access point device is a non-access point single-site device or a non-access point multi-link device; the first access point device is a first access point single-site device or a first access point multi-link device; and the second access point device is a second access point single-site device or a second access point multi-link device.

[0683] Figure 17 shows a structural block diagram of a migration apparatus provided in an exemplary embodiment of this application. Optionally, the apparatus can be implemented as a non-access point device. A non-access point device includes a non-access point site device or a non-access point multilink device. The apparatus includes:

[0684] The sending module 1420 is used by the non-access point device to send a third frame, which indicates the migration context information from the first access point device to the second access point device. The context information is the context of the uplink data communication protocol for the non-access point device.

[0685] In some embodiments, the context information includes one or more of the following:

[0686] The sequence number of the last data packet that has been transmitted to the upper or higher layer in the first TID;

[0687] The packet number of the last data packet that has been transmitted to the upper or higher layer in the first TID;

[0688] Receive reordering cache control status information;

[0689] Scoreboard context control status information;

[0690] Block confirmation parameter set information;

[0691] Block confirmation timeout value.

[0692] In some embodiments, receiving reorder cache control status information includes one or more of the following:

[0693] The first parameter value is used to indicate the lowest sequence number expected to be received in the receive window;

[0694] The second parameter value is used to indicate the highest sequence number expected to be received in the receive window;

[0695] Receives the bitmap value of the reordered cache record.

[0696] In some embodiments, the scoreboard context control status information includes one or more of the following:

[0697] The third parameter value is used to indicate the lowest sequence number position in the BA record bitmap;

[0698] The fourth parameter value is used to indicate the position of the highest sequence number in the BA record bitmap;

[0699] BA records bitmap values.

[0700] In some embodiments, the first frame includes at least one of the following fields:

[0701] The first field is used to indicate the sequence number of the last data packet that has been transmitted to the upper or higher layer of the first TID;

[0702] The second field is used to indicate the packet number of the last data packet that has been transmitted to the upper layer for the first TID;

[0703] The third field is used to indicate the status information of receiving reordering cache control;

[0704] The fourth field is used to indicate the scoreboard context control status information;

[0705] The fifth field is used to indicate the block confirmation parameter set information;

[0706] The sixth field is used to indicate the block confirmation timeout value.

[0707] In some embodiments, at least one field in the first frame is carried in the block acknowledgment protocol context element and / or the security association context element.

[0708] It should be noted that the device provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules according to actual needs, that is, the content structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0709] Figure 18 shows a schematic diagram of the structure of a communication device (network device or terminal device) provided in one embodiment of this application. The communication device may include: a processor 2101, a receiver 2102, a transmitter 2103, a memory 2104, and a bus 2105.

[0710] The processor 2101 includes one or more processing cores. The processor 2101 executes various functional applications and information processing by running software programs and modules.

[0711] The receiver 2102 and the transmitter 2103 can be implemented as a transceiver 2106, which can be a communication chip.

[0712] The memory 2104 is connected to the processor 2101 via the bus 2105. The memory 2104 can be used to store computer programs, and the processor 2101 can be used to execute the computer programs to implement the various steps performed by the communication device in the above method embodiment.

[0713] Furthermore, memory 2104 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, including but not limited to: RAM (Random-Access Memory) and ROM (Read-Only Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other solid-state storage technologies, CD-ROM (Compact Disc Read-Only Memory), DVD (Digital Video Disc) or other optical storage, magnetic tape cassettes, magnetic tape, disk storage or other magnetic storage devices.

[0714] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor of a communication device to implement the various steps in the migration method described above.

[0715] In some embodiments, the computer-readable storage medium may include ROM (Read-Only Memory), RAM (Random-Access Memory), SSD (Solid State Drives), or optical disc, etc. The random access memory may include ReRAM (Resistance Random Access Memory) and DRAM (Dynamic Random Access Memory).

[0716] This application also provides a chip, which includes programmable logic circuits and / or program instructions, and when the chip is run on a communication device, it is used to implement the various steps in the above migration method.

[0717] This application also provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of the communication device reads and executes the computer instructions from the computer-readable storage medium to implement the various steps in the migration method described above.

[0718] Those skilled in the art will recognize that the functions described in the embodiments of this application in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transfer of a computer program from one place to another. Storage media can be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0719] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A migration method characterized by, The method is performed by a non-access point device, and the method includes: Receive a first frame, the first frame being used to indicate context information and / or the migration status of the context information from the first access point device to the second access point device; The context information refers to the context of the uplink data communication protocol for the non-access point device.

2. The method of claim 1, wherein, The context information includes one or more of the following: The sequence number of the last data packet that has been transmitted to the upper or higher layer, which is the first-order identifier (TID). The packet number of the last data packet that has been transmitted to the upper or higher layer of the first TID; Receive reordering cache control status information; Scoreboard context control status information; Block confirmation parameter set information; Block confirmation timeout value.

3. The method of claim 2, wherein, The received reordering cache control status information includes one or more of the following: The first parameter value is used to indicate the lowest sequence number expected to be received in the receive window; The second parameter value is used to indicate the highest sequence number expected to be received in the receiving window; Receives the bitmap value of the reordered cache record.

4. The method of claim 2, wherein, The scoreboard context control status information includes one or more of the following: The third parameter value is used to indicate the lowest sequence number position in the block confirmation BA record bitmap; The fourth parameter value is used to indicate the position of the highest sequence number in the BA record bitmap; BA records bitmap values.

5. The method according to any one of claims 1 to 4, characterized in that, The first frame includes at least one of the following fields: The first field is used to indicate the sequence number of the last data packet that has been transmitted to the upper or higher layer of the first TID; The second field is used to indicate the packet number of the last data packet that the first TID has been transmitted to the upper layer; The third field is used to indicate the status information of receiving reordering cache control; The fourth field is used to indicate the scoreboard context control status information; The fifth field is used to indicate the block confirmation parameter set information; The sixth field is used to indicate the block confirmation timeout value.

6. The method according to claim 5, characterized in that, At least one field in the first frame is carried in the block acknowledgment protocol context element and / or the security association context element.

7. The method according to any one of claims 1 to 6, characterized in that, The migration state includes at least one of the following: The first migration state indicates that all the context information has been migrated. The second migration status is used to indicate that the migration of the context information portion is complete; The third migration status is used to indicate that the migration of all the context information has not been completed.

8. The method according to any one of claims 1 to 7, characterized in that, After the non-access point device initiates the roaming decision and before sending the roaming request frame, the method further includes one or more of the following: Stop adding new data packets to the transmit buffer corresponding to the first TID that are to be sent uplink; Within a first time period, the first data packet in the transmission buffer is sent first, and the first data packet is the data packet to be sent uplink corresponding to the first TID in the transmission buffer; Stop sending the data packets to be sent uplink corresponding to the first TID.

9. The method of claim 8, wherein, If the first data packet cannot be completely sent within the first time period, the method further includes one or more of the following: Clear the second data packet, which is the uncompleted data packet corresponding to the first TID in the sending buffer; The second data packet and / or the third data packet are retained, wherein the third data packet is the data packet that has been sent and has received an acknowledgment response corresponding to the first TID, and the sequence number of the third data packet is greater than or equal to the sequence number of the second data packet; The data packets that were not successfully sent include data packets that were not sent and / or data packets that were sent but for which no acknowledgment response was received.

10. The method of claim 9, wherein, If the second data packet and / or the third data packet are retained, the method further includes one or more of the following: The fourth data packet is retained. The fourth data packet is the data packet corresponding to the first TID, and the sequence number of the fourth data packet is greater than or equal to the sequence number of the second data packet. The data packet with the earlier sequence number in the second data packet is sent first.

11. The method according to any one of claims 1 to 7, characterized in that, After the non-access point device sends a roaming request frame and before receiving a roaming response frame, the method further includes one or more of the following: Stop adding new uplink data packets corresponding to the first TID to the transmit buffer until the roaming response frame is received; Within the second time period, the first data packet in the transmission buffer is sent first, and the first data packet is the data packet to be sent uplink corresponding to the first TID in the transmission buffer; Stop sending the data packets to be sent uplink corresponding to the first TID.

12. The method of claim 11, wherein, If the first data packet cannot be completely sent within the second time period, the method further includes one or more of the following: Clear the second data packet, which is the uncompleted data packet corresponding to the first TID in the sending buffer; The second data packet and / or the third data packet are retained, wherein the third data packet is a data packet that has been sent and has received an acknowledgment response, and the sequence number of the third data packet is greater than or equal to the sequence number of the second data packet; The data packets that were not successfully sent include data packets that were not sent and / or data packets that were sent but for which no acknowledgment response was received.

13. The method of claim 12, wherein, If the second data packet and / or the third data packet are retained, the method further includes one or more of the following: The fourth data packet is reserved. The fourth data packet is the data packet to be sent uplink corresponding to the first TID. The sequence number of the fourth data packet is greater than or equal to the sequence number of the second data packet. The data packet with the earlier sequence number in the second data packet is sent first.

14. The method according to any one of claims 1 to 7, characterized in that, After the non-access point device receives the roaming response frame, the method further includes one or more of the following: Without renegotiating the BA protocol, newly added data packets will continue to use the original sequence number in sequence; In the case of renegotiating the BA protocol, data packets in the transmit buffer are processed based on the renegotiated sequence number.

15. The method according to any one of claims 1 to 7, characterized in that, After the non-access point device receives the roaming response frame, the method further includes one or more of the following: In the case of pairwise temporary key (PTK) updates, the updated PTK is used to encrypt the data packets to be sent and / or to decrypt the received data packets, and a new packet number (PN) space is used. If the PTK is not updated, the original PTK is used to encrypt the data packets to be sent and / or decrypt the data packets to be received, and the original PN space is used.

16. The method according to any one of claims 1 to 7, characterized in that, If, after the non-access point device receives the first frame, or after the non-access point device receives the roaming response frame, or when the non-access point device receives the roaming response frame, there is still a first data packet in the transmission buffer and the BA protocol has not been renegotiated, the method further includes one or more of the following: If the sequence number of the fifth data packet is less than or equal to the first sequence number, the fifth data packet is discarded. The first sequence number is the sequence number of the last data packet that has been uploaded to the upper or higher layer. If the sequence number of the fifth data packet is greater than the first sequence number, and the fifth data packet is encrypted, then the fifth data packet is discarded. If the sequence number of the fifth data packet is greater than the first sequence number and the fifth data packet is encrypted, and if the PTK is not updated, then the original PTK and the original PN space are used to keep the fifth data packet unchanged. If the sequence number of the fifth data packet is greater than the first sequence number and the fifth data packet is encrypted, and the PTK is updated, the original PTK is used to decrypt the fifth data packet, and then the new PTK is used to encrypt the fifth data packet, and a new PN space is used. If the sequence number of the fifth data packet is greater than the first sequence number, and the fifth data packet is unencrypted, then if no new PTK encryption is required, the fifth data packet remains unchanged. If the sequence number of the fifth data packet is greater than the first sequence number and the fifth data packet is unencrypted, and if a new PTK encryption is required, then the fifth data packet is encrypted using the new PTK and a new PN space is used. The first data packet is the data packet to be sent uplink corresponding to the first TID in the sending buffer, and the fifth data packet is a subset of the first data packet.

17. The method of any one of claims 1 to 7, wherein, If, after the non-access point device receives the first frame, or after the non-access point device receives the roaming response frame, or when the non-access point device receives the roaming response frame, there is still a first data packet in the transmission buffer, and the BA protocol has been renegotiated, the method further includes one or more of the following: If the sequence number of the fifth data packet is less than or equal to the first sequence number, the fifth data packet is discarded. The first sequence number is the sequence number of the last data packet that has been uploaded to the upper or higher layer. If the sequence number of the fifth data packet is greater than the first sequence number, the fifth data packet is discarded. If the sequence number of the fifth data packet is greater than the first sequence number, the newly negotiated sequence number shall be used; If the sequence number of the fifth data packet is greater than the first sequence number, and the fifth data packet is unencrypted, then if PTK encryption is not required, the fifth data packet remains unchanged. If the sequence number of the fifth data packet is greater than the first sequence number and the fifth data packet is unencrypted, and if the original PTK encryption is required, then the original PTK is used to encrypt the fifth data packet, and the original PN space is used. If the sequence number of the fifth data packet is greater than the first sequence number and the fifth data packet is unencrypted, and if a new PTK encryption is required, then the fifth data packet is encrypted using the new PTK and a new PN space is used. If the sequence number of the fifth data packet is greater than the first sequence number and the fifth data packet is encrypted, and if a new PTK encryption is required, the original PTK is used to decrypt the fifth data packet, and then the new PTK is used to encrypt the fifth data packet, and a new PN space is used. The first data packet is the data packet to be sent uplink corresponding to the first TID in the sending buffer, and the fifth data packet is a subset of the first data packet.

18. The method of any one of claims 1 to 7, wherein, After the non-access point device receives the first frame, or after the non-access point device receives the roaming response frame, or when the non-access point device receives the roaming response frame, the method further includes: Based on the received reordering buffer record bitmap value, determine to send the sixth data packet, and / or clear the seventh data packet; The sixth data packet is the data packet corresponding to the first bitmap value in the received reordering cache record bitmap value, and the seventh data packet is the data packet corresponding to the second bitmap value in the received reordering cache record bitmap value.

19. The method according to any one of claims 1 to 7, characterized in that, After the non-access point device receives the first frame, or after the non-access point device receives the roaming response frame, or when the non-access point device receives the roaming response frame, the method further includes: A second frame is sent to the second access point device, the second frame being used to indicate the update of the receive reordering cache control status information.

20. The method of claim 19, wherein, The second frame includes: The third field is used to indicate the status information for receiving reordering cache control.

21. The method according to claim 20, characterized in that, At least one field in the second frame is carried in the block acknowledgment protocol context element and / or the security association context element.

22. The method according to any one of claims 1 to 21, characterized in that, The first frame is either a roaming response frame or a data communication context information migration status notification frame, and the reception time of the data communication context information migration status notification frame includes at least one of the following: Before sending the roaming request frame; After sending the roaming request frame; Before receiving the roaming response frame; Upon receiving the roaming response frame; After receiving the roaming response frame.

23. The method according to any one of claims 1 to 22, characterized in that, The non-access point device is a non-access point single-site device or a non-access point multi-link device. The first access point device is either a single-site access point device or a multi-link access point device. The second access point device is either a single-site second access point device or a multi-link second access point device.

24. A migration method, comprising: The method is executed by a first access point device, and the method includes: Send a first frame to a non-access point device, the first frame being used to indicate context information and / or the migration status of the context information from the first access point device to the second access point device; The context information refers to the context of the uplink data communication protocol for the non-access point device.

25. The method of claim 24, wherein, The context information includes one or more of the following: The sequence number of the last data packet that has been transmitted to the upper or higher layer in the first TID; The packet number of the last data packet that has been transmitted to the upper or higher layer of the first TID; Receive reordering cache control status information; Scoreboard context control status information; Block confirmation parameter set information; Block confirmation timeout value.

26. The method of claim 25, wherein, The received reordering cache control status information includes one or more of the following: The first parameter value is used to indicate the lowest sequence number expected to be received in the receive window; The second parameter value is used to indicate the highest sequence number expected to be received in the receiving window; Receives the bitmap value of the reordered cache record.

27. The method of claim 25, wherein, The scoreboard context control status information includes one or more of the following: The third parameter value is used to indicate the lowest sequence number position in the BA record bitmap; The fourth parameter value is used to indicate the position of the highest sequence number in the BA record bitmap; BA records bitmap values.

28. The method of any one of claims 24 to 27, wherein, The first frame includes at least one of the following fields: The first field is used to indicate the sequence number of the last data packet that has been transmitted to the upper or higher layer of the first TID; The second field is used to indicate the packet number of the last data packet that the first TID has been transmitted to the upper layer; The third field is used to indicate the status information of receiving reordering cache control; The fourth field is used to indicate the scoreboard context control status information; The fifth field is used to indicate the block confirmation parameter set information; The sixth field is used to indicate the block confirmation timeout value.

29. The method according to claim 28, characterized in that, At least one field in the first frame is carried in the block acknowledgment protocol context element and / or the security association context element.

30. The method of any one of claims 24 to 19, wherein, The migration state includes at least one of the following: The first migration state indicates that all the context information has been migrated. The second migration status is used to indicate that the migration of the context information portion is complete; The third migration status is used to indicate that the migration of all the context information has not been completed.

31. The method of any one of claims 24 to 30, wherein, After receiving the roaming request frame, the method further includes one or more of the following: If the first condition is met, the eighth data packet in the receive reordering buffer is cleared, and the eighth data packet is a data packet that was not successfully migrated in the receive reordering buffer. If the second condition is met, the eighth data packet is migrated to the second access point device.

32. The method of claim 31, wherein, The first condition includes at least one of the following: PTK update; PTK has not been updated, but migration from the first access point device to the second access point device is not supported.

33. The method of claim 31, wherein, The second condition includes: PTK has not been updated and migration from the first access point device to the second access point device is supported.

34. The method according to any one of claims 24 to 33, characterized in that, The first frame is either a roaming response frame or a data communication context information migration status notification frame, and the transmission time of the data communication context information migration status notification frame includes at least one of the following: Before receiving the roaming request frame; After receiving the roaming request frame; Before sending the roaming response frame; While sending the roaming response frame; After sending the roaming response frame.

35. The method according to any one of claims 24 to 34, characterized in that, The non-access point device is a non-access point single-site device or a non-access point multi-link device. The first access point device is either a single-site access point device or a multi-link access point device. The second access point device is either a single-site second access point device or a multi-link second access point device.

36. A migration method, comprising: The method is executed by a second access point device, and the method includes: Send a first frame to a non-access point device, the first frame being used to indicate context information and / or the migration status of the context information from the first access point device to the second access point device; The context information refers to the context of the uplink data communication protocol for the non-access point device.

37. The method of claim 36, wherein, The context information includes one or more of the following: The sequence number of the last data packet that has been transmitted to the upper or higher layer in the first TID; The packet number of the last data packet that has been transmitted to the upper layer in the first TID; Receive reordering cache control status information; Scoreboard context control status information; Block confirmation parameter set information; Block confirmation timeout value.

38. The method of claim 37, wherein, The received reordering cache control status information includes one or more of the following: The first parameter value is used to indicate the lowest sequence number expected to be received in the receive window; The second parameter value is used to indicate the highest sequence number expected to be received in the receiving window; Receives the bitmap value of the reordered cache record.

39. The method of claim 37, wherein, The scoreboard context control status information includes one or more of the following: The third parameter value is used to indicate the lowest sequence number position in the BA record bitmap; The fourth parameter value is used to indicate the position of the highest sequence number in the BA record bitmap; BA records bitmap values.

40. The method of any one of claims 36 to 39, wherein, The first frame includes at least one of the following fields: The first field is used to indicate the sequence number of the last data packet that has been transmitted to the upper or higher layer of the first TID; The second field is used to indicate the packet number of the last data packet that the first TID has been transmitted to the upper layer; The third field is used to indicate the status information of receiving reordering cache control; The fourth field is used to indicate the scoreboard context control status information; The fifth field is used to indicate the block confirmation parameter set information; The sixth field is used to indicate the block confirmation timeout value.

41. The method according to claim 40, characterized in that, At least one field in the first frame is carried in the block acknowledgment protocol context element and / or the security association context element.

42. The method of any one of claims 36 to 41, wherein, The migration state includes at least one of the following: The first migration state indicates that all the context information has been migrated. The second migration status is used to indicate that the migration of the context information portion is complete; The third migration status is used to indicate that the migration of all the context information has not been completed.

43. The method of any one of claims 36 to 42, wherein, After the second access point device sends a roaming response frame, the method further includes one or more of the following: If the PTK is not updated, the original PTK is used to parse the received individually addressed data packets, and the original PN space check is used. In the case of PTK update, the updated PTK is used to parse the received individually addressed data packets, and the original PN space check is used.

44. The method according to any one of claims 36 to 43, characterized in that, The first frame is either a roaming response frame or a data communication context information migration status notification frame, and the transmission time of the data communication context information migration status notification frame includes at least one of the following: Before receiving the roaming request frame; After receiving the roaming request frame; Before sending the roaming response frame; At the same time as sending the roaming response frame; After sending the roaming response frame.

45. The method according to any one of claims 36 to 44, characterized in that, The non-access point device is a non-access point single-site device or a non-access point multi-link device. The first access point device is either a single-site access point device or a multi-link access point device. The second access point device is either a single-site second access point device or a multi-link second access point device.

46. A migration method, comprising: The method is performed by a non-access point device, and the method includes: Send a third frame, the third frame being used to indicate the migration context information from the first access point device to the second access point device; The context information refers to the context of the uplink data communication protocol for the non-access point device.

47. The method of claim 46, wherein, The context information includes one or more of the following: The sequence number of the last data packet that has been transmitted to the upper or higher layer in the first TID; The packet number of the last data packet that has been transmitted to the upper layer in the first TID; Receive reordering cache control status information; Scoreboard context control status information; Block confirmation parameter set information; Block confirmation timeout value.

48. The method of claim 47, wherein, The received reordering cache control status information includes one or more of the following: The first parameter value is used to indicate the lowest sequence number expected to be received in the receive window; The second parameter value is used to indicate the highest sequence number expected to be received in the receiving window; Receives the bitmap value of the reordered cache record.

49. The method of claim 47, wherein, The scoreboard context control status information includes one or more of the following: The third parameter value is used to indicate the lowest sequence number position in the BA record bitmap; The fourth parameter value is used to indicate the position of the highest sequence number in the BA record bitmap; BA records bitmap values.

50. The method of any one of claims 46 to 49, wherein, The third frame includes at least one of the following fields: The first field is used to indicate the sequence number of the last data packet that has been transmitted to the upper or higher layer of the first TID; The second field is used to indicate the packet number of the last data packet that the first TID has been transmitted to the upper layer; The third field is used to indicate the status information of receiving reordering cache control; The fourth field is used to indicate the scoreboard context control status information; The fifth field is used to indicate the block confirmation parameter set information; The sixth field is used to indicate the block confirmation timeout value.

51. The method according to claim 50, characterized in that, At least one field in the third frame is carried in the block acknowledgment protocol context element and / or the security association context element.

52. The method according to any one of claims 46 to 51, characterized in that, The third frame is either a roaming request frame or a data communication context information migration indication frame.

53. A migration device, comprising: The device includes: A receiving module is configured to receive a first frame, wherein the first frame is used to indicate context information and / or the migration status of the context information from the first access point device to the second access point device. The context information refers to the context of the uplink data communication protocol for the non-access point device.

54. A migration device, comprising: The device includes: The sending module is used to send a first frame to a non-access point device, wherein the first frame is used to indicate context information and / or the migration status of the context information from the first access point device to the second access point device. The context information refers to the context of the uplink data communication protocol for the non-access point device.

55. A migration device, comprising: The device includes: A sending module is used to send a third frame, the third frame being used to indicate the migration context information from the first access point device to the second access point device; The context information refers to the context of the uplink data communication protocol for the non-access point device.

56. A non-access point device, comprising: The non-access point device includes: processor; A transceiver connected to the processor; Memory for storing the executable instructions of the processor; The processor is configured to load and execute the executable instructions to implement the migration method as described in any one of claims 1 to 23, and / or the migration method as described in any one of claims 46 to 52.

57. A first access point device, comprising: The first access point device includes: processor; A transceiver connected to the processor; Memory for storing the executable instructions of the processor; The processor is configured to load and execute the executable instructions to implement the migration method as described in any one of claims 24 to 35.

58. A second access point device, comprising: The second access point device includes: processor; A transceiver connected to the processor; Memory for storing the executable instructions of the processor; The processor is configured to load and execute the executable instructions to implement the migration method as described in any one of claims 36 to 45.

59. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement the migration method according to any one of claims 1 to 52.

60. A chip, comprising: The chip includes programmable logic circuitry and / or program instructions, which, when the chip is running on a non-access point device, are used to implement the migration method according to any one of claims 1 to 23, and / or the migration method according to any one of claims 46 to 52.

61. A chip, comprising: The chip includes programmable logic circuitry and / or program instructions, which, when the chip is running on the first access point device, are used to implement the migration method according to any one of claims 24 to 35.

62. A chip, comprising: The chip includes programmable logic circuitry and / or program instructions, which, when the chip is running on the second access point device, are used to implement the migration method according to any one of claims 36 to 45.

63. A computer program product, characterized in that, The computer program product includes computer instructions stored in a computer-readable storage medium; the processor of the non-access point device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the non-access point device to implement the migration method according to any one of claims 1 to 23, and / or the migration method according to any one of claims 46 to 52.

64. A computer program product, characterised in that, The computer program product includes computer instructions stored in a computer-readable storage medium; the processor of the first access point device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the first access point device to implement the migration method according to any one of claims 24 to 35.

65. A computer program product, characterised in that, The computer program product includes computer instructions stored in a computer-readable storage medium; the processor of the second access point device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the second access point device to implement the migration method according to any one of claims 36 to 45.

66. A computer program characterised in that, The computer program is executed by the processor of the non-access point device to implement the migration method according to any one of claims 1 to 23, and / or the migration method according to any one of claims 46 to 52.

67. A computer program characterised in that, The computer program is executed by the processor of the first access point device to implement the migration method according to any one of claims 24 to 35.

68. A computer program, characterized in that, The computer program is executed by the processor of the second access point device to implement the migration method according to any one of claims 36 to 45.

Images